FAST Workflow
Use this as the project-management skill for a FAST submission. Replace every date with the current
official timetable and work backwards from the deadline you choose. FAST — the USENIX Conference on
File and Storage Technologies — runs two deadlines a year, has an author-response period,
and can issue a one-shot revision that spans into the next deadline, so plan for a longer arc
than a plain accept/reject conference.
FAST is a USENIX conference: it has no standing editor-in-chief and no article-processing
charge. Rotating leadership is the per-edition Program Co-Chairs and the program committee, and
the cost model is registration plus USENIX membership — proceedings are open access. Chairs and the
Artifact Evaluation Committee rotate yearly; re-check the current committee page rather than carrying
a name forward (FAST '27 rosters: 待核实 beyond what the CFP names).
Choose the deadline, then plan backward
FAST '27 offers Spring (submit 17 Mar 2026, notify 4 Jun 2026, final files 28 Jul 2026) and
Fall (submit 15 Sep 2026, notify 8 Dec 2026, final files 26 Jan 2027). Pick by evidence
readiness — storage measurements at steady state on real, aged devices take real calendar time —
not by whichever is nearest. As of 2026-07-09 the Spring round is notified and the live target is
the Fall deadline, 15 Sep 2026.
Milestones
- Venue fit: confirm FAST over OSDI/ATC/EuroSys and that the core lesson is storage
(
fast-topic-selection).
- Evidence lock: freeze the testbed (devices, firmware, kernel), the workloads/traces, the
device-state protocol (aging, fill, TRIM), the baselines, and the metrics.
- Registration: register real title, abstract, authors, topics, and conflicts on the correct
Spring/Fall HotCRP instance.
- Submission: upload the anonymized, double-blind PDF and the availability statement.
- Author response: during the response window, answer reviewer questions with existing evidence
or a concrete, feasible plan.
- Decision: Accept / Accept-with-shepherding / One-shot Revision / Reject.
- Shepherding or one-shot revision (if issued): make the required changes; a one-shot revision
may demand new experiments and is resubmitted at the next deadline.
- Acceptance: prepare the open-access camera-ready, pursue USENIX artifact badges on the AEC's
own timeline, register, and present.
Backward plan from the submission deadline
| Weeks out (heuristic) |
Storage-evaluation milestone |
| 12+ |
Testbed fixed: device models/firmware, kernel, mkfs options; workloads/traces chosen |
| 10 |
Device-state protocol locked (aging/preconditioning, fill level, TRIM); baselines built and tuned |
| 8 |
Measurement runs complete at steady state; device counters (SMART/logs) captured; provenance logged |
| 6 |
Analysis done; tail-latency distributions, write-amplification, endurance projections computed |
| 4 |
Full draft in the USENIX template; artifact + trace-replay scripts assembled and anonymized |
| 3 |
Internal mock review by a storage reader |
| 2 |
Caveats hardened, related-work delta sharpened, page limit met |
| 1 |
Double-blind sweep on PDF and artifact; availability statement final |
| 0 |
Register the abstract on the correct HotCRP, then upload |
These offsets are planning heuristics only — anchor every one to the current Important Dates block,
never to a previous cycle's calendar. Note that storage runs (aging a drive, replaying a long trace,
an endurance test) can dominate the schedule; size them explicitly.
The two-deadline reality and one-shot revision
- Missing one deadline is not a lost year. The other FAST deadline is months away — but so is a
sibling (OSDI/ATC/EuroSys) date; factor that into routing rather than idling.
- A one-shot revision is a second full deadline, not a formality. Its instructions can require
specific new experiments, the revised paper is re-read, and it can be rejected. Budget the
revision window like a fresh submission, and note the paper stays under review at FAST during it,
so it cannot go elsewhere in parallel.
Failure modes by stage
- Testbed still moving at week 6 forces last-minute measurements nobody audited — the classic
storage-soundness reject in the making.
- Reporting fresh-out-of-box instead of steady-state numbers invites the "did you precondition?"
objection that can sink an SSD paper.
- Leaving the anonymized artifact and trace hosting to the final week is how a device dump,
hostname, or personal trace URL leaks identity under double-blind.
- Treating a one-shot revision as an accept and under-budgeting its experiments turns a winnable
revision into a reject.
Coordination notes
- Assign one owner for the testbed/provenance log and another for the double-blind sweep; shared
ownership is how both slip.
- Archive the exact submitted PDF, artifact, and (later) the response/revision documents — the
revision round must quote reviews precisely and stay anonymous.
Output format
[Current stage] idea / evidence / writing / registration / submitted / response / shepherd-or-revision / accepted
[Target deadline] Spring / Fall <date and source, or unknown>
[Critical path] <three tasks that determine readiness — often measurement-time-bound>
[Risk register] <page limit / anonymity / device state / provenance / tail latency / artifact>
[Owner map] <task -> person or role>
Source: brycewang-stanford/Awesome-Journal-Skills → FAST-Skills/skills/fast-workflow/SKILL.md
1---2name: fast-workflow3description: Use when planning a USENIX FAST project timeline from venue fit through choosing a Spring or Fall deadline, double-blind submission, the author-response period, shepherding or a one-shot revision, artifact evaluation, and the open-access camera-ready, with backward-planning offsets tuned to storage evaluation and honest handling of the two-deadline cycle.4---5
6
7# FAST Workflow
8
9Use this as the project-management skill for a FAST submission. Replace every date with the current
10official timetable and work backwards from the deadline you choose. FAST — the USENIX Conference on
11File and Storage Technologies — runs **two deadlines a year**, has an **author-response** period,
12and can issue a **one-shot revision** that spans into the next deadline, so plan for a longer arc
13than a plain accept/reject conference.
14
15FAST is a USENIX conference: it has **no standing editor-in-chief** and **no article-processing
16charge**. Rotating leadership is the per-edition Program Co-Chairs and the program committee, and
17the cost model is registration plus USENIX membership — proceedings are open access. Chairs and the
18Artifact Evaluation Committee rotate yearly; re-check the current committee page rather than carrying
19a name forward (FAST '27 rosters: **待核实** beyond what the CFP names).
20
21## Choose the deadline, then plan backward
22
23FAST '27 offers **Spring** (submit 17 Mar 2026, notify 4 Jun 2026, final files 28 Jul 2026) and
24**Fall** (submit 15 Sep 2026, notify 8 Dec 2026, final files 26 Jan 2027). Pick by *evidence
25readiness* — storage measurements at steady state on real, aged devices take real calendar time —
26not by whichever is nearest. As of 2026-07-09 the Spring round is notified and the live target is
27the **Fall deadline, 15 Sep 2026**.
28
29## Milestones
30
31- **Venue fit:** confirm FAST over OSDI/ATC/EuroSys and that the core lesson is storage
32 (`fast-topic-selection`).
33- **Evidence lock:** freeze the testbed (devices, firmware, kernel), the workloads/traces, the
34 device-state protocol (aging, fill, TRIM), the baselines, and the metrics.
35- **Registration:** register real title, abstract, authors, topics, and conflicts on the *correct*
36 Spring/Fall HotCRP instance.
37- **Submission:** upload the anonymized, double-blind PDF and the availability statement.
38- **Author response:** during the response window, answer reviewer questions with existing evidence
39 or a concrete, feasible plan.
40- **Decision:** Accept / Accept-with-shepherding / **One-shot Revision** / Reject.
41- **Shepherding or one-shot revision (if issued):** make the required changes; a one-shot revision
42 may demand *new experiments* and is resubmitted at the next deadline.
43- **Acceptance:** prepare the open-access camera-ready, pursue USENIX artifact badges on the AEC's
44 own timeline, register, and present.
45
46## Backward plan from the submission deadline
47
48| Weeks out (heuristic) | Storage-evaluation milestone |
49|---|---|
50| 12+ | Testbed fixed: device models/firmware, kernel, mkfs options; workloads/traces chosen |
51| 10 | Device-state protocol locked (aging/preconditioning, fill level, TRIM); baselines built and tuned |
52| 8 | Measurement runs complete at steady state; device counters (SMART/logs) captured; provenance logged |
53| 6 | Analysis done; tail-latency distributions, write-amplification, endurance projections computed |
54| 4 | Full draft in the USENIX template; artifact + trace-replay scripts assembled and anonymized |
55| 3 | Internal mock review by a storage reader |
56| 2 | Caveats hardened, related-work delta sharpened, page limit met |
57| 1 | Double-blind sweep on PDF and artifact; availability statement final |
58| 0 | Register the abstract on the correct HotCRP, then upload |
59
60These offsets are planning heuristics only — anchor every one to the current Important Dates block,
61never to a previous cycle's calendar. Note that storage runs (aging a drive, replaying a long trace,
62an endurance test) can dominate the schedule; size them explicitly.
63
64## The two-deadline reality and one-shot revision
65
66- **Missing one deadline is not a lost year.** The other FAST deadline is months away — but so is a
67 sibling (OSDI/ATC/EuroSys) date; factor that into routing rather than idling.
68- **A one-shot revision is a second full deadline, not a formality.** Its instructions can require
69 specific new experiments, the revised paper is re-read, and it can be rejected. Budget the
70 revision window like a fresh submission, and note the paper stays *under review at FAST* during it,
71 so it cannot go elsewhere in parallel.
72
73## Failure modes by stage
74
75- **Testbed still moving at week 6** forces last-minute measurements nobody audited — the classic
76 storage-soundness reject in the making.
77- **Reporting fresh-out-of-box instead of steady-state** numbers invites the "did you precondition?"
78 objection that can sink an SSD paper.
79- **Leaving the anonymized artifact and trace hosting to the final week** is how a device dump,
80 hostname, or personal trace URL leaks identity under double-blind.
81- **Treating a one-shot revision as an accept** and under-budgeting its experiments turns a winnable
82 revision into a reject.
83
84## Coordination notes
85
86- Assign one owner for the testbed/provenance log and another for the double-blind sweep; shared
87 ownership is how both slip.
88- Archive the exact submitted PDF, artifact, and (later) the response/revision documents — the
89 revision round must quote reviews precisely and stay anonymous.
90
91## Output format
92
93```text
94[Current stage] idea / evidence / writing / registration / submitted / response / shepherd-or-revision / accepted
95[Target deadline] Spring / Fall <date and source, or unknown>
96[Critical path] <three tasks that determine readiness — often measurement-time-bound>
97[Risk register] <page limit / anonymity / device state / provenance / tail latency / artifact>
98[Owner map] <task -> person or role>
99```
100
101---
102
103**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `FAST-Skills/skills/fast-workflow/SKILL.md`
thedixitjain