brycewang-stanford PPoPP Author Response
Write the rebuttal for the fixed author-response window (PPoPP 2026: 27–29 October 2025). This is a short, word-capped, single written turn — as verified there is no guaranteed revise-and-resubmit round to fall back on. Reviewers read it, discuss, and decide. Spend the budget on the points that can change a verdict, answered with data, not adjectives.
What the window is and is not
- It is a 2–3 day window with a word cap; you cannot run a month of new experiments.
- It is not a debate forum or a place to relitigate taste. It is where you correct factual misreadings and supply the specific number a reviewer said was missing.
- It stays double-blind: reveal no identity, name no cluster/grant, add no author-revealing link.
Triage the reviews first
[Blocking + fixable] a missing baseline you pre-ran; a scaling point you already have;
a misread correctness argument -> answer these first, with data
[Blocking + not fixable in words] a study-design gap needing new machine time
-> concede honestly, scope the claim down, or note it as future work
[Non-blocking] wording, a citation, a minor clarification -> one line each, or skip
Answer the reviewer who is closest to championing you and whose objection is concrete; a reviewer who only questioned novelty rarely decides a systems paper.
The two questions you must be ready for
PPoPP rebuttals live or die on two recurring asks. Prepare for both before reviews arrive
(see ppopp-experiments), because the window is too short to generate the runs from scratch:
- "Does it still scale at higher core counts / on another topology or GPU?" — Have the larger core sweep or the second-machine run already measured. In the rebuttal, give the number: "At 128 cores throughput is ; the curve stays linear to 96 and flattens at 112 due to memory bandwidth, as we now quantify." A concrete point beats "we expect it to scale."
- "How does it compare to baseline X / the state of the art [k]?" — Have the comparison ready. "Against [k] on the same 2-socket node, our structure is × at 64 threads and matches at 4."
Promising to run an experiment "in the final version" does not move a PPoPP reviewer; a measured number does.
Answering a misread correctness argument
If a reviewer misreads your linearizability or progress argument, correct it precisely: point to the linearization point, the specific interleaving they worried about, and why your synchronization (under the named memory model) handles it. Do not restate the whole proof — cite the section and give the one clarifying sentence that dissolves the objection.
Writing mechanics
- Lead with the answer, then the evidence. "Yes — measured: ." Reviewers skim under load.
- Quote the reviewer's ask in a few words so the mapping is unambiguous, then answer it.
- Number your responses to reviewer/point so the discussion can follow them.
- Fit the cap. Cut acknowledgements and restatement; every sentence should either supply a fact or correct one.
- Concede what you cannot fix and say what you will do — a candid, scoped concession reads better than an evasive claim, and reviewers reward honesty in the discussion.
What not to do
- Do not argue that a request is unreasonable; either answer it or scope the claim.
- Do not introduce a new claim the reviewers could not check — it invites suspicion, not credit.
- Do not leak identity: no lab name, no named machine, no personal repo link, even mid-argument.
- Do not spend words on non-blocking nits while a blocking scaling question goes unanswered.
Output format
[Window] author-response dates, word cap
[Triage] blocking-fixable / blocking-not-fixable / non-blocking — points sorted
[Scaling answer] higher-core / second-machine number ready and stated? yes/no
[Baseline answer] comparison to the named competitor ready and stated? yes/no
[Correctness fix] misread interleaving corrected precisely? yes/no
[Anonymity] no identity/machine/grant/repo leak? yes/no
[Cuts] what to drop to fit the cap