Community Interaction

This chapter covers the operational mechanics of communicating with the Apache Tez community — dev@tez.apache.org, JIRA, and the project's chat presence. Most of the "rules" below are not Tez rules; they are Apache-wide conventions that 25 years of mailing lists have settled into. Violating them is not a hanging offence, but it does mark you as new and costs you a small amount of credibility you have not yet earned.

The Lists

Tez has the standard ASF list set:

Subscribe to a list by sending an empty mail to <list>-subscribe@tez.apache.org. Confirm the reply. Unsubscribe via <list>-unsubscribe@tez.apache.org.

Default for new contributors: subscribe to dev@ and user@. Add issues@ once you are actively tracking JIRAs.

Mail Etiquette: Subject Prefixes

Subject lines on dev@ use ASCII-bracketed prefixes so subscribers can filter. Use them.

For a JIRA-related question, the subject is usually Re: [jira] [Created] (TEZ-NNNN) <title> — a reply to the bot mail.

Examples of good subjects:

• [DISCUSS] Promoting MROutput#getDelegationToken to @Public
• [PROPOSAL] TEZ-4321: Caching DAG plans across submissions
• [VOTE] Apache Tez 0.10.4 RC1
• [ANNOUNCE] New Tez committer: NAME

Mail Etiquette: Formatting

The ASF lists are plaintext-first. The hard rules:

1. Plain text only. No HTML, no rich text. Most clients have a "Send as plain text" toggle; set it as the default for *@apache.org recipients.
2. Inline reply, not top-post. Quote the relevant lines, reply below each.
3. Wrap at ~78 columns. Long unbroken lines render badly in archives.
4. Sign off. First name or first + last; not your full corporate signature block.
5. No attachments over a few KB. Patches go on JIRA, not the list.
6. No images. Diagrams as ASCII or as links to images hosted elsewhere.

A good dev@ reply looks like:

On Tue, May 7, 2024 at 10:14 AM, Foo Bar <foo@example.com> wrote:
> I think we should change the default of tez.am.resource.memory.mb
> from 1024 to 2048 to handle large DAGs better.

Agreed for large DAGs, but 2048 doubles the AM footprint for everyone
running small jobs (most CI users). Could we instead size it based on
DAGPlan size, falling back to 1024? Sketch:

  am_mem_mb = max(1024, dagPlanBytes / 1024 * 4)

I can prototype on TEZ-4XXX if there's interest.

-- 
Jane

What it doesn't have: HTML, a corporate disclaimer, a 2 MB inline screenshot, "+1" with no context, or "any updates?" with no quoted reference.

JIRA Etiquette

JIRA is the system of record for code-touching work. The mores:

Don't reassign

The Assignee field belongs to whoever is doing the work. If a JIRA is assigned to someone else, do not reassign it to yourself, even if it's been idle for a year. Comment first:

Hi @ASSIGNEE, I'd like to pick this up if you're not actively working on it. Happy to hand back if you have an in-flight patch. If I don't hear back in a week I'll assign to myself.

After a week of silence, then take it.

Ask before claiming high-traffic JIRAs

For high-visibility issues (release blockers, anything with multiple watchers), comment "I'll take a look at this" before you set yourself as assignee. This prevents two people working on the same fix.

"Patch Available" semantics

Setting status to Patch Available is a signal that means:

• A patch (or PR linked from the JIRA) is attached
• It applies cleanly to the current trunk
• The author believes tests pass locally
• The author is requesting review

It does not mean "I am still iterating." If you upload a draft, leave the status as In Progress and say so in a comment.

Status flow you control vs. don't

Patch naming convention

Patches attached to JIRA use the convention TEZ-NNNN.NNN.patch:

TEZ-4321.001.patch   <- first iteration
TEZ-4321.002.patch   <- after first review round
TEZ-4321.003.patch   <- after second review round

Branch-specific patches add a branch suffix:

TEZ-4321.branch-0.10.001.patch

Old patches stay attached — never delete them. The history is part of the review record.

Where the Tez Community Currently Lives

Tez does not have an official Slack or Discord. The active channels are:

If a #tez Slack channel does not exist, do not assume one. The mailing list is the official channel and is where decisions are made and archived. Slack/IRC is at most a hallway conversation that must be summarised back to the list.

Sister projects you may need to follow because Tez integrates with them:

• dev@hive.apache.org — Hive on Tez execution issues
• dev@hadoop.apache.org — YARN / HDFS compatibility
• dev@pig.apache.org — Pig on Tez (mostly inactive but exists)

Self-Introduction Template

A first post to dev@tez.apache.org after subscribing is optional but helpful. Keep it short:

Subject: [DISCUSS] Introduction and intent to contribute

Hi all,

I'm <first> <last>, a <role> at <company / "independent">. I've been
using Tez via Hive in production for ~<N> months and have been
reading the codebase to understand <component / area>.

I'm interested in contributing in the area of <one or two concrete
areas, e.g. "shuffle reliability" or "AM logging">. I've worked
through Levels 1-4 of the open-source-engineer curriculum and have
TEZ-NNNN (small Javadoc fix) ready as my first patch.

Happy for any pointers on first issues to tackle.

Thanks,
<First>

What this does:

• Signals you've done homework (not asking "how do I start?")
• Names a concrete area so committers can match you to mentors
• References a tiny first patch, so you've already shown you understand the workflow

What to avoid:

• "I'd like to contribute, please assign me a task" (no committer will do this for you)
• A list of grand redesigns
• A corporate signature block

Asking a Question on user@ Well

The format that gets answers:

Subject: Tez 0.10.x: AM OOMing on submission of 200-vertex DAG

Versions:
  Tez 0.10.3
  Hadoop 3.3.6
  Hive 3.1.3
  JDK 11

Symptom:
  TezClient.submitDAG throws OOM after ~12 seconds. AM log attached
  shows GC overhead limit exceeded inside DAGImpl.init.

Reproduction:
  - submit DAG with 200 vertices, each with 5 inputs
  - tez.am.resource.memory.mb = 1024 (default)

What I tried:
  - bumping to 2048 — works
  - reducing parallelism — works around but unwanted

Question:
  Is there a known scaling limit for DAGPlan size with default AM
  memory? Should the AM default scale with DAGPlan size?

Logs / DAG: <link to gist or paste in JIRA>

It gives versions, symptom, reproduction, what was already tried, and a focused question. A question that omits any of these gets a "please provide more info" reply, costing a round-trip day.

Validation Artifacts

After this chapter you should have, on disk and in the public archive:

1. A subscription confirmation to dev@tez.apache.org and user@tez.apache.org.
2. A self-introduction email posted to dev@, with archive URL saved.
3. One inline-reply (not top-post) reply to an existing dev@ thread.
4. A draft JIRA in JIRA (status Open) describing a real issue you've noticed.
5. A ~/tez-notes/etiquette.md cheatsheet with the subject prefixes table.

The next chapter — Patch Quality — is what your first attached patch needs to look like.