PMC Responsibilities

PMC (Project Management Committee) membership at Apache is not a senior-engineer title. It is a stewardship role with explicit legal, brand, community, and release responsibilities. This chapter is the operational manual for what PMC members actually do between releases.

The Tez PMC list is at private@tez.apache.org. Public PMC members are listed at https://tez.apache.org/team-list.html (or the equivalent on the current site).

The Four Buckets of PMC Work

Plus one cross-bucket: board reporting, quarterly.

Legal Responsibilities

License Headers

Every source file in the Tez tree must have an Apache 2.0 license header. Tez uses Apache RAT to enforce this.

cd ~/tez-src
mvn apache-rat:check

The expected header for a .java file:

/**
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

If RAT fails on a release candidate, the release cannot ship. PMC members reviewing a release verify RAT cleanliness as part of vote-time checks (see Release Voting).

For non-.java files (.proto, .xml, .sh, .md), the same content with the appropriate comment delimiters.

NOTICE File

The NOTICE file at the repo root carries:

• The required Apache attribution line.
• Required attribution for any bundled third-party code that explicitly demands it.

cat ~/tez-src/NOTICE

Most BSD-, MIT-, and Apache-licensed dependencies do not require NOTICE entries. Some do (notably ones with NOTICE files of their own, which by Apache convention propagate into bundlers). The rule of thumb: if a dependency ships a NOTICE file, copy the required text into Tez's NOTICE.

Common error: adding random "thanks to" lines. NOTICE is not a thank-you file; it is a legal artifact. Keep it minimal and correct.

LICENSE File

LICENSE at the repo root is the Apache License 2.0 plus appendices for any bundled third-party code under different licenses.

For Tez, mostly the appendices are absent because the source release bundles no third-party source. The binary release (the convenience tarball) may bundle jars whose licenses must be appendixed.

If you are a PMC member adding a new dependency that gets bundled in the binary release:

1. Identify the dependency's license (read it, don't guess).
2. Verify category (A, B, or X) — see Licensing.
3. If A: update LICENSE appendix; sometimes NOTICE.
4. If B: requires PMC discussion + LICENSE / NOTICE updates.
5. If X: stop. Cannot be bundled. May only be a runtime-optional dep, never a hard one.

ICLA Matching

Every non-trivial contribution must come from someone with an Apache ICLA on file. The ICLA list is maintained by Apache Infra; PMC members can verify by emailing secretary@apache.org with a contributor name.

In practice, for casual contributors:

• Trivial patches (Javadoc, typo) do not require ICLA.
• Anything substantive does.
• The contributor sends the ICLA themselves; PMC verifies it landed.

If a substantial patch is committed without an ICLA on file, that is a legal exposure for the foundation. PMC members must catch this before commit.

Brand Responsibilities

"Apache Tez" is a trademark of the Apache Software Foundation. The PMC is the steward.

For specifics see the ASF Trademark and Brand Policy. When in doubt, the PMC defers to trademarks@apache.org.

Community Responsibilities

Moderation

Most ASF mailing lists are moderated for non-subscribers (subscribers post freely). The moderation work is light: approving first posts, rejecting spam.

Tez has a small mod team (typically a couple of PMC members). Add dev-moderate@ or similar to your mail filter to spot moderation requests.

If subscriber behavior on a list becomes problematic — flame wars, code-of-conduct violations — the PMC handles it. Typical escalation:

1. Off-list private email from a PMC member to the offending subscriber.
2. If unaddressed, a public on-list warning.
3. If unaddressed, removal from the list (rare; requires PMC vote).

For severe cases (harassment, security threats), escalate immediately to board@apache.org.

Voting New Committers

The committer-bit process, from the PMC's side:

1. PMC member observes a strong contributor (see meritocracy chapter).
2. PMC member emails private@tez.apache.org with [VOTE] thread.
3. PMC members vote +1 / 0 / -1 (usually +1, sometimes 0 with rationale).
4. Vote runs ~72 hours; passes with >3 binding +1 and no binding -1.
5. PMC member privately emails the contributor with the offer.
6. On acceptance, ASF Infra is notified to provision the ASF account.
7. PMC announces publicly on dev@.

A -1 from a PMC member on a committer vote requires a concrete reason. "Doesn't feel right" is not enough; "two recent JIRAs showed inadequate care for compatibility" is.

PMC members may vote 0 if they don't know the contributor well — common, no shame in it.

Voting New PMC Members

Same mechanism as committer, except:

• All committers are pre-considered, so the candidate is always a sitting committer.
• The bar is higher (judgement, willingness to do PMC work, see Meritocracy).

After acceptance, the candidate is invited to the PMC. The Apache Board confirms.

Code of Conduct

Apache projects follow the ASF Code of Conduct. The PMC is the enforcement body within the project. Most enforcement is gentle and private. Serious cases are escalated to the board.

Release Responsibilities

Covered in detail in Release Voting. The PMC-specific elements:

• Binding +1 votes on release artifacts are PMC-only.
• At least 3 binding +1 required for a release to pass.
• PMC member is the release manager (or supervises if a non-PMC committer is designated by lazy consensus to RM under PMC oversight).
• Post-release, PMC member ensures the announce@apache.org mail goes out and the website is updated.

Security Reports

Security disclosures arrive at private@tez.apache.org or security@apache.org. The process:

1. Acknowledge receipt within 48 hours.
2. PMC investigates in private; reproduce.
3. Develop a fix in a private branch (not in apache/tez until disclosure).
4. Determine severity (CVSS) and assign a CVE.
5. Coordinate disclosure timing with downstream projects (Hive, etc).
6. Cut a release containing the fix.
7. Send disclosure to oss-security and security@apache.org with CVE and details.

The discipline: never discuss security issues on public lists or public JIRA until the fix has been released and disclosure is published.

If you are new to PMC, read the ASF Security Team process before you need it.

Board Reporting

The Apache Board oversees every project via quarterly reports. The Tez PMC submits a report each quarter (or per the schedule the board sets — currently quarterly with projects rotated through). The chair (or a delegate) submits it via https://reporter.apache.org/.

A standard report contains:

• Community activity (new committers, new PMC members, list activity)
• Releases since last report
• Brand or legal issues
• Health concerns the board should know about

The board looks for warning signs:

The chair is responsible for filing on time. If the report is late, the board notices.

Time Commitment

A PMC member with no other ASF roles spends roughly:

A PMC member who is also chair adds the report-filing burden and acts as the project's ambassador to the board.

Stepping Back

PMC membership is permanent until you step back. Emeritus PMC status exists for those who have stepped away from active project work but want to remain available for consultation.

To go emeritus:

Subject: [NOTICE] Going emeritus PMC

Hi all,

Effective <date>, I'm moving to emeritus PMC status on Tez. My
involvement in the project has tapered and I want the active PMC
to reflect who's currently doing the work.

Please feel free to reach out if you ever want a sanity check on
something I worked on historically.

Thanks for the years of collaboration.

<First>

PMC removes you from active count. You retain your ASF account; you may return to active later by vote.

Validation Artifacts

After this chapter:

1. A ~/tez-notes/pmc-duties.md listing the four buckets and a one-line example of each.
2. A subscription to private@tez.apache.org (when you are PMC).
3. Knowledge of how to verify an ICLA, how to find the trademark policy, how to file a board report.
4. A reflex to escalate security reports to private@ immediately and never discuss them publicly until disclosure.

The next chapter — Licensing — drills into the legal bucket: ALv2, LICENSE/NOTICE rules, and category A/B/X.