| 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
[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 <delta> 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 <other-track> bar of <standard>. Our claim is a
<contribution type> claim; under the track's CFP scope, the evidence in Sec 5
addresses it because <reason>. On your specific concern: <direct answer>.
[R3 - web-fit skeptic]
The method exploits <web-native property>; without it, <what breaks>. Non-web
analogues (e.g., <venue>) do not face <constraint>.
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
- Answer every factual error, however small — uncorrected errors become
meta-review facts.
- Answer the objection most repeated across reviews with the common-thread block.
- Answer the lowest-scoring reviewer's strongest point, not their longest one.
- 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
[Rebuttal plan] <n> reviews: <in-track/adjacent/web-fit/feasibility counts>
[Common thread] <the one issue answered once for everyone>
[New evidence] <small additions only, with source of numbers>
[Concessions] <what is admitted and how the camera-ready will phrase it>
[Anonymity check] pass / fail
[Unverified mechanics] <length cap / format items confirmed in-platform>
