Warmup Guide — Final Apprenticeship Milestone

Orientation for Phase 12. The capstone introduces no new concepts — it integrates Phases 01–11 into three committer-grade artifacts. This warmup is the pre-flight check: what to have ready, how the three labs compose, and how to grade yourself before anyone else does.

Table of Contents

• Chapter 1: The Shape of the Milestone
• Chapter 2: Prerequisite Inventory — What You're Assumed to Have
• Chapter 3: The Contribution Cycle as a Single Performance
• Chapter 4: The Design Doc as Your Thesis
• Chapter 5: Reflection — Converting Experience into Transfer
• Chapter 6: After the Milestone — the Real First Patch
• Lab Walkthrough Guidance
• Success Criteria
• Interview Q&A
• References

Chapter 1: The Shape of the Milestone

Three labs, three artifact classes, one claim: you could operate as a committer candidate today.

The deep companion for all three is this phase's HITCHHIKERS-GUIDE — it carries the full mechanics (the eight-artifact cycle, the design-doc skeleton, review-response discipline, release-note format). This warmup deliberately doesn't repeat it; read it next.

Chapter 2: Prerequisite Inventory — What You're Assumed to Have

Honest self-check before starting; gaps here surface mid-capstone at 3× the cost:

• From Phase 02: you can navigate to any symbol, run one test, and execute the blame→JIRA→PR chain without thinking about it.
• From Phases 05–06: the blast-radius review checklist is reflexive; you write severity-labeled comments; characterization-tests-before-refactor is habit.
• From Phases 04/10: you can classify a change's compatibility impact (the Chapter 5 rules table from the Phase 10 warmup) and write the release-note line it requires.
• From Phase 11: you can state the skew matrix and the deprecation lifecycle — Lab 02's design topics live in this territory.
• From Phase 01: you remember what is actually being evaluated (trust axes), which is the grading rubric behind every artifact here.

Anything shaky → re-read that phase's WARMUP success-criteria list; they were written as exactly this checklist.

Chapter 3: The Contribution Cycle as a Single Performance

What changes when the pieces compose (the part that surprises people): the artifacts constrain each other.

• The issue framing determines the patch's reviewability — a falsifiable problem statement ("normalize() drops U+00A0; repro attached") pre-answers the reviewer's first three questions.
• The test is written against the issue, not the patch — it must fail on unpatched code (run it and capture that failure; the discipline catches wrong-fix bugs before review does).
• The review response quality is bounded by the patch's scope — a minimal diff makes every comment addressable; scope creep makes some comments unanswerable without "I'll split this out" (which you should then actually do).
• The release note is bounded by your blast-radius understanding — if the "who is affected" line is hard to write, the patch isn't done being understood.

Treat Lab 01 as a dress rehearsal with the costume on: write every artifact as if the recipient were a real PMC member who'll spend 10 minutes on it, total.

Chapter 4: The Design Doc as Your Thesis

Lab 02 is the single highest-leverage artifact in the curriculum for interviews — a complete design doc demonstrates the altitude that distinguishes staff candidates. The compressed guidance (full skeleton in the HITCHHIKERS-GUIDE §2):

• Pick a problem from Phases 10–11's space (scheduler improvement, metastore scaling, API/format evolution) so the curriculum's case law (Phase 03) and the system-design walkthroughs give you precedent to cite — citing precedent is the senior register.
• The alternatives section is the doc: 2–3 real options with honest costs, including "do nothing." Write each option's case as its proponent would; rejection reasons must survive a hostile reading.
• Non-goals and revert plans are where reviewers test for judgment; budget real effort there.
• Length discipline: ≤6 pages. Over that, decompose the design (sequence of small consensuses — the KIP/SPIP pattern).

Chapter 5: Reflection — Converting Experience into Transfer

Lab 03's bar (anti-platitude rules in the HITCHHIKERS-GUIDE §5): every claim must be falsifiable and costed. The generative prompts that produce real content:

• Which phase's material did you misjudge the importance of at the start, and what did the misjudgment cost in hours? (Almost everyone: under-weighting review culture, over-weighting code volume.)
• What's the earliest detection signature of each mistake you made — the thing a reader could watch for? ("If your characterization tests feel unnecessary, you're about to learn why they aren't.")
• What would you tell someone choosing between this curriculum and "just start submitting patches"? (The honest answer has both halves.)
• Three things you now do by reflex that you did by checklist in Phase 05 — reflexes are the curriculum's actual output; name them.

Chapter 6: After the Milestone — the Real First Patch

The milestone's exit ramp is Phase 01's plan, now executable:

1. Return to your Lab 01 (Phase 01) project map — refresh it; six months of project drift is normal.
2. Choose the first real issue with the trust calculus: starter-labeled, in your mapped subsystem, reproducible by you, reviewable by the 2–3 people you identified.
3. Run the Lab 01 (this phase) cycle for real — same artifacts, real stakes, 72-hour-response discipline.
4. In parallel, start the reciprocity loop: one review of someone else's PR per week in that subsystem (the highest trust-signal-per-hour activity available to you — Phase 01 Ch. 4).
5. Calibrate to the project's measured timelines (your own Lab 01 numbers), not your impatience: months-scale presence is the unit of progress.

Lab Walkthrough Guidance

Order: Lab 01 → Lab 02 → Lab 03, reflection last while everything is fresh. Detailed per-lab guidance lives in the HITCHHIKERS-GUIDE "Lab Walkthrough Guidance" section — follow it; this warmup's Chapters 3–5 are the why behind each instruction there.

One scheduling note: the three labs are ~2 weeks of honest work. Do not compress Lab 02 below several sittings — design docs written in one sitting read like it, and the re-read-after-three-days step is where half the alternatives-section weaknesses surface.

Success Criteria

The milestone — and the curriculum — is complete when:

1. Your Lab 01 package would not embarrass you posted to a real ASF project today, and you can defend every artifact's choices against the Phase 06 checklist.
2. Your design doc's alternatives section survives a hostile reviewer (test: have someone — or yourself, post-delay — argue for a rejected option; the doc should already contain the rebuttal).
3. Your reflection contains ≥3 falsifiable, costed lessons (Chapter 5's bar) that a Phase-01 reader could act on.
4. You have selected the real project, real subsystem, and real first issue for Chapter 6's plan — with dates.

Interview Q&A

The capstone-relevant interview answers are consolidated in the HITCHHIKERS-GUIDE Interview Q&A and in interview-prep/. The one meta-question to prepare from this warmup:

Q: You've never been a committer. Why should we believe you can operate at that level? Point at artifacts, not adjectives: the full contribution cycle executed to ASF norms (show the review-response discipline), a subsystem design doc with steel-manned alternatives, a working review record (your Phase 06 outputs + real reviews from Chapter 6's loop), and the measured project map proving you understand the specific community you're entering. "I have done the job's components in public, here they are" is the only credible answer to a credentials gap — and it's the one this curriculum was built to let you give.

References

• HITCHHIKERS-GUIDE.md — this phase's full mechanics; read immediately after this warmup
• interview-prep/ and system-design/ — the consolidation targets
• Spark: Contributing — re-read now; it reads differently after eleven phases
• Fogel, Producing Open Source Software — final read-through; it is the curriculum's bibliography in one book