sigmod-author-response

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 <company>" 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).

| Letter component | What reviewers expect | Frequent failure |

|---|---|---|

| Change inventory | Requirement-by-requirement table, each mapped to an edit | Narrative essay with no map |

| Color key | One color per reviewer, stated up front | Uniform highlighting nobody can attribute |

| New evidence | Requested experiments actually run, numbers in the paper | Results only in the letter, not the paper |

| Declined requests | Explicit, reasoned, respectful refusal | Silent omission discovered on re-review |

| Locators | Section/page/line for every edit | "See revised Section 5" with no page |

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.

1. Classify each as: run new experiment / rewrite / clarify / decline.
2. Budget the single extra page before writing — decide which requirement

owns it, because two half-answers waste it.

1. Draft edits in the paper first, the letter second; a letter written before

the edits describes intentions, not changes.

1. 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>