| name | icse-author-response |
| description | Use when drafting an ICSE author response or executing a Major Revision, covering criterion-targeted replies to research-track reviews, the September response window, the four-week revision sprint to the November deadline, response-letter structure, and change tracking that survives PC re-review. |
ICSE Author Response
ICSE gives authors two distinct speaking turns, and they demand different
documents. The author response (September in the 2027 cycle, checked
2026-07-08) answers reviews before first decisions; the Major Revision
response letter (revision due November 17, 2026; final decision December 18)
accompanies a changed paper re-read by the same reviewers. Do not write the
first as if it were the second.
Turn 1: the author response
You are writing for the PC discussion, not for your own catharsis. Three moves
earn their space:
- Correct factual misreadings, with a page/section pointer: "R2 states we
evaluate on toy programs; §5.1 lists the 17 real-world projects (median 210
kLOC)."
- Supply requested evidence that already exists — a number, a table cell,
a clarification of the study protocol. If it fits in a sentence, give the
sentence, not a promise.
- Commit to feasible changes, scoped to what a Major Revision window can
hold. "We will add effect sizes to Table 4" is credible; "we will run a
controlled experiment with professional developers" is not.
Map every reply to the criterion it defends. ICSE reviews are structured around
novelty, rigor, relevance, and verifiability/transparency — a response that
answers a rigor objection with a relevance argument reads as evasion.
| Objection pattern | Criterion under attack | Response that works |
|---|
| "Delta over [X] unclear" | Novelty | One-paragraph contrast: what X cannot do, with citation and evidence pointer |
| "Only N subjects / projects" | Rigor | Justify N against comparable published studies; show per-subject variance |
| "Why would practitioners care?" | Relevance | Concrete failure cost, practitioner quote, or deployment context from the paper |
| "Cannot tell how the tool works" | Verifiability | Point to artifact + name the exact section/README that answers it |
| "Threats section is boilerplate" | Rigor | Name the one threat that genuinely worries you and the mitigation you ran |
Response mechanics for the current cycle (length cap, structured forms, whether
revised PDFs are allowed) were not published at check time — 待核实 on the
HotCRP site when the window opens. Draft to fit the tightest historical norm:
short, numbered, no new-contribution smuggling.
Turn 2: the Major Revision
A Major Revision at ICSE is an itemized contract. The meta-review or reviews
enumerate required changes; December's decision largely reduces to whether each
item is verifiably addressed. The four-week window (Oct 20 notification →
Nov 17 revision in 2027) sets the feasibility bar for what you promise.
Structure the response letter as a ledger:
# Response to Reviews — Submission #NNN (Major Revision)
## Summary of changes
Three sentences: the big moves, in reviewer language.
## R1.1 (rigor) — "No baseline against static analysis tools."
**Change:** Added SpotBugs and Infer as baselines; new §5.3, Table 6.
**Where:** pp. 6–7, marked in blue.
## R1.2 (verifiability) — "Prompt templates not disclosed."
**Change:** Full templates now in the replication package (`prompts/`),
summarized in §4.2.
## R3.4 — "Compare on industrial code."
**Declined, with reason:** licensing prevents redistribution; we instead added
two large OSS systems (§5.1) and state the limit in Threats (§7).
Rules of the ledger: every numbered reviewer point appears, including the ones
you decline; every change names its section and page; declined items get a
reason, never silence. Submit a diff-marked PDF if the instructions allow one
— reviewers granted four weeks of their own time deserve not to hunt.
Revision-sprint triage
With four weeks, order work by decision impact per day:
- Days 1–3: parse all reviews into the ledger; agree the decline list with
coauthors; email the chairs only if a required change is genuinely ambiguous.
- Week 1–2: the evidence items — new baselines, added analyses, statistics.
These have the longest compute/writing tails.
- Week 3: framing items — intro repositioning, related-work additions,
threats rewrite.
- Final days: ledger completion pass, diff-PDF build, artifact update so
the package matches the revised claims.
Tone calibration
The register that works is technical-neutral: no wounded pride, no
flattery, no lawyering. Compare:
- Defensive: "The reviewer apparently did not read §5, where this is
clearly explained." → Working: "§5.2 (Table 4, row 3) reports this; we
will make the forward reference in §3 explicit."
- Over-conceding: "We agree our evaluation is limited and will try to
improve." → Working: "We agree external validity is bounded by the Java
focus; we now state this in §7 and add two non-JVM subjects to the
package's extension guide."
Concede real weaknesses precisely (it buys credibility for the pushbacks);
push back on real errors respectfully (silence reads as agreement).
Anti-patterns
- The grateful essay. Paragraphs of thanks before content; reviewers read
ledgers, not letters of appreciation.
- The stealth rewrite. Changing sections nobody complained about invites
fresh objections in December with no turn left to answer them.
- The optimistic promise in Turn 1 that Turn 2 cannot keep — reviewers
keep receipts across turns; an unkept response commitment is a rejection
reason all by itself.
- Artifact drift: revised claims with an unrevised replication package
fails exactly the verifiability criterion the revision was meant to satisfy.
Output format
[Turn] author response / major revision
[Ledger] N reviewer points -> addressed / declined-with-reason / needs decision
[Feasibility] promised work vs days remaining to Nov 17
[Risk items] points where the December decision could still go against you
