nsdi-workflow

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).

1. Reserve infrastructure immediately for any issue needing measurements.
2. Maintain the change-highlighted PDF and the change-summary memo as you go — both

are mandatory auxiliary material at resubmission (nsdi-author-response).

1. 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>