Model the pipeline before interpreting any single review. PPoPP runs a single-round, double-blind conference review with a scheduled author-response rebuttal and an unusual safety net: papers not accepted for a talk are automatically considered for posters. The most consequential mental shift for authors arriving from a journal-style venue is that there is (as verified) no guaranteed revise-and-resubmit round — the rebuttal is your one written turn, so it must land.
| Axis | What they check | Common failure |
|---|---|---|
| Parallelism as the contribution | Is the concurrency/parallel-performance the point? | A compiler/theory result wearing a parallel costume (a CGO/POPL reroute) |
| Correctness under concurrency | Races, linearizability/progress, the memory model | "It passed my tests" with no argument about interleavings |
| Scalability | Speedup curves, core sweeps, NUMA/GPU, saturation | One thread count; a win that vanishes on another topology |
| Baseline honesty | Comparison to the strongest real competitor | Beating a strawman or the authors' own unoptimized code |
| Measurement rigor | Variance, warm-up, pinning, repeated runs | A single-run bar chart with no error bars |
| Reproducibility | Enough to re-run; an artifact | Hardware and topology unstated |
| Decision | What it means | Author move |
|---|---|---|
| Accept (talk) | Contribution and evidence hold | Camera-ready + artifact; do not reopen scope |
| Poster (auto-considered) | The idea is of interest but not a full talk this cycle | Decide in advance whether the 2-page proceedings summary is worth it |
| Reject | Structural: wrong scope, weak baseline, no scaling story | Reframe or reroute (CGO/PLDI/ASPLOS/SC or a later round) |
| "Revision" (if offered — 待核实) | Repairable gaps within a bounded window | Treat as an R&R; make or explicitly decline every request with evidence |
The strategic reading: because there is (as verified) one written turn, design the submission so its weakest point is answerable in the rebuttal with a number you already have (a pre-run baseline, an extra core-count) rather than something requiring a month of new machine time.
acmart sigplan, 10 pages).[Before submission] abstract + topic tags -> TPMS/PC matching (largest early lever)
[Initial reviews] factual corrections, a pre-run number, a clarified interleaving argument
[Rebuttal] the decisive turn: answer "does it scale?" and "baseline X?" with data
already in hand, within the word cap
[After reject] no appeal; reroute to a co-located sibling or the next round
A rebuttal moves borderline papers when it supplies a scaling point or a baseline a reviewer said was missing; it does not move papers when it argues taste or promises future experiments. The classic PPoPP loss is a reviewer asking "how does this behave at 128 cores / on a second GPU?" and the authors having only the one machine's numbers.
Weight reviews before answering. A review that cites your speedup figure, your baseline choice, and your correctness argument was read closely; answer each reviewer on the axis they raised — correctness reviewers with an interleaving argument, performance reviewers with a number. A review that only questions novelty has left soundness to the others; do not spend your word budget there.
[Process stage] pre-submission / awaiting reviews / rebuttal / decided
[Decision] accept / poster / reject / revision(if offered), with the driving criterion
[Criterion map] each review point -> parallelism-as-point | correctness | scalability | baseline | measurement | reproducibility
[Leverage plan] the rebuttal number or correction that can actually change the outcome
[Forbidden moves] identity leak / promised-but-unrun experiments / arguing taste