nsdi-workflow

name	nsdi-workflow
description	Use when planning an NSDI campaign across the spring and fall deadlines — sequencing abstract and paper gates, notification waits, one-shot revision windows, artifact evaluation, and the May symposium — so a networked-systems project always knows which of the two yearly gates it is really building toward.

NSDI Workflow

NSDI is a calendar problem disguised as a conference. One edition, two submission gates, two decision cohorts, and a revision mechanism that spans deadlines — a team that plans "for NSDI" without naming the gate usually discovers it planned for neither. Dates below are the NSDI '27 cycle as rendered on 2026-07-08; treat them as this cycle's snapshot and re-pull the HotCRP /deadlines pages before acting.

The '27 clock

Gate	Date (11:59 pm US EDT)	Cohort
Spring abstracts	April 16, 2026	spring
Spring full papers	April 23, 2026	spring
Spring notification	July 23, 2026	spring
Fall abstracts	September 10, 2026	fall
Fall full papers	September 17, 2026	fall
Fall notification	December 8, 2026	fall
Symposium	May 11-13, 2027, Providence, RI	both

Where "today" (2026-07-08) sits: spring authors are two weeks from notification; a fresh submission has nine weeks to the fall abstract gate. Camera-ready dates and the '27 artifact schedule were not yet rendered — 待核实, watch the conference page.

One project, four legal paths through the cycle

Path A  fall '26 submit -> accept (Dec 8) -> final paper + AE -> present May '27
Path B  fall '26 submit -> one-shot revision -> resubmit spring '27 (next edition)
Path C  fall '26 submit -> reject -> BARRED from spring '27; rework for fall '27
Path D  spring '26 one-shot revision (notif Jul 23) -> revise -> fall '26 resubmit

Path C is the one teams forget: a plain rejection carries a one-deadline ban, so the cheapest-looking option — "just submit and see" — silently spends two deadlines, not one. Build the decision into the plan: submit only when the evidence would survive review, otherwise hold for the next gate and use the time on the testbed.

Working backward from a gate

A fall-2026 target, walked backward:

• T-9 to T-6 weeks: freeze the design; the evaluation plan (workloads, baselines, scale points) written down and reviewed as if it were the paper (nsdi-experiments). Trace collection and testbed reservations start now — cluster time is the resource that cannot be compressed in deadline week.
• T-6 to T-3: experiments run continuously with provenance capture (nsdi-reproducibility); the paper skeleton fills section by section (nsdi-writing-style); related-work sweep across both NSDI cohort lists of the current edition (nsdi-related-work).
• T-2: full internal read against the 12-page budget; appendix triage (nsdi-supplementary).
• T-1 week (Sept 10): abstract, authors, track, and conflicts registered on the fall HotCRP site. The abstract gate is a hard prerequisite, not a formality.
• T-0 (Sept 17): final PDF through the submission audit (nsdi-submission), uploaded and marked complete with hours to spare.

The waits, and what to do inside them

NSDI's review silences are long (spring: April to late July; fall: September to early December). Productive uses that pay off regardless of outcome:

• Harden the artifact toward badge evaluation — the accept-case deliverable (nsdi-artifact-evaluation), and the Community Award requires public code/data by the final-papers deadline.
• Keep the testbed alive and re-runnable; a one-shot revision letter often demands new experiments on a 3-4 month fuse, and a decommissioned cluster turns a feasible revision into a forfeit.
• Draft the extension or the next paper; do not submit the same work elsewhere — concurrent submission violates USENIX policy.

Revision-window management (path B/D)

A one-shot revision arrives with a reviewer-authored list of required issues and a deadline implied by the next submission gate. Run it as a mini-project:

1. Within a week: map every required issue to an owner and a cost (new experiment, new analysis, rewrite).
2. Reserve infrastructure immediately for any issue needing measurements.
3. Maintain the change-highlighted PDF and the change-summary memo as you go — both are mandatory auxiliary material at resubmission (nsdi-author-response).
4. Freeze two weeks before the gate; a revision that misses its window or dodges an issue is rejected with no further revision option.

Choosing between the gates when both are open

Early in a cycle, spring-vs-fall is a real decision, not a default:

• Spring favors projects whose evaluation is already running: an accept yields ten months of artifact and presentation runway, and even a one-shot revision recycles into the same edition's fall gate (path D) — the gentlest failure mode NSDI offers.
• Fall favors projects still building: five more months of testbed time, at the cost of a compressed post-accept pipeline and a revision that lands in the next edition.
• Never split one paper across both by submitting a weak spring version as a placeholder — the rejection ban (path C) converts that hedge into exclusion from the very fall gate the team was counting on.

Standing risks with named owners

• Gate confusion — someone plans for "the NSDI deadline" without saying which. Owner: project lead; fix: every milestone names spring/fall + year.
• Time-zone drift — '27 uses US EDT where '26 used PDT; a reused conversion table is an hour-scale landmine. Owner: submitter of record.
• Cap collisions — eight submissions per author per edition across both deadlines; large groups reconcile author lists before each abstract gate. Owner: most-senior common author.
• Infrastructure decay during waits. Owner: artifact lead.

Output format

[Target gate] spring / fall + year (papers due <date>)
[Today's position] weeks to next gate; cohort status of any pending submission
[Backward plan] milestone -> week -> owner
[Ban check] any cohort-ban or revision window constraining this plan?
[Wait-time tasks] artifact / testbed / next-paper assignments
[Top schedule risk] <one item + mitigation>