infocom-review-process
GitHub解析IEEE INFOCOM论文评审流程，涵盖双盲、自动分配、早期拒稿及无作者反驳机制。对比SIGCOMM/NSDI，指导作者通过完善初稿应对评审，分析不同决策结果并规划后续修改或重投策略。
触发场景
安装
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill infocom-review-process -g -y
SKILL.md
Frontmatter
{
"name": "infocom-review-process",
"description": "Use when reasoning about how an IEEE INFOCOM submission is evaluated, covering the large-scale double-blind pipeline, automated paper-reviewer assignment, the two-tier TPC and early-reject phase, the (traditional) absence of an author rebuttal, TPC discussion, and how INFOCOM's process differs from SIGCOMM\/NSDI rebuttal-driven reviewing."
}
INFOCOM Review Process
Model the pipeline before interpreting any single review. INFOCOM's process is large-scale and TPC-driven: thousands of submissions are matched to a broad Technical Program Committee by an automated assignment system, screened through an early-reject phase, and decided in TPC discussion. The most consequential mental shift for authors arriving from SIGCOMM/NSDI is that INFOCOM has traditionally offered no author rebuttal — the submitted PDF must defend itself, because you likely never get a turn to reply.
Process model
- Submission and review run on EDAS with double-blind anonymity: identities are hidden from reviewers throughout.
- Automated review assignment matches each manuscript to TPC members by comparing the paper's content to reviewers' representative publications. Your topic tags and abstract are the levers that route you to the right subarea — a mis-tagged paper lands with reviewers who read it as a visitor.
- Early-reject phase. INFOCOM 2027 posts an early-reject notification (9 Oct 2026) weeks before the final acceptance notification (8 Dec 2026). Papers that are out of scope, violate the double-blind/length rules, or draw uniformly weak initial scores are cut here without reaching the full discussion.
- TPC discussion and final decision (INFOCOM 2026: 8 Dec 2025). Surviving papers are debated by the assigned TPC members, often with an area/vice chair moderating, and accepted or rejected.
- Accepted papers publish in the IEEE INFOCOM Proceedings and IEEE Xplore.
Reading a decision against the categories
| Decision | What it means | Author move |
|---|---|---|
| Early reject | Screened out before full discussion: scope, compliance, or uniformly low scores | Do not appeal; diagnose honestly and reroute or substantially rework |
| Reject (final) | Survived the screen but lost in discussion: a real weakness the reviewers agreed on | Reframe or reroute (SIGCOMM/NSDI/ICNP or a journal); fix the named weakness before resubmitting |
| Accept | Contribution and evidence hold | Camera-ready + IEEE Xplore production; register an author |
Because there is usually no rebuttal, the strategic reading runs before submission: anticipate the reviewer's first objection (an untuned baseline, an unstated assumption, a proof gap) and close it in the PDF, since you will not get to close it in a reply.
How INFOCOM differs from its siblings
- vs. SIGCOMM / NSDI: those are small, highly selective ACM/USENIX venues with a rebuttal and a systems-building, artifact-heavy culture. INFOCOM is large, IEEE, double-blind on EDAS, with automated assignment, an early-reject screen, and (traditionally) no rebuttal — and it welcomes analytical/optimization contributions that SIGCOMM often routes elsewhere.
- vs. ICNP: ICNP is a smaller IEEE protocols venue; INFOCOM's breadth and scale are its identity. Do not assume a shared reviewer pool or timeline.
- vs. IEEE/ACM ToN or JSAC: the journals have no page ceiling and a revise-and-resubmit cycle; INFOCOM is a single-shot conference decision with a hard nine-page budget. A study too long or too incremental for INFOCOM's page limit may belong in the journal.
Who reads you
Expect a handful of TPC reviewers drawn by the assignment system from your declared subarea. In a broad venue they may span pure theory to pure systems, so a paper must be legible to both: an optimization result needs an intuition and a plausible deployment story; a systems result needs its assumptions and a fair comparison. Vague method descriptions and unfair baselines are the classic INFOCOM rejects — reviewers in a crowded pool reward papers that are easy to check and hard to dismiss.
Where author leverage actually exists
[Before submission] topic tags + abstract -> reviewer pool via automated assignment (largest lever)
[In the PDF] pre-empt the obvious objection; the paper is your only argument
[Early-reject stage] no appeal; treat the cut as signal, not noise
[After reject] no rebuttal existed to blame; fix the named weakness, reroute or resubmit next cycle
[If a cycle adds a response window] answer only the decision-critical, verifiable points (待核实)
Since the traditional process gives no reply turn, the highest-leverage move is defensive writing: the threats to a claim, the assumption behind a theorem, and the fairness of a baseline must all be visible in the submitted pages.
Misreadings to avoid
- Expecting a rebuttal. Do not hold back an answer "for the response" — there usually is none (verify the current cycle; 待核实).
- Treating early-reject as a fluke. It is a deliberate screen; a uniform low score means the paper did not read as INFOCOM-ready.
- Under-tagging the topic. The automated assignment is only as good as your metadata; wrong tags route you to the wrong readers.
- Assuming SIGCOMM norms. Artifact-heavy, rebuttal-driven expectations do not transfer.
Output format
[Process stage] pre-submission / under review / early-reject / final decision / accepted
[Decision category] early-reject / reject / accept, with the criterion driving it
[Assignment risk] do topic tags + abstract route to the right subarea? yes/no
[Defensive-writing gaps] <objections to pre-empt in the PDF, since no rebuttal>
[If response window exists] <the decision-critical points to answer (待核实 the window itself)>
版本历史
- 9f86f09 当前 2026-07-19 16:02
