/ase-author-response

name: ase-author-response
description: Use when drafting ASE (IEEE/ACM Automated Software Engineering) author responses, covering the double-anonymous rebuttal that must first survive the early-rejection gate and — distinctively — the criteria-bound revision-round summary-of-changes that maps every stated revision criterion to a concrete change and is re-checked against those criteria.

ASE Author Response

Use this after ASE reviews are released. ASE has **two distinct speaking turns**, and conflating them is a common mistake: a short **rebuttal** (for papers that survive the early-rejection gate), and — if you receive a **Revision** — a **summary-of-changes** accompanying a revised paper that is re-checked against the reviewers' explicitly stated criteria. Both must respect double-anonymity: no author names, institutions, or revealed repository ownership, even to strengthen a point.

Triage (both turns)

• Answer what affects the decision: significance and soundness of the automation, evaluation quality

on real subjects, threats to validity, clarity, and the Data Availability / artifact posture.

• Use evidence that already exists or that the revision will concretely add — never a vague promise.
• Correct factual misreadings first; a reviewer who misread your tool's configuration or a table is

often persuadable.

• Keep every word anonymous. Do not name your tool's real name, institution, grant, or a private

repository.

Turn 1 — the rebuttal (only if you survived early rejection)

If your paper reached the rebuttal stage, at least one reviewer saw value; a uniformly negative set would have been early-rejected. So the rebuttal's job is narrow: **move the borderline reviewer**.

• Short and decision-focused. One decision-critical point per reviewer beats an exhaustive reply.
• Concede what is true, correct what is misread, and point to exactly where the answer lives in the

submitted paper or artifact.

• Do not paste large new results the reviewers cannot verify; if a small, checkable number answers a

direct question ("what is the runtime overhead?"), give it.

• Signal what you *would* do in a revision, because Revision is a live outcome — but do not promise a

redesign you cannot deliver in the window.

Turn 2 — the revision summary-of-changes (the distinctive ASE move)

A Revision is criteria-bound: the reviewers wrote **concrete, actionable criteria** and agreed to accept in principle if they are met. The summary-of-changes is a **criterion ledger**: for every stated criterion, either meet it and show where, or explain precisely why it is infeasible and what you did instead.

[C1] Criterion (quoted): "Add a comparison against tool X on the same subjects."
     -> Action: DONE  | added §5.3, Table 4: X run with an equal, documented budget on all 90 subjects
     -> Where: §5.3, Table 4; artifact/eval/compare_X.sh
[C2] Criterion: "Report an ablation isolating the learned component."
     -> Action: DONE  | §5.4, Table 5 replaces learned templates with static rewrites
[C3] Criterion: "Evaluate on an industrial code base."
     -> Action: INFEASIBLE (with reason) | no license to redistribute proprietary subjects; added
        an open large-scale subject instead (§5.5) and noted the residual external-validity threat

The rule that turns a Revision into an acceptance: **address every criterion.** A criterion that is neither met nor explicitly and reasonably addressed is what the re-check punishes — the discussion lead maps your summary-of-changes back onto the criteria one by one.

Reviewer pushback patterns (automated-SE flavored)

| Pushback | What it signals | ASE-ready response | |---|---|---| | "The baseline tool is not tuned/fair" | Soundness doubt about the comparison | Re-run with an equal, documented budget; report new numbers, or justify the setup | | "Evaluated only on toy or self-selected subjects" | External-validity limit | Add real subject systems, or scope the claim and name the threat | | "The improvement is the model, not your design" | Model-as-contribution doubt | Add the ablation isolating the automation from the model; report marginal value | | "The tool/artifact does not run" | Reproducibility / availability gap | Fix and re-anonymize; describe the run path and re-execution oracle in the response | | "Overlaps prior automation X" | Novelty/delta doubt | Sharpen the delta sentence; add the missing head-to-head comparison |

Anonymity in the response (easy to slip)

• Refer to your own prior work in the third person, as in the paper.
• Describe tool/artifact changes without linking to an identity-revealing repository; use the

anonymized location.

• Do not thank a named collaborator or funder inside the response or the summary-of-changes.

Calibration

• Respond to the criterion the reviewer actually raised, not the one you would rather defend.
• Length and format norms for both turns vary by cycle; confirm the current instructions before

sending.

• The PC discussion (and, for a Revision, the re-check against the stated criteria) decides; write

the response as evidence for an advocate, and make the revised paper — not the letter — carry the argument.

Output format

[Turn] rebuttal / revision summary-of-changes
[Priority issue] <reviewer concern or stated criterion>
[Decision dimension] significance / soundness / evaluation / threats / clarity / data-availability
[Criterion ledger] <criterion -> DONE/PARTIAL/INFEASIBLE + where in paper/artifact>
[Anonymity check] <no identity leak in the response: passed/issues>