Phase 01 — Apache Contributor Foundations
Difficulty: ⭐☆☆☆☆ | Estimated Time: 1–2 weeks
Roles supported: All tracks — foundational mental model for every phase that follows.
Why This Phase Exists
Every engineer who has ever contributed a patch and heard nothing back, or submitted a PR and been asked for a complete redesign, has encountered the same invisible barrier: the Apache trust model. It is never written in one place. It is learned by observing and participating over months and years.
This phase makes the implicit explicit. You will understand the Apache hierarchy, how trust is built and evaluated, why technically excellent engineers fail to become committers, and what the stewardship mindset actually requires. Without this foundation, every technical skill in the phases that follow will be applied in the wrong direction.
Concepts
- Apache contributor → committer → PMC member hierarchy
- The mechanics of committer elections
- Trust dimensions: technical credibility, review quality, reliability, communication, stewardship
- Why large-batch contribution fails; why incremental sustained participation wins
- Apache mailing list culture: dev@, user@, private@
- Consensus and voting (+1 / 0 / -1, binding vs non-binding)
- Lazy consensus and when it applies
- Stewardship behaviors: backward compatibility, operational empathy, incremental change
- How to read a contributor's public history (JIRA, GitHub, mailing list archives)
- Constructing a "trust gap" analysis: what separates a strong contributor from a committer candidate
Labs
Lab 01 — Contributor Landscape Mapping
| Field | Value |
|---|---|
| Goal | Research a real Apache project and map five contributors at different stages of the contributor ladder, producing a structured profile for each. |
| Concepts | Contributor vs committer vs PMC; visible participation history; JIRA/GitHub/Whimsy as evidence trails. |
| Project | Apache Spark (primary) — or Apache Hadoop if you prefer a Hadoop focus. |
| Steps | 1) Use Apache Whimsy Roster to identify current Spark PMC members and committers. 2) Use GitHub and JIRA to identify 2–3 active contributors who are not yet committers. 3) For each of your 5 selected engineers, complete one contributor-profile-template.md. 4) Write a 200-word "journey summary" for at least one real contributor: first patch → committer election. |
| Output | Five completed contributor-profile-[name].md files plus a 200-word journey summary. |
| Talking Points | What patterns appear across all committer profiles? What is missing from strong contributor profiles? How long does the journey typically take? |
| Resume Bullet | "Analyzed contributor-to-committer progression for Apache Spark: mapped five public contribution histories across JIRA, GitHub, and mailing list archives to identify the trust-building patterns that precede committer elections." |
| Extensions | Compare the journey timelines across Hadoop and Spark. Do different projects have different norms? |
Lab 02 — Trust Audit
| Field | Value |
|---|---|
| Goal | Evaluate a fictional contributor profile against the six trust dimensions used by Apache maintainers and produce a structured gap analysis with recommended actions. |
| Concepts | Trust dimensions; committer evaluation criteria; stewardship mindset; incremental participation. |
| Steps | 1) Read the fictional contributor profile provided in the lab README. 2) Score each of the six trust dimensions on a 1–5 scale with specific evidence. 3) Identify the top two gaps blocking committer candidacy. 4) Produce three concrete recommended actions that would move the profile forward within 6 months. 5) Write a one-paragraph PMC nomination draft — or explain why you could not write one yet. |
| Output | One completed trust-audit-[name].md with dimension scores, gap analysis, action plan, and nomination draft or blocker explanation. |
| Talking Points | Which dimensions are hardest to build quickly? Which can be gamed — and why that backfires? How does a PMC member's private nomination discussion actually use this information? |
| Resume Bullet | "Applied Apache committer trust model to structured contributor evaluation; produced gap analysis and 6-month development plan across six trust dimensions (technical credibility, review quality, reliability, communication, stewardship, community participation)." |
| Extensions | Apply the same audit to yourself. Which are your weakest dimensions today? |
Deliverables Checklist
- Five contributor profile documents completed (lab-01)
- At least one 200-word journey summary (lab-01)
- Trust audit completed with all six dimension scores (lab-02)
- Top two gaps identified with evidence (lab-02)
- Three recommended actions written (lab-02)
- Nomination draft or blocker explanation written (lab-02)
Interview Relevance
- "How does someone become an Apache committer?" (you can answer with the full election mechanics)
- "What makes a good open-source contributor?" (you can answer with the six trust dimensions)
- "Why do technically strong engineers sometimes fail to get traction in open source?" (you can answer with five failure modes)
- "What is lazy consensus?" (you can answer precisely)
- "What is the difference between a committer and a PMC member?" (you can answer with governance authority details)