The 16-Week Plan

This is a calendar. It maps the nine levels, the supporting tracks (deep dives, rust-vmm, contributor mindset, the issue roadmap), and the capstone onto 16 weeks of part-time work — the realistic rhythm of a working engineer giving Firecracker 8–12 focused hours a week. It is not a race. The gates in Milestones M1–M9 decide whether you advance, not the calendar; if a week takes you two, take two. But a schedule turns "I'll get to it" into "this week I do X," and that is the difference between finishing and drifting.

The plan front-loads the foundations (KVM, the threading model, the boot path) because everything later depends on them, and it interleaves real GitHub issue practice from Week 4 onward so you are contributing — not just reading — well before the capstone. Each phase ends with an exit checkpoint you must pass before moving on.

Note: Every "reading" cell points at curriculum pages and repo docs; every "labs" cell points at the level's labs. Run the labs — reading is not doing. Where a row says "issue practice," go to the Issue Roadmap, filter the real GitHub tracker (gh issue list), and actually engage. The roadmap stages are graded by difficulty; match them to your week.

Warning: Do not start the calendar on a broken baseline. You must have finished Overview & Prerequisites (a microVM boots from your own build) and read the Hitchhiker's Guide and Warm-Up before Week 1. Those are Week 0.


The Shape of the 16 Weeks

flowchart LR
    W0[Week 0: Setup + Warm-Up] --> P1[Weeks 1-3: Foundations<br/>L1-L2]
    P1 --> P2[Weeks 4-6: Architecture & KVM<br/>L3-L4]
    P2 --> P3[Weeks 7-9: Testing, Boot, Virtio<br/>L5-L7]
    P3 --> P4[Weeks 10-12: Real Contribution<br/>L8 + roadmap]
    P4 --> P5[Weeks 13-14: Advanced Maintainer<br/>L9]
    P5 --> P6[Weeks 15-16: Capstone<br/>full contribution cycle]
PhaseWeeksLevels / tracksThe one thing you can do at the end
0. SetupWeek 0Overview, Hitchhiker's, Warm-UpBoot, network, and snapshot a microVM as a user; locate code with rg.
1. Foundations1–3L1, L2Build/test Firecracker, write a minimal KVM VMM, open a clean first PR.
2. Architecture & KVM4–6L3, L4Trace API→VMM→vCPU; read the run loop and VM exits without a guide.
3. Engine internals7–9L5, L6, L7Use the test framework; trace the boot path and a virtio I/O end to end.
4. Real contribution10–12L8 + Issue RoadmapReproduce a real issue, root-cause it, ship a reviewed PR.
5. Advanced maintainer13–14L9Reason about seccomp/jailer, snapshot compat, and performance regressions.
6. Capstone15–16CapstoneOne full contribution cycle: issue → fix → tests → PR → write-up.

Phase 0 — Week 0: Setup & Warm-Up

WeekFocusReadingHands-onIssue practiceExit checkpoint
0Get a working build and the mental modelOverview & Prerequisites; Hitchhiker's Guide; Warm-Up; repo CONTRIBUTING.md, docs/getting-started.md, SPECIFICATION.mdBuild with tools/devtool build --release; boot a microVM; run all five warm-up scenarios (boot, net, second drive, snapshot, MMDS); wire git commit -sBrowse the Issue Roadmap and the live tracker; bookmark good first issueThe Overview "You Are Ready When…" and Warm-Up "What to Verify" checklists are fully green. This is the gate into Week 1.

Phase 1 — Foundations (Weeks 1–3): Levels 1–2

You build the floor everything stands on: a confident build/test loop, KVM from scratch (you write a tiny VMM by hand before you read Firecracker's), and your first real PR with DCO sign-off.

WeekFocusReadingHands-on labsIssue practiceExit checkpoint
1Build, test, bootLevel 1 index; deep dive kvm-fundamentals; rust-vmm: what-is-rust-vmmLab 1.1 build-from-source; Lab 1.2 run-tests; Lab 1.3 boot-first-microvmRead 5 closed good first issue PRs end to end; note what a clean PR looks liketools/devtool build/test/checkstyle all green; you can boot from your own binary and explain each curl
2KVM by handrust-vmm: kvm-ioctls-and-kvm-bindings; deep dive guest-memory-managementLab 1.4 minimal-kvm-vmm; rust-vmm Lab r1 build-a-kvm-vmPick a docs/test good first issue (Stage 1); claim it by commentingYour hand-written VMM opens /dev/kvm, maps memory, runs KVM_RUN, handles an IO exit
3Contributor workflowLevel 2 index; contributor-mindset: pr-quality, reading-codebase; release-governance: licensing-and-dcoLab 2.1 navigate-repo; Lab 2.2 prepare-pr; Lab 2.3 fixit-good-first-issue; Lab 2.4 review-a-prOpen your first real PR from Stage 1 work: DCO-signed, CHANGELOG entry, passes CIMilestone M1 + M2: a PR is open against main, correctly signed, CI green, and you can defend every line

Tip: Weeks 1–2 are the highest-leverage in the whole plan. An engineer who genuinely understands the three KVM fd levels and the KVM_RUN loop reads the rest of Firecracker far faster. Do not rush Lab 1.4 — writing the ~70-line VMM yourself is worth ten pages of reading.


Phase 2 — Architecture & KVM (Weeks 4–6): Levels 3–4

Now you read Firecracker's own machinery: the three-thread model, the API→VMM action channel, and the vCPU run loop with its VM-exit taxonomy. This is where the warm-up's "under the hood" becomes code you can trace.

WeekFocusReadingHands-on labsIssue practiceExit checkpoint
4Threading & the action channelLevel 3 index; deep dives the-vmm-threading-model, api-server-and-action-channel, the-event-managerLab 3.1 trace-api-to-vmm; Lab 3.2 threading-model-eventmanagerEngage a Stage 2 issue (build/logging); start a discussion on itYou can draw the API thread → VmmAction (mpsc + eventfd) → VMM epoll loop path from memory
5A custom API actiondeep dive logging-and-metrics; rust-vmm: event-managerLab 3.3 project-custom-api-actionOpen a Stage 2 or Stage 3 (error-messages) PRYour custom action flows socket → ParsedRequest → VmmAction → handler → response; tests pass
6vCPUs, the run loop, VM exitsLevel 4 index; deep dives vcpu-run-loop-and-vm-exits, cpu-templates-and-cpuid, interrupts-and-irqchipLab 4.1 read-vcpu-run-loop; Lab 4.2 vm-exits-mmio-pio; Lab 4.3 cpuid-template; Lab 4.4 fixit-vcpu-edge-caseComment substantively on an open vCPU/KVM issue (Stage 6)Milestone M3 + M4: trace a request to a KVM_RUN exit and back; explain MMIO vs PIO exits without notes

Phase 3 — Engine Internals (Weeks 7–9): Levels 5–7

Testing fluency, the boot path and guest memory, and the virtio device model — block, net, vsock — from the descriptor ring up. This phase has the most labs; pace yourself.

WeekFocusReadingHands-on labsIssue practiceExit checkpoint
7Testing & debuggingLevel 5 index; deep dive logging-and-metrics; contributor-mindset: design-via-githubLab 5.1 integration-test-framework; Lab 5.2 add-unit-test; Lab 5.3 project-integration-test; Lab 5.4 fixit-flaky-testPick up a Stage 9 flaky-test issue; reproduce itYou can write a pytest integration test in tests/ and run it via tools/devtool test; Milestone M5
8Boot path & guest memoryLevel 6 index; deep dives the-boot-sequence, acpi-and-mptable; rust-vmm: linux-loader, vm-memoryLab 6.1 trace-boot-sequence; Lab 6.2 guest-memory-layout; Lab 6.3 project-boot-configA Stage 4 api-validation or Stage 5 device-config PRYou can trace vmlinux load → zero page/e820 → initial vCPU regs; Milestone M6
9The virtio device modelLevel 7 index; deep dives virtio-transport-mmio, virtqueues, virtio-block, virtio-net-and-tap; rust-vmm: virtio-queueLab 7.1 trace-virtio-block-io; Lab 7.2 virtqueues-and-mmio; Lab 7.3 project-custom-virtio-deviceEngage a Stage 7 virtio-devices issueMilestone M7: trace a guest disk read through the available ring → descriptor chain → host pread → used ring → IRQ

Tip: Week 9 is the densest. If you are behind, push Lab 7.3 (building a device) into Week 10 — but do not skip Lab 7.1. Tracing one real I/O end to end is the gate skill for the contribution phase.


Phase 4 — Real Contribution (Weeks 10–12): Level 8 + the Issue Roadmap

You stop practicing and start contributing for real: select a genuine issue, reproduce it, find the root cause through execution-path analysis, fix it, test it, and shepherd a PR through ≥2 maintainer reviews.

WeekFocusReadingHands-on labsIssue practiceExit checkpoint
10Find & reproduce a real issueLevel 8 index; contributor-mindset: design-via-github, community-interaction; Issue Roadmap indexLab 8.1 reproduce-issueSelect a real open issue matched to your level (Stage 3–7); claim it, post a reproductionA minimal, reliable reproduction is posted on the issue; maintainers can confirm it
11Fix itcontributor-mindset: responding-to-feedback, compatibilityLab 8.2 implement-fix; Lab 8.3 error-messagesOpen the fix PR: DCO-signed, integration test, CHANGELOG entry, ≤72-char titleThe PR is open, CI green, and your PR description ties the fix to a root cause
12Drive it to mergecontributor-mindset: pr-quality; release-governance: github-reviewIterate on review; rebase/--amend -s cleanly; respond to every commentAddress ≥2 maintainers' feedback rounds; help review someone else's PRMilestone M8: a PR merged (or in final review) that fixes a real, confirmed issue

Warning: Real PRs take real calendar time — reviewers are busy and require ≥2 approvals. Open the PR early in Week 11 so the review clock starts. If it has not merged by Week 12, that is normal; the milestone is satisfied by a high-quality PR in active review, not necessarily merged.


Phase 5 — Advanced Maintainer (Weeks 13–14): Level 9

The maintainer-grade concerns: the security model end to end (jailer + seccomp + threat model), snapshot/restore compatibility, and diagnosing performance regressions.

WeekFocusReadingHands-on labsIssue practiceExit checkpoint
13Security & snapshotsLevel 9 index; deep dives the-jailer, seccomp-filtering, snapshotting; repo docs/jailer.md, docs/seccomp.md, docs/prod-host-setup.mdLab 9.1 seccomp-jailer; Lab 9.2 snapshot-restoreEngage a Stage 11 security-seccomp or Stage 8 snapshot-compat issueYou can explain the four defense-in-depth layers and audit one device's attack surface
14Performance & compatibilityengineering: oversubscription-and-density, boot-time-optimization, hugepages-and-memory-performance; deep dive rate-limiting-token-bucketLab 9.3 perf-regressionA Stage 10 performance issue: measure, bisect, write upMilestone M9: diagnose a perf regression with measurement; reason about snapshot backward-compat correctly

Phase 6 — Capstone (Weeks 15–16): One Full Contribution Cycle

The capstone is not new material — it is the whole apprenticeship performed once, cleanly, on a real contribution, and written up as evidence. Follow the ten capstone steps.

WeekFocusStepsDeliverableExit checkpoint
15Issue → reproduction → root cause → implementationstep-01 issue-selection → step-02 reproduction → step-03 execution-path → step-04 root-cause → step-05 implementationA working fix on a branch with a written execution-path analysisThe root cause is proven (not guessed) and the fix is implemented behind tests
16Testing → validation → PR → docs → write-upstep-06 testing → step-07 validation → step-08 pr → step-09 github-docs → step-10 writeupA submitted PR + an engineering write-up scored against the evaluation rubricAll nine milestones satisfied; capstone PR submitted; write-up complete

After the capstone, keep going: the capstone projects portfolio and the feature masterclasses are where you deepen toward sustained, maintainer-track contribution. The path from contributor to maintainer is months to years — this 16 weeks earns you the starting line, not the finish.


If You Only Have 8 Weeks (Compressed Track)

For an experienced VMM/kernel engineer, or anyone who must move fast, here is a compressed track. It keeps the non-negotiables — KVM by hand, the run loop, one virtio I/O traced end to end, and one real PR — and trims the depth elsewhere. Budget the same 8–12 hours/week but accept that you will revisit the skipped deep dives later.

WeekCoversMust-do labsMust-pass milestone
1Setup + Warm-Up + L1 build/boot1.1, 1.3Boot a microVM from your own build
2L1 KVM by hand + L2 workflow1.4 minimal-kvm-vmm, 2.2 prepare-prM1+M2: hand-written VMM runs; clean PR mechanics
3L3 architecture + threading3.1 trace-api-to-vmm, 3.2M3: trace API→VMM→vCPU
4L4 KVM/vCPU run loop + VM exits4.1 read-vcpu-run-loop, 4.2 vm-exitsM4: run loop + exit taxonomy
5L6 boot path (skim L5 testing)6.1 trace-boot-sequence, 5.2 add-unit-testM6: trace the boot path
6L7 virtio devices7.1 trace-virtio-block-io, 7.2 virtqueuesM7: trace one virtio I/O end to end
7L8 real contribution8.1 reproduce-issue, 8.2 implement-fixM8: a real fix PR in review
8L9 essentials + mini-capstone9.1 seccomp-jailer, 9.2 snapshot-restoreM9; a scoped capstone PR

What the 8-week track deliberately defers (do these later): Level 5 testing depth, the rust-vmm labs beyond r1, the engineering at scale essays, the feature masterclasses, and the integration labs. You can become a credible contributor in 8 weeks; becoming a maintainer is the longer game the full 16 weeks (and beyond) builds toward.

Note: Whichever track you take, the milestones are the real gates. If you cannot pass Milestone M4's self-checks, you are not ready for Level 6 no matter what week the calendar says. The calendar serves the milestones, not the other way around.


Where to Go Next

Read Milestones M1–M9 next — they define the competence gates this calendar is pacing you toward. Then begin Level 1. Keep this plan and the milestones page open as you go; mark each exit checkpoint as you pass it.