Contributor Mindset

This section is the "soft skills with hard edges" half of the curriculum. The Levels teach you the mechanics — how Tez builds a DAG, how the DAGAppMaster schedules tasks, how the shuffle moves bytes. This section teaches you how the Apache Tez project works: how decisions are made, how patches are accepted, how trust is earned, and how a contributor becomes a committer.

These are not optional skills. A technically excellent patch with poor process around it will sit on JIRA for a year and get closed as stale. A modest patch with clean process — a linked JIRA, a green Yetus run, a dev@ thread that shows your homework — gets reviewed and committed. The difference is rarely the code.

You should also calibrate one hard fact before you start: Tez is a mature, maintenance-phase project with a very small active committer set. Sample it yourself:

cd ~/tez-src
git shortlog -sn --since="2 years ago" | head -10

At the time of writing that list is short. Two people — Raghav Aggarwal and Laszlo Bodor — account for the large majority of commits over the last two years (roughly 32 and 28 respectively), with a long tail of contributors at one or two commits each. The founders whose names dominate the all-time log — Hitesh Shah (~619 commits), Siddharth Seth (~611), Bikas Saha (~403), Jonathan Eagles (~272), Rajesh Balamohan (~246) — are largely inactive now. Recent work is overwhelmingly maintenance: build modernization (Yetus, Jenkins, Java 21 and 25 support), dependency upgrades, Spotless/SpotBugs hygiene, and a slow-moving "[Cloud]" container-image effort. This shapes everything. A low-traffic project means slow reviews, a handful of gatekeepers, and enormous leverage for anyone who shows up consistently and does clean work. It also means the design conversations that mattered mostly already happened — and they are sitting in JIRA, which is why two of the seven chapters below are about excavating that history.

Reading Order

The chapters mirror the actual arc of a new contributor: learn to read, learn where the design lives, learn to talk, learn to ship a patch, learn to iterate, learn what you may break, learn how trust accrues.

Chapters 1–2 are pre-work — read them before opening any JIRA. Chapters 3–5 are operational — read them before submitting your first patch. Chapters 6–7 are strategic — read them when you start thinking beyond a single change.

The Arc: User → Contributor → Committer

Everyone on the Tez PMC started as a user. The project bylaws (docs/src/site/markdown/by-laws.md in the checkout) name four roles — User, Developer (contributor), Committer, PMC member — and they form a ladder you climb by doing the visible work at each rung.

The bylaws are explicit that a developer "who makes sustained, welcome contributions" may be invited to become a committer, and that "the form of contribution is not limited to code — it can also include code review, helping out users on the mailing lists, documentation." On a small project this is not abstract: the current active committers review nearly every merge (grep the log for reviewed by Laszlo Bodor and you will see one name recur). Becoming the third or fourth person who reliably reviews and unstalls patches is a concrete, open slot — see Meritocracy.

How This Section Complements the Rest of the Book

The relationship is concrete. Each mindset chapter pairs with technical material and with the issue roadmap, which is where you pick the real JIRA you will actually work.

If you are doing the Capstone, you should have read all seven chapters by the time you reach the step where you attach your real patch. The Capstone is graded in part on process — the things this section teaches.

What This Section Is Not

It is not generic open-source advice. Every claim, template, and procedure here is grounded in Tez-specific reality that you can verify in your own clone:

• The Apache Tez JIRA project (TEZ) and the TEZ-NNNN references peppered through the source (grep -rn "TEZ-[0-9]" tez-dag/src/main).
• The dev@tez.apache.org mailing list and its archive at lists.apache.org.
• In-repo policy and tooling: .asf.yaml, .github/workflows/build.yml, dev-support/tez-personality.sh (the Apache Yetus personality), the Checkstyle config at tez-build-tools/src/main/resources/checkstyle/checkstyle.xml, and the Spotless rules under dev-support/spotless/.
• The project bylaws in docs/src/site/markdown/by-laws.md, published at tez.apache.org.
• The @Public / @Private / @Evolving / @Unstable annotations that mark the API contract in tez-api.

Where a chapter generalizes to Apache-wide norms, it labels the generalization. Where it states a Tez-specific rule, it cites the in-repo file or the JIRA where the rule was set.

Prerequisites

Before this section is useful you must have:

• A local clone of Tez at ~/tez-src:

  git clone https://github.com/apache/tez.git ~/tez-src
  cd ~/tez-src
  

• A JIRA account at issues.apache.org/jira. This is your contribution identity — Tez tracks work in JIRA, not GitHub Issues (they are disabled; see features: issues: false in .asf.yaml).
• A subscription to dev@tez.apache.org — send empty mail to dev-subscribe@tez.apache.org and confirm the reply.
• A GitHub account. Since roughly late 2019 the working unit of change is a GitHub pull request linked to a JIRA, squash-merged (enabled_merge_buttons: squash: true in .asf.yaml). The old attached-.patch-file workflow is history you will still meet in old JIRAs — Community Interaction explains both.
• An ASF ID is not required — that comes later, with committership.

You Have Absorbed This Section When…

Treat this as the gate before declaring the section "read." You have absorbed it when you can:

1. Find any feature in Tez within 10 minutes by tracing from TezClient.submitDAG or DAGAppMaster.main, using git log -S, IDE call hierarchy, and Test* classes as spec.
2. Recover the "why" behind a piece of code: git blame → the TEZ-NNNN in the commit message → the JIRA and its design discussion.
3. Write a JIRA description a committer can act on with zero follow-up questions.
4. Produce a patch that passes Checkstyle and the changed-module tests on the first try, is attached to a JIRA, and is offered as a GitHub PR the way the project takes them today.
5. Read a @Public/@Private annotation and predict what you may and may not change.
6. Explain the difference between a contributor, a committer, and a PMC member, and describe a realistic track record that leads from the first to the second on a project this small.

The next chapter — Reading the Codebase — gives you the navigation strategy you will use through everything that follows.