--- name: webconf-author-response description: Use when drafting the Web Conference (WWW) rebuttal inside its one-week window, triaging reviews from the venue's mixed systems/mining/social-science reviewer pool, answering misread-track objections, protecting anonymity, and deciding what can honestly be promised for the camera-ready versus what needs new evidence. --- # Web Conference Author Response The 2026 rebuttal window ran November 24 - December 1, 2025 — seven days, scheduled over a major holiday week in North America, between the October 7 paper deadline and the January 13 notification. Plan writing capacity for that specific week the moment the paper goes in. Exact mechanics (length caps, per-review vs. single response, revised-PDF permission) were not published in the sources this pack could verify; confirm them in the review platform the day reviews arrive, before drafting. ## Read the packet as a track artifact Web Conference reviews come from a track-scoped pool, and the venue's defining property is that neighboring tracks read the same paper differently. A recommendation paper reviewed in "User modeling, personalization and recommendation" gets offline-metric and baseline questions; the same paper in "Social networks and social media" gets construct-validity and user-harm questions. Before answering anything, classify each review: | Reviewer stance | Diagnostic signal | Response strategy | |---|---|---| | In-track expert | Names specific baselines/datasets you skipped | Concede or supply numbers; never hand-wave | | Adjacent-track lens | Questions assume a different evidence standard | Restate the track's contribution type, then answer on their terms | | Web-fit skeptic | "Why is this a WWW paper?" | Point to the web-native element: platform data, web-scale constraint, user behavior | | Feasibility doubter | "Would this survive real traffic / real crawls?" | Cite the appendix's systems details by section number | The "why is this a WWW paper" objection is the venue's signature rejection reason and deserves its own paragraph in almost every rebuttal: name the property of the Web (openness, adversarial content, platform incentives, hyperlink structure, live user feedback) without which the contribution would not exist. ## Evidence rules inside the window - New numbers are credible only if small and directly responsive: one extra baseline, one ablation cell, one robustness split. A brand-new experiment campaign announced in a rebuttal reads as an admission the paper was premature. - Anything already in the submission beats anything new. Cite by page, section, and line number (the `review` class option prints line numbers for exactly this). - Keep anonymity intact: no links to freshly pushed repositories or dashboards whose accounts identify you, no "as we showed at ." - Never promise the camera-ready something the 12-page proceedings budget cannot hold. "We will add a full new user study" is a promise reviewers know is either false or destined for an appendix nobody must read. ## Rebuttal skeleton ```text [Common thread] (2-4 sentences shared across reviewers) All reviewers asked about X; the short answer is Y (Sec 4.2, lines 512-530). [R1 - in-track] Q: missing baseline B. A: added; B underperforms ours by on the same split (protocol identical to Table 2). Will appear in Table 2. Q: dataset freshness. A: crawl window and snapshot date are in App. A; we will surface them in Sec 3.1. [R2 - adjacent track] Your reading applies the bar of . Our claim is a claim; under the track's CFP scope, the evidence in Sec 5 addresses it because . On your specific concern: . [R3 - web-fit skeptic] The method exploits ; without it, . Non-web analogues (e.g., ) do not face . ``` One discipline per answer: quote the reviewer's actual sentence, answer it in the first line, then justify. Reviewers reread rebuttals in minutes, not hours. ## Triage when everything cannot be answered 1. Answer every factual error, however small — uncorrected errors become meta-review facts. 2. Answer the objection most repeated across reviews with the common-thread block. 3. Answer the lowest-scoring reviewer's *strongest* point, not their longest one. 4. Concede real limitations explicitly and say what the camera-ready will state. At this venue, a clean concession on scope routinely outperforms a defensive paragraph, because track chairs read rebuttals for calibration as much as content. ## Micro-example: the same objection, answered twice Reviewer sentence: *"The improvements may come from the larger embedding table rather than the proposed crawl-time signal."* Weak answer (defensive, unfalsifiable): > We respectfully disagree. Our method is fundamentally different from simply > increasing capacity, as explained in Section 4. The crawl-time signal is a key > novel contribution and the results clearly demonstrate its effectiveness. Strong answer (evidence-anchored, one new number, page-cited): > Table 3 row 4 already controls for this: the parameter-matched ablation > (identical embedding budget, signal removed) loses 3.8 points (p. 7, lines > 689-702). We add one cell for completeness: doubling the baseline's embedding > table recovers only 0.4 of those points. We will fold this cell into Table 3 > and state the parameter counts in the caption. The differences that matter: the strong answer names the existing evidence by coordinates, adds the *smallest* experiment that decides the question, and ends with a concrete, budget-compatible camera-ready commitment. It also never uses "novel," "fundamentally," or "clearly" — calibration words that track chairs discount automatically. ## After the window Nothing can be added between December 1 and the January 13 notification; do not email chairs with supplements. If the outcome is rejection, the same cycle still offered later routes in 2026 — short papers (November deadlines) closed before notification, but the next edition's research tracks and the current edition's workshop calls remain; route via `webconf-workflow`. ## Output format ```text [Rebuttal plan] reviews: [Common thread] [New evidence] [Concessions] [Anonymity check] pass / fail [Unverified mechanics] ```