FSE Writing Style
Use this when revising the main paper. FSE papers are PACMSE journal articles read by SE
empiricists, so they need a software-engineering contribution stated in the first page and
evidence a reviewer trusts. The failure this skill prevents is a technically fine paper that reads
like a systems demo or an ML result with an SE title glued on.
Revision rules
- Lead with the SE contribution: the problem a practitioner recognizes, why the current state
is inadequate, the contribution (technique and/or finding), the evidence, and what changes for
software engineering.
- State research questions as contracts. Each RQ should name what is measured and how it will
be judged; every RQ must be answered explicitly in the results, and no result should exist
without an RQ it serves.
- Pair every claim with proportional evidence — real subjects, a fair baseline, a statistic
with an effect size, or a qualitative code with agreement — not adjectives.
- Argue threats to validity; do not recite them. Name the construct, internal, external, and
conclusion threats that actually bite this study, and say what you did to bound each. A
boilerplate threats paragraph is a tell that the author has not stressed their own claims.
- Respect the page budget as a design constraint, not a formatting afterthought — the ACM
template is generous but finite, and a study that only fits by shrinking threats or method is
over-scoped.
- Maintain heavy double-anonymity in self-citations, tool names, acknowledgements, funding,
and the data-availability wording.
Empirical-SE paper skeleton
| Section |
Job it must do |
Common failure |
| Intro |
Problem, inadequacy, contribution, evidence preview, SE payoff — first page |
Leads with a technology trend, not a problem |
| Background/Motivation |
Why a practitioner or the field needs this now |
Motivation by assertion, no grounding |
| Approach / Study design |
The technique or the RQs + protocol, reproducibly |
Method described too thinly to re-run |
| Evaluation |
Each RQ answered with proportional evidence |
Metrics that proxy for the claim rather than test it |
| Threats to validity |
The threats that bite, each bounded |
Generic list untethered from this study |
| Related work |
Delta-first positioning against SE literature |
Catalog of citations with no contrast |
Sentence-level rewrites
| Draft pattern |
FSE-safe rewrite |
| "Our tool significantly improves..." |
"detects X% more defects (95% CI ...) than on " |
| "We evaluate on a large dataset." |
"We evaluate on projects sampled by , listed in the artifact" |
| "Results show our approach works well." |
"RQ2: developers acted on of comments (effect size ...); threats in §5.2" |
| "State-of-the-art performance." |
Claim scoped to the subjects, metrics, and regime actually tested |
| "The LLM understands the code." |
"the model's output matched in of cases" |
Threats-to-validity discipline
[Construct] does the metric measure the SE outcome you claim? (e.g. proxy for causation)
[Internal] could something other than your technique explain the effect? (confounds, tuning)
[External] to which projects/languages/teams does the finding generalize?
[Conclusion] are the statistics appropriate; multiple comparisons corrected; variance reported?
-> for each that bites: state it, then state the mitigation, next to the affected result
Vignette: compressing a three-RQ study
A draft with three RQs, nine figures, and a sprawling background: keep all three RQ answers, the
two figures that carry the headline findings, and a threats subsection per RQ; move secondary plots
and full protocol tables to the artifact with explicit forward references; cut background to what
the argument needs. The test of a good cut: a reviewer should be able to answer "what did each RQ
find, and what threatens it?" from the body alone.
Output format
[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped
[First-page fix] <new framing leading with the SE contribution>
[RQ audit] <RQ -> metric -> where answered -> proportional? yes/no>
[Threats fix] <threat that bites -> mitigation to add, placed by the result>
[Anonymity edits] <tool names / self-citations / links to rewrite>
Source: brycewang-stanford/Awesome-Journal-Skills → FSE-Skills/skills/fse-writing-style/SKILL.md
1---2name: fse-writing-style3description: Use when revising an ESEC/FSE paper for a practitioner-grounded software-engineering contribution on the first page, research-question contracts, a threats-to-validity section that argues rather than recites, evidence proportional to the claim, double-anonymous wording, and disciplined use of the ACM-template page budget.4---567# FSE Writing Style89Use this when revising the main paper. FSE papers are PACMSE journal articles read by SE10empiricists, so they need a **software-engineering contribution stated in the first page** and11evidence a reviewer trusts. The failure this skill prevents is a technically fine paper that reads12like a systems demo or an ML result with an SE title glued on.1314## Revision rules1516- **Lead with the SE contribution:** the problem a practitioner recognizes, why the current state17 is inadequate, the contribution (technique and/or finding), the evidence, and what changes for18 software engineering.19- **State research questions as contracts.** Each RQ should name what is measured and how it will20 be judged; every RQ must be answered explicitly in the results, and no result should exist21 without an RQ it serves.22- **Pair every claim with proportional evidence** — real subjects, a fair baseline, a statistic23 with an effect size, or a qualitative code with agreement — not adjectives.24- **Argue threats to validity; do not recite them.** Name the construct, internal, external, and25 conclusion threats that actually bite *this* study, and say what you did to bound each. A26 boilerplate threats paragraph is a tell that the author has not stressed their own claims.27- **Respect the page budget as a design constraint,** not a formatting afterthought — the ACM28 template is generous but finite, and a study that only fits by shrinking threats or method is29 over-scoped.30- **Maintain heavy double-anonymity** in self-citations, tool names, acknowledgements, funding,31 and the data-availability wording.3233## Empirical-SE paper skeleton3435| Section | Job it must do | Common failure |36|---|---|---|37| Intro | Problem, inadequacy, contribution, evidence preview, SE payoff — first page | Leads with a technology trend, not a problem |38| Background/Motivation | Why a practitioner or the field needs this now | Motivation by assertion, no grounding |39| Approach / Study design | The technique or the RQs + protocol, reproducibly | Method described too thinly to re-run |40| Evaluation | Each RQ answered with proportional evidence | Metrics that proxy for the claim rather than test it |41| Threats to validity | The threats that bite, each bounded | Generic list untethered from this study |42| Related work | Delta-first positioning against SE literature | Catalog of citations with no contrast |4344## Sentence-level rewrites4546| Draft pattern | FSE-safe rewrite |47|---|---|48| "Our tool significantly improves..." | "detects X% more defects (95% CI ...) than <baseline> on <N real projects>" |49| "We evaluate on a large dataset." | "We evaluate on <N> projects sampled by <criterion>, listed in the artifact" |50| "Results show our approach works well." | "RQ2: developers acted on <fraction> of comments (effect size ...); threats in §5.2" |51| "State-of-the-art performance." | Claim scoped to the subjects, metrics, and regime actually tested |52| "The LLM understands the code." | "the model's output matched <criterion> in <fraction> of cases" |5354## Threats-to-validity discipline5556```text57[Construct] does the metric measure the SE outcome you claim? (e.g. proxy for causation)58[Internal] could something other than your technique explain the effect? (confounds, tuning)59[External] to which projects/languages/teams does the finding generalize?60[Conclusion] are the statistics appropriate; multiple comparisons corrected; variance reported?61-> for each that bites: state it, then state the mitigation, next to the affected result62```6364## Vignette: compressing a three-RQ study6566A draft with three RQs, nine figures, and a sprawling background: keep all three RQ answers, the67two figures that carry the headline findings, and a threats subsection per RQ; move secondary plots68and full protocol tables to the artifact with explicit forward references; cut background to what69the argument needs. The test of a good cut: a reviewer should be able to answer "what did each RQ70find, and what threatens it?" from the body alone.7172## Output format7374```text75[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped76[First-page fix] <new framing leading with the SE contribution>77[RQ audit] <RQ -> metric -> where answered -> proportional? yes/no>78[Threats fix] <threat that bites -> mitigation to add, placed by the result>79[Anonymity edits] <tool names / self-citations / links to rewrite>80```8182---8384**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `FSE-Skills/skills/fse-writing-style/SKILL.md`
thedixitjain