nsdi-artifact-evaluation
GitHub指导NSDI论文作者准备 Artifact Evaluation，包括选择徽章、打包代码与测试环境、确保永久公开及争取社区奖。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill nsdi-artifact-evaluation -g -y
SKILL.md
Frontmatter
{
"name": "nsdi-artifact-evaluation",
"description": "Use when preparing an accepted NSDI paper's artifact for badge evaluation — packaging code, traces, and testbed recipes for the AEC, choosing which badges to pursue, meeting Zenodo-style permanence expectations, and timing public release to stay eligible for the Community Award."
}
NSDI Artifact Evaluation
Artifact evaluation at NSDI is post-acceptance and opt-in: accepted authors package what the paper is made of, an Artifact Evaluation Committee tries it, and earned badges travel with the paper. Mechanics below follow the NSDI '26 Call for Artifacts as rendered on 2026-07-08 — the '27 call was not yet retrievable (待核实), so treat '26 as the model and reread the live page after acceptance.
What the '26 cycle established
- Evaluation was open to all accepted papers.
- Three separate badges; a paper may earn one, two, or all three. The confirmed name is Artifacts Available — awarded when artifacts are retrievable permanently and publicly, with Zenodo encouraged (public funding, DOI assignment). The other two badge names in the NSDI '26 wording were not fully retrievable (待核实); USENIX's scheme at sibling venues pairs Available with functionality and results-reproduction badges.
- Authors choose which badges the AEC should consider at artifact-submission time — the evaluation is scoped to what you claim.
- '26 timeline anchor: artifacts due July 31, 2025, decisions October 14, 2025 — i.e., months after the first acceptance cohort, weeks-scale effort windows. Expect cohort-specific dates in '27 (待核实).
Choose badges like claims
The badge menu is a claims menu; over-claiming wastes AEC goodwill exactly as over-claiming in the paper wastes reviewer goodwill.
| You can honestly promise | Pursue | Do not pursue |
|---|---|---|
| The bits are public forever (DOI'd archive) | Available | — |
| An evaluator can build and run the core on documented hardware | + functionality-level badge | results claims tied to your production traces |
| Headline figures regenerate within characterized variance on accessible hardware | + reproduction-level badge | anything requiring your private fleet |
The networked-systems complication: results badges collide with topology dependence.
If p99.9 numbers need 80 nodes and a specific RTT matrix, ship a documented
downscaled configuration with expected outputs at that scale, and say explicitly
which paper trends survive downscaling and which do not (nsdi-reproducibility).
The Community Award changes your timeline
NSDI's Community Award goes to the best paper whose code and/or dataset is made
publicly available by the final-papers deadline. Note the trigger: not badge
completion — public release by camera-ready time. Teams that treat openness as a
post-AE cleanup task silently exit the running. If the artifact will be public
anyway, make it public early enough to count (nsdi-camera-ready).
Package for a stranger with a deadline
AEC members evaluate many artifacts on volunteer time. The artifact that wins is the one where the first fifteen minutes succeed:
artifact/
README.md # claims -> badge(s) sought; hardware/software needs up front
GETTING_STARTED.md # <=30 min smoke path: build, tiny topology, one sanity result
CLAIMS.md # paper claim -> experiment -> script -> expected output ± variance
setup/ # topology recipes: containers/CloudLab profile/VM configs
traces/ # shippable traces or synthetic generators + fidelity notes
experiments/<id>/ # one runnable unit per paper experiment (run.sh + provenance)
figures/Makefile # regenerate paper figures from logs (fresh or shipped)
LICENSE # explicit license; unlicensed code is not "available"
NSDI-specific packaging notes:
- State the variance. Tail-latency reproduction is stochastic; publish the spread you observed so the evaluator can tell noise from failure.
- Solve the testbed problem for them: a public-testbed profile (e.g., CloudLab) or an emulated topology beats instructions that assume your lab's switches.
- Trace substitutions documented: where production data cannot ship, the synthetic stand-in's construction and its fidelity limits are part of the artifact, not a footnote.
- Kernel/NIC settings pinned — the classic source of "works for authors only."
Dry-run protocol before submission
The single highest-yield hour: a lab member who did not build the artifact follows
GETTING_STARTED.md on a machine you did not prepare.
- Fresh VM or container, no lab dotfiles, no cached dependencies.
- Stopwatch on: record where the reader stalls, every undocumented assumption, and the wall-clock to first sanity result.
- Fix the artifact, not the reader — each stall becomes a README line or a setup script, then re-run with a second novice if anything structural changed.
Process notes
- By artifact-submission time you provide a stable URL or uploaded archive; from there, treat the artifact as frozen except through communication with the AEC.
- Evaluation is typically interactive at systems venues — expect clarification questions and budget author time during the window rather than vacationing through it.
- Badges recognize the artifact; they change neither the paper's acceptance nor its
page budget. The two-page artifact-appendix conventions of some sibling venues are
not an NSDI '26 fact — final-paper packaging follows
nsdi-camera-readyand the live instructions.
Common failure modes at systems AECs
- The build assumes the authors' distribution/toolchain; pin everything or ship the container.
- Scripts hardcode the lab's hostnames, interface names, or IP ranges.
- Expected outputs given as exact numbers with no variance band — evaluators "fail" runs that are actually fine.
- The trace download link requires the authors' institutional login.
- The README's experiment names do not match the paper's section numbers, forcing the evaluator to reverse-map claims.
Output format
[Badge plan] sought badges + honest basis for each
[Fifteen-minute test] GETTING_STARTED verified on a clean machine? time observed
[Scale strategy] downscale config + surviving-trends statement present?
[Trace shippability] per-dataset: ship / substitute / withhold (documented)
[Community Award] public release date vs final-papers deadline
[Gaps] ordered fixes before artifact submission
Version History
- 9f86f09 Current 2026-07-19 17:07
