First establish what response channel exists this cycle. SIGIR does not have a famous institutionalized rebuttal ritual the way ICLR or KDD do, and whether a given edition runs an author-response or discussion phase for full/short papers was not verifiable for 2026 (待核实 — check the track page and the OpenReview timeline of your own submission). This skill therefore covers three situations: a real response window, no window at all, and the post-rejection letter.
Treat it as a precision instrument, not a second paper. SIGIR reviewers are IR methodologists; the objections cluster predictably, and each cluster has a strongest honest answer:
| Objection cluster | Weak reply | Strong reply |
|---|---|---|
| "Baselines are outdated / not tuned" | "We will add X" | Name the tuning protocol already in the paper (grid, budget, dev split) and cite the table row proving parity of effort |
| "No significance testing" | "Differences are large" | Report the paired test you ran (test, correction, p or CI) with exact table coordinates; if you truly didn't run one, concede and state what you will report |
| "Only one collection" | "Others are future work" | Explain the claim's scope: which property of the collection the claim depends on, and why generalization is or is not asserted |
| "Metric choice hides the effect" | Defend the metric abstractly | Show the effect on the reviewer's preferred metric if it is computable from your runs — run files make this a one-line answer |
| "This is a known result" | Assert novelty | Contrast mechanisms against the specific cited paper: what it does, what yours does, what breaks if the delta is removed |
Rules of engagement:
Then the response happens before submission. Write the paper so the predictable objections above are pre-answered: a tuning-protocol paragraph, a significance-testing sentence under every close comparison, an explicit claim-scope sentence for the collection lineup. Budget half a page of the 9 for pre-emption; it is the cheapest acceptance probability you can buy at a venue where you may never get to talk back.
Reply skeleton per reviewer (aim: fits on one screen)
---------------------------------------------------
Thanks + one-line summary of what we changed/clarify.
[W1] <reviewer's words, 1 line>
-> Answer with coordinates. (Table/§/Fig)
-> If conceded: what we will do, where it will go.
[W2] ...
Closing: the one thing we most want re-weighed, stated once.
Anti-patterns that reliably backfire with IR reviewers:
IR is a small field: the reviewer you bruise this cycle chairs your session next year. Calibrate register per line, not per document:
Too hot: "R2 clearly has not read Section 5, where this is addressed." Too cold: "We thank the reviewer for this insightful comment and will carefully consider it in future work." Right: "§5.2 ¶3 reports this experiment (Table 4, rows 2-3); we agree the pointer from §3 was too subtle and will add a forward reference."
The pattern: locate, concede the findability problem even when the content exists, and commit to the small fix. Reserve firm disagreement for factual errors, and spend it at most once per reviewer — a response that disputes everything is read as disputing nothing.
Because run files exist (if sigir-artifact-evaluation was followed), several
reviewer requests are answerable in hours without new training:
ir_measures.[Response channel] confirmed window / none this cycle / post-rejection
[Reviewer map] R1: <stance, key ask> | R2: ... | R3: ...
[Triage] answerable-with-coordinates / concede-and-fix / out-of-scope
[New-evidence budget] <what, if anything, gets computed during the window>
[Resubmission route] next SIGIR cycle / SIGIR-AP R&R / ECIR / CIKM / WSDM / TOIS
[One ask] <the single re-weighing request to close with>