| 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:
- Within a week: map every required issue to an owner and a cost (new experiment,
new analysis, rewrite).
- Reserve infrastructure immediately for any issue needing measurements.
- Maintain the change-highlighted PDF and the change-summary memo as you go — both
are mandatory auxiliary material at resubmission (
nsdi-author-response).
- 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>
