Issta author response

ISSTA Author Response

Use this after ISSTA reviews are released. ISSTA's response step feeds a decision that is not just accept/reject: a first-round paper can be told to submit a Major Revision, so the response and the revision plan are two connected artifacts. Reopen the current author-response and major-revision instructions before drafting, because the dates and mechanics are cycle-specific.

Triage

• Answer concerns that move the decision: soundness of the technique, fairness of the evaluation, scope of the claims, comparison to related work, and verifiability. Cosmetic complaints come last.
• Use submitted evidence — paper sections, tables, the artifact, threats-to-validity discussion. Do not promise experiments you have not run unless you can run them within a Major-Revision window.
• Keep the response anonymous. Do not reveal institution, tool name if it de-anonymizes, repository ownership, or grant numbers in the rebuttal text.
• Separate a rebuttal correction (the reviewer misread something already in the paper) from a promised change (something you will add). Label which is which so the meta-reviewer can weigh the paper as-is against the paper-if-revised.
• If the review budget is tight, spend it on the one objection that, unaddressed, sinks the paper — usually an evaluation-validity or missing-baseline concern.

Drafting pattern

1. State the decision-critical correction or concession in the first line of each reply.
2. Point to the exact table, figure, section, or artifact path that already answers it.
3. Explain the consequence for the claim: what still holds, what you will scope down.
4. Promise only changes that fit the outcome — a camera-ready wording fix for an Accept-leaning paper, a concrete new experiment only if a Major-Revision window exists.

Reviewer pushback patterns

Pushback	What it signals	ISSTA-ready reply
"Evaluated only on your own subjects"	External-validity doubt	Point to the labelled benchmark and its provenance, or commit to adding an established one (Defects4J, real CVEs) in revision
"Baseline is not configured fairly"	Comparison-validity doubt	Cite the equal-budget setup, or concede and re-run the baseline under the reviewer's configuration
"Improvement is within noise"	Statistical-significance doubt	Reference the non-parametric test and effect size, or add repeated runs in revision
"Cannot tell if the artifact reproduces this"	Verifiability doubt	Point to the entry script and logged outputs, or fix the README before the artifact deadline

From reviews to a Major-Revision ledger

When the outcome is Major Revision, convert every review comment into a tracked row: the comment, the change, where it lands in the paper, and its status. The resubmission's cover letter walks this ledger; reviewers who see each of their points addressed in order revise upward.

[R2.3] "No comparison to reversed-order rerunning."
  -> Added reversed-order baseline at equal budget; Table 2, rows 4-6. STATUS: done
[R1.1] "Shared-state model undefined for native calls."
  -> Scoped native state out explicitly; Section 3.1, threats. STATUS: done
[R3.2] "Overhead not reported."
  -> Added per-project overhead; Table 3. STATUS: in progress

Discussion-phase calibration

• Reply precisely and early; ISSTA response windows are short and a focused rebuttal beats an exhaustive one.
• Never paste a whole new results section into the response box; summarize the finding and anchor it to submitted or clearly-promised material.
• Do not argue tone. Convert a hostile review into the technical objection underneath it and answer that.

Output format

[Priority issue] <reviewer concern>
[Decision dimension] soundness / evaluation / scope / related-work / verifiability
[Reply type] rebuttal correction / promised change
[Draft reply] <anonymous, evidence-anchored text>
[Evidence anchor] <table/figure/section/artifact path>
[Revision-ledger row] <comment -> change -> location -> status>