Webconf Author Response

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:

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

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

[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>

Source: brycewang-stanford/Awesome-Journal-Skills → The-Web-Conference-Skills/skills/webconf-author-response/SKILL.md