CIKM's response mechanics are genuinely cycle-dependent: no official statement confirming or denying a 2026 rebuttal phase could be retrieved (source map, 2026-07-08, 待核实). This skill therefore covers all four author-side writing situations around CIKM reviews, with the no-window case treated as the default — because when there is no rebuttal, the reply to reviewers gets written anyway, just in different documents.
| Situation | The document you actually write | Governing constraint |
|---|---|---|
| A response window opens | Anonymous reply inside EasyChair | Announced word/format rules; anonymity persists |
| No window, paper accepted | Camera-ready revision note | Address concerns without exceeding accepted scope |
| No window, paper rejected | Resubmission brief for the next venue | Honest triage, no venue-blaming |
| Factual process error | Confidential note to PC chairs | Facts only; never argue merit this way |
CIKM reviews arrive from up to three community lanes (cikm-review-process), so a
good reply is organized by reviewer, not by theme — each lane's reviewer should find
their own objection answered in their own vocabulary:
Reviewer: "Complexity analysis suggests quadratic blow-up on dense graphs; the experiments avoid this regime."
Reply skeleton: (a) confirm the reading is correct for worst-case density; (b) point to the submitted Table/appendix entry showing observed scaling on the densest tested graph; (c) state the density regime of the target application and that the claim is scoped to it; (d) offer a one-sentence camera-ready scope clarification. Four moves, no new experiments, no evasion.
The August 7 → August 20 camera-ready sprint (2026 dates) is where reviewer concerns
get answered in practice. Build a concern → edit ledger: every substantive review
point maps to a camera-ready change, a scoped-limitation sentence, or a reasoned
no-change. Keep the ledger; if the proceedings process or a chair asks what changed,
the answer is ready, and cikm-camera-ready consumes it directly.
Write it within a week, while context is fresh:
cikm-workflow fallback choice.CIKM's communities have different argument cultures — IR discussion leans protocol-precise, mining leans delta-and-numbers, KM/database leans systems-pragmatic — but one register works for all three: technical, specific, and unwounded. Practical rules:
Response mechanics are exactly the kind of fact this venue changes per cycle, so before drafting anything reviewer-facing:
[ ] Reopen the current cycle's author instructions / notification email:
does a response channel exist at all this year?
[ ] If yes: word/character limit, format, deadline (AoE?), and whether
new results or links are permitted or barred
[ ] Anonymity rules during the window (assume double-blind persists)
[ ] Who may submit: contact author only, or any author?
[ ] For chair notes: the stated contact route on the host site, not a
guessed email address
Every item comes from the current host site or EasyChair instance — the 2026 source map deliberately records the rebuttal question as unresolved (待核实), and this checklist is how it gets resolved for whatever cycle is live.
Whatever the channel — window reply, camera-ready note, or chair correspondence — hold to roughly a page of substance per audience. Beyond that length, the reader is skimming, and a skimmed concession does as much damage as an unmade one. If the honest response needs three pages, the paper had three pages of problems; choose the one whose resolution changes the decision and spend the page there.
[Situation] response-window / camera-ready note / resubmission brief / chair note
[Per-reviewer leads] <R1/R2/R3: the concern each block opens with>
[Evidence anchors] <submitted section/table/artifact per concern>
[Concessions] <scoped limits admitted, in one line each>
[Deliverable deadline] <window close / Aug-20-style camera-ready gate / next venue gate>