icse-author-response

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:

1. 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)."
2. 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.
3. 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.

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:

1. 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.
2. Week 1–2: the evidence items — new baselines, added analyses, statistics. These have the longest compute/writing tails.
3. Week 3: framing items — intro repositioning, related-work additions, threats rewrite.
4. 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