Write rebuttal

Write Rebuttal

Distilled from Devi Parikh, Dhruv Batra & Stefan Lee, How we write rebuttals (https://deviparikh.medium.com/how-we-write-rebuttals-dc84742fece1).

A rebuttal exists to clarify and convince — it is one stage in a deliberative scientific process, not a fight to win. Optimize it for the reader, not for venting.

The one idea that governs everything

Two audiences, and beginners forget the second one:

1. Reviewers — read your paper, may have forgotten details. Goal: clarify doubts, correct misunderstandings, push back on mischaracterizations, incorporate feedback.
2. Area Chair / meta-reviewer — likely has not read your paper closely and won't re-read it. Goal: show good-faith effort, give a fair summary, make it obvious each concern was addressed, flag bad-faith reviewing, and help them decide.

Most new researchers write only for (1). Writing for (2) is what moves decisions. Think of it like debate: you convince the judges (AC), not your opponents.

The acceptance test for every response — the "neutral third-party" test: Could someone who has not read your paper or the reviews tell, from your rebuttal alone, that the concern was addressed? If not, rewrite it (self-contained; Tip 8).

Process (do these in order)

1. Itemize — put every reviewer comment/question/concern in a spreadsheet, one row each, columns per reviewer. Do this first, ASAP: it guarantees nothing is missed, surfaces shared concerns to consolidate, and identifies needed experiments early while there's still time to run them.
2. Brain-dump — rough responses in the sheet, no style/length worry. Collaborative.
3. Draft — turn the consensus into concise responses covering every point.
4. Revise — reread the reviews, check completeness, prioritize the majors, fit the space limit. Run the neutral-third-party test on each response.

See references/rebuttal-skeleton.md for a ready structure (summary → common concerns → per-reviewer → note to AC), micro-templates, and two AC "dashboard" summary tables. assets/rebuttal-template.tex is the compilable LaTeX implementation — use it only where free-form PDF responses are accepted.

The 18 tactics (apply while drafting)

Full detail + examples in references/eighteen-tips.md. The load-bearing ones:

• Start positive (1) — open with a short recap of the praise; don't let strengths be forgotten.
• Order by strength, not by reviewer (2) — lead with the biggest concerns you have good answers for; trail minor/weaker points.
• Quote → direct answer → detail (3) — quote the concern, answer Yes/No/one line in bold first, then elaborate.
• Stats speak louder than words (12) — whenever you disagree with a reviewer, back it with a number, not an argument. Ask "can I establish this with data?"
• Don't promise, do (13) — compute the number/analysis now and put it in the rebuttal; then say you'll fold it into the paper. Never leave "we will add X" as the whole answer.
• Get credit for what's already there (9) — if they asked for something in the paper, cite the line/section and restate it.
• Be transparent (15) — venue bars new experiments? no clean intuition? out of GPUs? result is null? Say so honestly and reframe — do not overclaim.
• Answer the intent, not just the literal question (5), be self-contained (8), consolidate shared concerns (10), thank real effort (17), and remember the humans (18) — seek common ground unless a reviewer is bad-faith (16).

Applying it to rebuttal experiments

The guide shapes what you run, not just how you write:

• Itemize first (Step 1) to derive the experiment list from concerns, then map each experiment to the exact sentence/slot it will fill.
• Tip 2 + 13: prioritize experiments that will reliably yield a clean, defensible number inside the response window over high-variance gambles. A promised experiment that doesn't land is worse than a transparent limitation (Tip 15).
• Tip 12: prefer designs that end in a statistic (effect size, CI, p-value, a baseline delta) — that is the currency of a rebuttal.
• Tip 14 (be receptive): when a reviewer proposes a baseline/ablation, try it — "maybe it will work" — rather than arguing why it wouldn't.
• Never pre-write the outcome. If a response sentence already asserts a result ("the increase is significant") before the experiment is run, that violates Tips 13 and 15 — fill it only with the computed value, or reframe to what the data supports.

Anti-patterns (auto-reject in review)

• A response that fails the neutral-third-party test (needs the paper to make sense).
• "We will add / we plan to" with no number in the rebuttal itself (violates 13).
• Ordered reviewer-by-reviewer with the weakest answer first (violates 2).
• Arguing a point you could have measured (violates 12).
• Combative tone, litigating instead of clarifying (violates 4, 18).
• Silent overclaim of a result the data doesn't yet support (violates 13, 15).
• Ignoring the AC entirely — no decision-oriented summary (the core miss).

Optional check

python scripts/lint_rebuttal.py <rebuttal.tex|.md> flags promise-language ("we will add", "in the final version"), unfilled placeholders (\Rtodo, TODO, [\ldots]), outcomes asserted next to unfilled slots, a missing AC section, a missing opening thanks, and the absence of any statistics. Advisory only — judgment still yours.