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

Sentence-level rewrites

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>