| name | icalp-review-process |
| description | Use when reasoning about how an ICALP (EATCS) submission is evaluated, covering lightweight double-blind review, the separate Track A and Track B program committees, the asymmetric author interaction (Track B rebuttal vs Track A correctness-only contact), correctness-driven acceptance, the single accept/reject decision, and how ICALP's process differs from STOC/FOCS/SODA. |
ICALP Review Process
Model the pipeline before interpreting any single review. ICALP's process is conference-style and
correctness-centered: a paper is accepted or rejected in one round (no journal-style major
revision), and the reviewers' overriding job is to judge whether the theorems are significant and
the proofs are correct. The most consequential thing to internalize is that the two tracks run
different processes — Track B gives you a rebuttal, Track A generally does not.
Process model
- Submission and review run on HotCRP, on separate servers per track, under lightweight
double-blind: identities are hidden for an unbiased first read, self-references are third person,
but the regime is deliberately not adversarial about de-anonymization.
- Each paper is refereed by the track's program committee (often with sub-reviewers who are
subject experts), who weigh the significance of the result, the correctness and depth of the
proofs, the improvement over prior bounds, and clarity.
- Track A (Algorithms, Complexity and Games): chairs for ICALP 2026 are Sayan Bhattacharya and
Danupon Nanongkai (reported). Authors are contacted only if a correctness issue must be
resolved — otherwise there is no interaction.
- Track B (Automata, Logic, Semantics and Theory of Programming): chaired by Michael Benedikt
(reported). There is a rebuttal period (ICALP 2026: 21-24 March) where authors respond to
initial reviews.
- Decisions are accept / reject in one round; accepted papers publish open-access in LIPIcs.
Reading a decision against the criteria
| Decision | What it usually means | Author move |
|---|
| Accept | Result significant, proofs judged correct, improvement over prior work is clear | Camera-ready in LIPIcs; post/refresh the full version; arrange a presenter |
| Reject (borderline) | Correct but incremental, or a proof gap the referees could not close in time | Strengthen or reframe; consider STOC/FOCS/SODA/LICS or a journal (icalp-topic-selection) |
| Reject (structural) | A proof is wrong or the model/claim is off | Fix the mathematics before resubmitting anywhere; do not merely re-target |
The strategic reading: because there is no revision round, the submission must be correct and
complete at deadline. A believable-but-unwritten proof is the classic ICALP rejection — reviewers
cannot accept what they cannot check in the appendix or full version.
How ICALP differs from its US siblings
- vs. STOC / FOCS: those are ACM/IEEE flagships with their own PCs, templates, and calendars, and
a US-centered community. ICALP is EATCS/European, LIPIcs open-access, and two-track. Prestige
and pool differ; never assume a shared calendar or format.
- vs. SODA: SODA is SIAM's algorithms venue with a distinct community and its own reviewing style.
ICALP Track A overlaps in scope but is a different program committee and audience.
- vs. journals: ICALP is single-round accept/reject, not revise-and-resubmit. There is no major
revision; a paper that needs one belongs in a journal (LMCS, TALG, TCS, JACM) or a later cycle.
Who reads you
Expect subject-matter referees for your specific subarea and track — a matroid result is read by
someone who knows matroid intersection; a VASS result by someone who knows Petri nets. They will
check the proofs, not skim them, which is exactly why the full version / appendix must be complete.
A vague proof sketch with "details omitted" and no full version is caught, not trusted.
Where author leverage actually exists
[Before submission] track choice + clean model + complete proofs (largest lever)
[Track A] essentially none post-submission except a correctness clarification if asked
[Track B rebuttal] correct factual misreadings; point to the exact lemma answering an objection
[After reject] no appeal; reroute to a sibling venue or journal, having fixed the mathematics
For Track B, a rebuttal moves a paper when it fixes a misread ("the reviewer thinks Lemma 4
needs X, but the hypothesis already gives it, see line ...") — not when it argues taste. For Track
A, the lever is almost entirely before submission: get the proofs complete and the exposition
clear, because you will likely not get to speak again.
Reading a review packet
Weight reviews by how closely the proof was read. A review that cites your lemma numbers and questions
a specific step engaged the mathematics and is your most important reader — answer that step exactly
(Track B) or make sure it is airtight (Track A). A review that discusses only novelty has left
correctness to the others. Reviewers who flag a potential gap are giving you the single most
important signal: if they are right, no rebuttal saves it; if they misread, a precise pointer to the
proof can.
Misreadings to avoid
- Expecting a revision round — there is none; the submission is the artifact of record.
- Assuming a Track A rebuttal — Track A contacts you only for correctness; do not bank on
responding.
- Treating "details in the full version" as sufficient without the full version — reviewers must
be able to check the proof at submission time.
- Projecting a US-venue process onto ICALP — the two-track split and the rebuttal asymmetry are
ICALP-specific.
Output format
[Process stage] pre-submission / under review / Track B rebuttal / notified
[Track] A (correctness-contact only) / B (rebuttal)
[Decision criterion] significance / correctness / improvement-over-prior / clarity
[Proof-check risk] any headline theorem whose full proof a referee cannot currently verify?
[Leverage plan] the next-stage action that can actually change the outcome
[Forbidden moves] shipping an unproved claim / arguing taste in a rebuttal
