CIKM '26 notifications went out this week, which for a chunk of the field means either a camera-ready sprint or a decision about where to resubmit.

Both are entirely predictable, and most groups handle them as emergencies.

The calendar is known a year out

Major venue dates move by days, not months. Submission, rebuttal, notification, and camera-ready windows are all published well in advance. So are the fallback venues and their offsets from the main cycle.

Which means the question "what happens if this is rejected" has a knowable answer on the day you submit, and almost nobody writes it down.

The three costs of not planning

Rebuttal collisions. Rebuttal periods are short and often overlap with other venues' submission windows. A group with papers in flight at two venues can lose a week to a collision that was visible months earlier.

Dead time after rejection. A paper rejected in August with no identified next venue commonly sits for weeks while people decide. The next appropriate deadline was already on the calendar; the delay is decision latency, not availability.

Camera-ready crunch. Acceptance triggers a fixed, short window for final version, artefact release, and often a video. Teams that have not reserved that time take it out of whatever else was running.

What a planned version looks like

It is not complicated:

1. On submission, record the notification date and the two most likely next venues with their deadlines.
2. Block the rebuttal window in the team calendar as unavailable time.
3. Block the camera-ready window as well, conditional on acceptance.
4. Check for collisions across all in-flight submissions before adding a new one.

This is perhaps an hour of work per submission cycle and removes most of the fire-fighting.

Why it does not happen

Partly because the information is scattered across venue sites in inconsistent formats, and assembling it is annoying enough that people skip it. Partly because rejection planning feels like anticipating failure, which teams avoid discussing.

The first is a tooling problem — the dates are structured data and there is no reason each group should be re-scraping them. The second is a cultural one, and the fix is to normalise having a resubmission plan on the day of submission, when it costs nothing emotionally to write down.

The wider point

Research has few genuinely fixed constraints. Compute varies, collaborators change, results arrive when they arrive. The conference calendar is one of the very few things that is known, stable, and shared across the whole field.

Treating the most predictable constraint as a recurring surprise is a strange way to run a lab, and it is one of the cheaper things to fix.