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)."

1. 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.

1. 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:

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.

1. Week 1–2: the evidence items — new baselines, added analyses, statistics.

These have the longest compute/writing tails.

1. Week 3: framing items — intro repositioning, related-work additions,

threats rewrite.

1. 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