Skills Soft Skills Structuring Technical Author Rebuttals

Structuring Technical Author Rebuttals

v20260724
pldi-author-response
Provides comprehensive guidelines for authors responding to reviewer objections after a major technical conference submission (e.g., PLDI). It details how to triage structural critiques—including factual errors, soundness doubts, and evaluation gaps—and emphasizes maintaining academic rigor, adhering strictly to the original scope, and avoiding promises of unproven new contributions.
Get Skill
146 downloads
Overview

PLDI Author Response

PLDI 2026 gave authors a five-day response window, February 17-21, 2026, between review delivery and the March 5 notification (dates from pldi26.sigplan.org, read 2026-07-08; every cycle re-times this). The response is read by people who build compilers and verifiers for a living: precision beats rhetoric, and a pointer into your own submitted PDF beats a paragraph of reassurance.

Triage before writing

Sort every reviewer point into one of four buckets and answer them in this order:

Bucket Example at PLDI Correct move
Factual error "The analysis ignores exceptions" when §4.2 handles them Quote §4.2 verbatim, one sentence of context
Soundness doubt "Theorem 2 seems to assume no reentrancy" State the assumption's exact location; if the reviewer is right, say what the fix costs
Evaluation gap "No comparison against the LLVM baseline at -O2" Give the number if it exists in your logs; otherwise commit to the exact experiment, not to "more evaluation"
Scope disagreement "Why not handle JIT compilation?" Defend the stated scope; do not promise to widen it

A soundness doubt outranks everything. One reviewer convinced your core theorem or transformation is broken outweighs three asking for extra benchmarks, so spend your first and best paragraph there.

Rules that keep responses alive

  • Answer the question asked. Implementor-reviewers notice deflection immediately; a direct "yes, our technique fails on X, and here is why the claim survives" earns more than a hedge.
  • No new contributions. New numbers are acceptable only when they answer a direct question and come from the already-described setup — for instance, a requested baseline flag configuration. A new algorithm or proof in a rebuttal reads as an admission the submission was premature.
  • Quote yourself by section and line, not by memory. Reviewers reread exactly what you cite; a wrong pointer costs credibility twice.
  • Budget by damage. Give the most negative substantive review the most space; do not spend a page thanking the champion reviewer.
  • Stay anonymous. Double-blind persists through the response; no links that resolve to your lab.

A working skeleton

We thank all reviewers. We first address the soundness question (Rev B),
then the baseline request (Rev A, Rev C), then smaller points.

[B1: soundness of Thm 2 under reentrancy]
Assumption A3 (§5.1, p.12) excludes reentrant callbacks; the proof uses it
in Lemma 4. We will state A3 in the theorem statement itself. The
restriction removes 2 of 14 benchmark programs (§6.1 already notes this).

[A2/C3: -O2 baseline]
Our logs include this configuration: geomean 1.11x vs 1.17x reported.
We will add the column to Table 4.

[C5: JIT scope]
Out of scope by design (§2); AOT-only assumptions are used in §4.3.

After the window

Archive the response beside the submitted PDF. If the decision is acceptance, your camera-ready and artifact must actually deliver every "we will" sentence — PLDI reviewers routinely check; see pldi-camera-ready and pldi-artifact-evaluation. If it is rejection, the response doubles as the revision plan for the next November.

Output format

[Decisive issue] <the one objection that moves the decision>
[Bucket map] Rev A: ... / Rev B: ... / Rev C: ...
[New-number policy] <what may be cited, from which logged runs>
[Commitments] <numbered, feasible, camera-ready-sized>
[Anonymity check] pass / fail
Info
Category Soft Skills
Name pldi-author-response
Version v20260724
Size 3.8KB
Updated At 2026-07-28
Language