brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
sigir-author-responseUse when reviews arrive for a SIGIR submission and the authors must decide how to answer — triaging IR-reviewer objections (weak baselines, missing significance tests, collection choice), writing within whatever response mechanism the current SIGIR cycle actually offers, and planning the resubmission path if the answer is no.
Independent GitHub snapshot · Automated classification · Original documentation governs
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>