brycewang-stanford ICSME Author Response
Use this after ICSME early decisions are released. ICSME gives authors one speaking turn, and whether you get it at all is decided first: at the start of the author-response period, papers are sorted into Accept, Reject, or Response Recommended. Only "Response Recommended" papers write a rebuttal, and because there is no Major Revision round, that rebuttal is the last word before the final decision.
First: read which bucket you are in
- Early Accept — do not write a defensive response; move to camera-ready and the ROSE artifact.
- Early Reject — no response is requested; a response would not be read. Reroute or rebuild.
- Response Recommended — you are in contention. The PC has specific questions; the rest of this skill is for you.
Triage the questions the PC actually asked
- Answer the specific questions the PC raised in the response invitation first — they are what the discussion will turn on. A rebuttal that ignores the flagged questions to relitigate the reviews' tone is wasted.
- Use evidence that already exists in the submitted paper or artifact. ICSME cannot accept "we will add this" — there is no revision round to add it in. Point to where the answer lives.
- Correct factual misreadings first; a reviewer who misread a change-history table or a mining criterion is often persuadable within one round.
- Keep every word anonymous. Do not name your tool's real name, your own subject system, your institution, grant, or a private repository, even to strengthen a point.
Structure a single-round ICSME rebuttal
Short and decision-focused. Address the PC's questions in priority order; one decisive answer per reviewer beats an exhaustive reply.
[Q1 - reviewer question, quoted briefly]
-> Answer: the held-out result they asked for is already in Table 3 (§4.2); we clarify it here
-> Evidence: §4.2, Table 3; artifact/analysis/rq2 logs (anonymized location)
[Q2 - "is the baseline tuned fairly?"]
-> Answer: both tools ran with the equal, documented budget in §4.1; we restate the setting
[Q3 - "does this generalize beyond one ecosystem?"]
-> Answer: we scope the claim to the studied systems and name it as an external-validity
threat in §5.2; we cannot add subjects in this round and do not claim we can
The rule that wins a single-round rebuttal: answer what was asked with what already exists, and concede cleanly what you cannot show. Overclaiming a fix you cannot make in a non-revision process is what a careful PC catches.
Reviewer pushback patterns
| Pushback | What it signals | ICSME-ready response |
|---|---|---|
| "The baseline is not tuned/fair" | Soundness doubt about the comparison | Point to the equal, documented budget already in the paper; restate the numbers |
| "This is a proxy for the real maintenance outcome" | Construct-validity objection | Point to the audited subsample or bound the proxy; state the residual threat |
| "Does this hold beyond one system's history?" | External-validity limit | Scope the claim to the studied systems; name the threat — do not promise new mining |
| "The mined corpus is not reproducible" | Open-science / provenance gap | Point to pinned SHAs, extraction dates, and the anonymized dataset in the artifact |
| "Overlaps prior maintenance work X" | Novelty/delta doubt | Sharpen the delta sentence against X using what is already in the paper |
Anonymity in the response (easy to slip)
- Refer to your own prior maintenance/evolution work in the third person, as in the paper.
- Describe the artifact without linking to an identity-revealing repository or your public org.
- Do not name the real subject system if naming it would reveal the authors; use the anonymized descriptor from the paper.
- Do not thank a named collaborator or funder inside the response.
Calibration
- Respond to the criterion the reviewer actually raised, not the one you would rather defend.
- There is no second round: do not defer the answer to a "camera-ready version" the PC has not seen.
- The PC discussion decides; the response is evidence for an advocate in that discussion, not a closing argument.
- Response length and format vary by cycle; confirm the current instructions before sending.
Output format
[Bucket] early accept / response recommended / early reject
[PC question] <the specific question being answered>
[Decision dimension] significance / soundness / evidence / threats / clarity / open-science
[Answer ledger] <question -> answer + where the supporting evidence already lives>
[Anonymity check] <no identity leak in the response: passed/issues>