Meritocracy: Contributor → Committer → PMC

The Apache Way uses a specific, technical sense of the word "meritocracy" that is often misread. This chapter is what it actually means inside Apache Tez, how the path from casual contributor to PMC member works, and what each step really requires.

The Three Roles

There is no fourth role. "Lead contributor" or "maintainer" are not Apache concepts. "Chair" is a PMC member who reports to the board; rotating, often by lottery within the PMC.

What "Meritocracy" Actually Means at Apache

Apache uses "meritocracy" in a very specific sense: decisions and elevations are based on accumulated, evidenced contribution to the project — not on title, employer, or personal connections.

That is narrower than the colloquial meaning. It explicitly does not mean:

• "Best engineer wins." Many excellent engineers are not committers because they have not engaged with this specific community.
• "Most patches wins." LOC is not a measure of merit.
• "Paid time on the project wins." Full-time paid Tez work, on its own, does not earn committership. The community must observe the contribution.
• "Smartest design wins arguments." Arguments are won by evidence and consensus, not cleverness.

What it does mean:

• Sustained, visible contribution over months
• Quality demonstrated by patches getting committed with few iterations
• Trust demonstrated by reasonable behavior on JIRA and dev@
• Investment in the project itself, not just in your features

The Path to Committer

The committer vote is private; the criteria are not codified anywhere with bullet points. What committers actually look at, in rough order:

1. Patch quality. Have your patches gone in with light review? Have you mastered the workflow in Patch Quality?
2. Volume and sustained activity. Not LOC, but consistency. 10 small patches over 6 months is much stronger than 1 huge patch.
3. Engagement breadth. Have you reviewed others' patches (with non-binding +1s)? Helped on user@ questions? Filed clean JIRAs?
4. Judgement on dev@. Have you participated in design discussions? Were your contributions thoughtful, not just adding noise?
5. Area coverage. Have you worked in more than one corner of the codebase, or are you trusted for a deep one? Either can earn the bit.
6. Trust. Would the existing committers be comfortable with you committing your own patches?

There is no fixed threshold. Different projects have different bars; Tez is in the middle (not as strict as Hadoop, not as loose as a brand-new TLP).

Typical Trajectory

Month 1-2:   First few small patches (Javadoc, log messages, tiny bug fixes).
             Some friction in review as you learn conventions.
Month 3-6:   More substantive patches. Lower review iteration count.
             Reviewing others' patches with non-binding +1.
Month 6-12:  Larger patches with design discussion.
             Filing follow-up JIRAs after your patches.
             Recognised name on dev@.
Month 12+:   A PMC member notices and proposes you on private@.
             PMC discusses, votes. Vote happens silently.
             You receive a private email offering the bit.
             You publicly accept on dev@ via an [ANNOUNCE] thread by the PMC.

The 12-month figure is a median, not a rule. Faster is possible with very sustained engagement; slower is common.

Accepting the Bit

If a PMC member emails you with an offer of committership, the steps:

1. Accept privately, via reply to the offer email.
2. The PMC raises an [ANNOUNCE] New Tez committer: <name> thread on dev@.
3. You acknowledge publicly on the thread.
4. ASF Infrastructure provisions your ASF ID (<id>@apache.org).
5. You get karma to push to apache/tez.

What changes for you:

• You can commit your own patches. Don't commit your own patches without review for the first few months. The community trust applies to your judgement of others' patches; your own still get reviewed.
• You get a binding +1 vote on commits.
• You get a non-binding +1 on releases (PMC +1 is binding).
• You are now visible as part of the project. Behave accordingly on dev@, JIRA, and conferences.

The Path to PMC

PMC membership is a separate, later, additive step. Committership is necessary but not sufficient. Criteria, looser even than committership:

1. Sustained activity as a committer. Months to years post-committer.
2. Project-level judgement, not just code. Have you weighed in on release timing, compat questions, community-management issues?
3. Willingness to take on release-management or PMC duties. Cutting a release, responding to security reports, mentoring new committers.
4. Trust to handle confidential matters — security disclosures arrive on private@tez.apache.org, and PMC members must handle them carefully.

PMC votes are also private. You are notified by email; the public announcement is on dev@.

What PMC Members Do That Committers Don't

Common Misconceptions

"I work on Tez full-time, so I should be a committer."

Paid time is irrelevant. The community can only assess what it can observe — public patches, public reviews, public discussion. Internal company work, no matter how extensive, does not exist from the project's perspective.

If your day job is Tez work, the way to convert that into committership is to do that work in the open: file JIRAs, attach patches, post designs.

"I wrote N lines of code, so I should be a committer."

LOC is not used. A contributor with 200 lines spread across 15 thoughtful patches is strictly stronger than one with 5000 lines in 2 mega-patches. Smaller, frequent, high- quality contributions demonstrate the judgement committership rewards.

"My company has N committers, so we should have the next slot."

Apache projects are explicitly company-independent. Many PMCs have an informal limit on the proportion of committers from any single employer (no more than ~50%) to preserve project independence. Companies do not have slots.

"I was a committer on project X, so I should get the bit here automatically."

You don't. Committership is per-project. Past contribution elsewhere is positive prior evidence but does not substitute for engagement on Tez.

"I have an ASF ICLA on file, so I'm a contributor."

An ICLA is a legal document covering future contributions. It does not make you a contributor; submitting a contribution makes you a contributor. ICLA is necessary for non-trivial contributions to be committed.

"There is a contributor-rank or leaderboard."

There isn't. Apache projects do not maintain rankings, badges, or stars. The closest thing is the CHANGES.txt file, which records the contributor name on each committed patch.

What Earns the Bit, Concretely

If you want a checklist, this is roughly it. None are individually required, but most committers tick most boxes by the time they're proposed:

• 10+ patches committed, spanning multiple areas of the code.
• At least one patch with non-trivial design discussion on dev@ or JIRA.
• At least one bug found by you, reproduced by you, fixed by you, tested by you.
• Reviewed at least 5 other contributors' patches with constructive non-binding +1s or -1s.
• Helped answer questions on user@ or in JIRA comments.
• Filed follow-up JIRAs when you noticed adjacent issues.
• Behaved well in every public interaction, including when a patch was rejected.
• Maintained existing patches as the codebase moved under them (rebased, addressed review).
• Sustained over 6+ months, not concentrated in one sprint.
• Not gaming any of the above (committers can tell).

What Earns PMC, Concretely

• Committer for 1–3+ years.
• Demonstrated judgement on dev@ beyond your own patches.
• Have either cut a release or helped with one.
• Have proposed or seconded other committers.
• Have engaged with at least one cross-project compat concern.
• Visible willingness to do PMC work (security, brand, board reports) — not just code.

Validation Artifacts

After this chapter you should have:

1. A clear-eyed view of where you currently are on the path.
2. A ~/tez-notes/karma.md listing every concrete thing you've done that the community can observe — patches, reviews, JIRA comments, dev@ posts.
3. A goal for the next 3 months in terms of contribution shape, not LOC.
4. The ability to explain the contributor / committer / PMC distinction to a colleague without using the word "lead."

This chapter closes the Contributor Mindset section. The next major section, Release & PMC Reality, takes you inside the committer and PMC view — what those roles actually look like from inside.