SIGMOD Author Response

SIGMOD gives authors two distinct speaking turns per round, and they play by different rules. The mid-round author feedback phase (about a week, two months after submission — e.g., Sep 10–17, 2026 for Round 3 of SIGMOD 2027) is a short clarification exchange before first verdicts. The revision letter accompanies a resubmission after a major or minor revision decision and is a full engineering document. Confirm the current round's mechanics in the live CFP before drafting either.

Turn 1: the feedback phase

• Correct factual review errors first: a misread experiment, a baseline the reviewer missed, a theorem condition quoted wrong.
• Answer direct reviewer questions with pointers into the submitted PDF — section, table, and figure numbers, not paraphrase.
• Do not promise future experiments as if they were done; the revision phase exists precisely so that promised work can be delivered and re-checked.
• Preserve anonymity absolutely: no institutional context, no "in our production deployment at " slips.
• Stay inside whatever length box CMT enforces this cycle; verify it live.

Turn 2: the revision letter

A revision verdict at SIGMOD is an offer with a contract. For SIGMOD 2027: the revised paper may add one extra content page, the letter runs up to four pages, and every change must be highlighted in a different color per reviewer, cross-referenced by section and page (line numbers when possible).

Revision triage order

1. Extract every sentence in the meta-review and reviews that states a requirement; number them R1.1, R2.1, and so on.
2. Classify each as: run new experiment / rewrite / clarify / decline.
3. Budget the single extra page before writing — decide which requirement owns it, because two half-answers waste it.
4. Draft edits in the paper first, the letter second; a letter written before the edits describes intentions, not changes.
5. Re-run the anonymity sweep on everything new: fresh plots, new repo snapshots, and added acknowledg— no, still none allowed.

Skeleton letter

Revision letter — Submission #NNN (Round k)
Color key: R1 = blue, R2 = orange, R3 = green.

R1.1 (required) "Compare against <baseline> on skewed workloads."
  Done. New Sec 6.4, Fig 9 (p. 11, blue). <Baseline> tuned per its
  authors' guidance; config in Appendix B.
R1.2 (suggested) "Discuss recovery cost."
  Added one paragraph, Sec 5.2 (p. 8, blue).
R2.1 (required) "Clarify the consistency guarantee under partition."
  Rewrote Sec 4.1 (p. 6, orange); the guarantee is unchanged, the prose
  overstated it. We now state exactly what is and is not guaranteed.
R3.1 (declined) "Port the engine to <other system>."
  We explain in Sec 7 (p. 12, green) why the design is engine-agnostic;
  a full port exceeds a revision cycle and does not test the claim.

Deadline geometry

The revision window is one month (e.g., verdict Oct 19 → revised paper Nov 19 for Round 3 of SIGMOD 2027), with the final accept/reject about three weeks later. Reviewers evaluate only whether the stated requirements were met — a revision is not an invitation to add a new contribution, and scope creep reads as instability. Withdrawing instead of revising counts as a rejection for the 12-month embargo, so price that before walking away.

Feedback-phase micro-example

Reviewer question: "Figure 7 shows your system slower than Baseline B at low thread counts — this seems to contradict the Section 3 claim."

Weak reply: "Thank you for the careful reading. Our system is designed for high concurrency, and we believe the low-thread regime is less relevant in practice."

Strong reply: "Sec 3's claim is scoped to contended workloads (p. 4, lines 12-14): under 8 threads there is no contention to remove, so we pay our bookkeeping overhead (quantified at 4-7% in Tab 3) without benefit. Fig 7 is consistent with that scoping; we will make the boundary explicit in the Fig 7 caption."

The strong version concedes the measured fact, cites its own scoping, and prices the overhead — three moves in four sentences, no adjectives.

Tone calibration for a systems audience

• Concede real bugs plainly and show the corrected numbers; database reviewers forgive errors faster than they forgive spin.
• Quantify every "we clarified" with what a reader can now compute or verify that they could not before.
• Never argue that a requirement is unreasonable in the feedback phase; argue it, if ever, in the letter with evidence.

Output format

[Phase] feedback window / revision letter
[Requirement ledger] Rk.n -> done / partial / declined, with locator
[Extra-page plan] which requirement owns the added page
[New-evidence risk] experiments promised vs. actually landed
[Anonymity re-check] pass or leak found in new material
[Send-readiness] ready / blocked on <item>