thedixitjain ICSE Writing Style
ICSE prose is judged by empiricists. The reviewer pool's shared training — controlled experiments, mining studies, qualitative methods — produces a house reading style: they locate the research questions, check that the design answers them, and read the threats-to-validity section as a candor test. Write for that reading order, not for a general CS audience.
The load-bearing skeleton
A canonical ICSE technique-plus-evaluation paper spends its ten pages (2027 format: 10 pages main text including all figures/tables/appendices, +2 pages references only) roughly like this:
| Section | Pages | What reviewers extract from it |
|---|---|---|
| Introduction | 1.5 | The SE problem, who suffers it, the claim, the contributions list |
| Background / motivating example | 1 | One concrete failing case the technique later fixes |
| Approach | 2–2.5 | How it works, precisely enough to reimplement (verifiability) |
| Study design | 1.5 | RQs, subjects, baselines, metrics, protocol — before any results |
| Results, organized by RQ | 2.5 | One answer per RQ, stated then evidenced |
| Discussion + implications | 0.5–1 | What researchers and practitioners should do differently |
| Threats to validity | 0.5 | Honest limits with mitigations |
| Related work + conclusion | 1 | Delta over neighbors (see icse-related-work) |
Empirical studies swap Approach for extended methodology; the RQ-driven spine stays. If a section cannot say which RQ it serves, it is a cut candidate.
Research questions as contract
State 2–4 RQs in the introduction or design section, then answer them in order with boxed findings:
\subsection{RQ1: How often do generated patches overfit the test suite?}
...evidence...
\begin{tcolorbox}
\textbf{RQ1 finding.} 47\% of patches passing the full suite fail held-out
tests; overfitting concentrates in multi-hunk patches.
\end{tcolorbox}
Reviewers navigate by these boxes. An RQ that is asked but never answered, or a finding with no RQ, both read as design drift — a rigor flag.
The threats-to-validity craft
The section is expected, but its quality is what gets scored. Community convention organizes threats as construct validity (are you measuring the right thing?), internal validity (could something else explain the result?), external validity (to what does it generalize?), and — for statistical work — conclusion validity. Three rules separate a real threats section from ritual:
- Name your actual weakest point, the one a hostile reviewer would find anyway. Preempting it converts an attack into a footnote.
- Pair every threat with what you did about it (mitigation) or why it is tolerable (bounded impact). A threat with neither is a confession.
- Ban imported boilerplate. "Our results may not generalize to other projects" appears in thousands of papers; "our 17 subjects are all Java build systems, and the technique reads JVM bytecode, so C# generalization is untested" is yours alone.
Motivation that survives the relevance criterion
ICSE scores relevance to software engineering explicitly. Ground the opening in an engineering pain that is evidenced, not asserted: a quantified cost from a cited study, a documented incident, an observed practice from your own formative data. The weakest ICSE openings assert that a problem "is important and has attracted increasing attention" — citation-mulch that spends the most valuable half page on nothing.
Calibrated claims
The verifiability criterion punishes claim/evidence gaps, so calibrate:
- Quantify or delete: "substantially outperforms" → "improves F1 by 0.09–0.14 across all three benchmarks (Table 3)".
- Scope every generalization: "for the Java projects studied", "in our interview population".
- Distinguish observation from causation everywhere except where the design licenses causal language (a controlled experiment does; a mining correlation does not).
- Make the contributions list checkable — each bullet should name the section and, where relevant, the artifact directory that substantiates it.
The abstract, sentence by sentence
An ICSE abstract that reviewers bid on accurately runs six moves: (1) the engineering problem with its cost; (2) the gap in how existing work handles it; (3) the approach in one mechanism-revealing sentence; (4) the study design in one sentence — subjects, baselines, method; (5) headline results with numbers, scoped; (6) the availability sentence. Move 4 is the one authors from other communities omit and SE reviewers miss immediately: at ICSE the study is a first-class part of the contribution, and an abstract that hides it reads as having something to hide.
Ten-page compression without desk-reject risk
The IEEE template's formatting rules are desk-reject-enforceable, so recover
space editorially: merge motivating example into the introduction; convert
prose protocol descriptions into a design table; move non-decision-critical
material to the replication package and cite it in the availability statement
(the package, unlike the paper, has no page cap); tighten figures — SE papers
lose half-pages to screenshots that could be 4-line listings. Never touch
\vspace, margins, or font sizes.
Output format
[Structure audit] skeleton section -> present/missing/oversized (page budget)
[RQ contract] each RQ -> design element -> boxed answer (complete? ordered?)
[Threats quality] real weakest point named? mitigations paired? boilerplate found?
[Claim calibration] list of unquantified/over-scoped claims with rewrites
[Space plan] cuts and relocations to reach 10 pages template-clean
Source: brycewang-stanford/Awesome-Journal-Skills → ICSE-Skills/skills/icse-writing-style/SKILL.md