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

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>