layout: section title: “Become A Committer” permalink: /contribute/become-a-committer/ section_menu: section-menu/contribute.html

Become a Committer

An Apache Beam committer has write access to the repository for merging pull requests, but you don‘t have to be a code contributor to become a committer. Becoming a committer means that you have the project’s trust. Read the ASF documentation for more about being a committer in the Apache Software Foundation.

The PMC makes someone a committer via nomination, discussion, and then majority vote. We use data from as many sources as possible to inform our reasoning. Here are some examples:

dev@ archives and statistics
user@ archives and statistics
apache-beam StackOverflow tag
Git metrics for Beam
Code reviews given and received on Beam
Clear areas of ownership (a runner, a DSL, IO connector, documentation, etc.)
Public events
Firsthand PMC testimonials

The PMC has assembled the following set of guidelines for becoming a committer.

An Apache Beam committer...

Takes many forms

There are many actions other than coding that build the trust we place in a committer - code review, design discussion, user support, community outreach, improving infrastructure, documentation, project management, etc.

Knows, upholds, and reinforces the Apache Software Foundation code of conduct

See the ASF documentation. In particular, they manifestly strive to:

Be open
Be empathetic
Be welcoming
Be friendly
Be patient
Be collaborative
Be inquisitive
Be careful in the words that they choose

Knows, upholds, and reinforces the responsibilities of an Apache Software Foundation committer

See the ASF documentation.

They help create a product that will outlive the interest of any particular volunteer (including themselves)
They grow and maintain the health of the Apache community
They help out with surrounding work, such as the website & documentation
They help users
They can be trusted to decide when code is ready for release, or when to ask someone else to make the judgment
They can be trusted to decide when to merge code (if a code contributor) or when to ask someone else to make the judgment

Knows, upholds, and reinforces the Beam community’s practices

They have a proven commitment to the project
They share their intentions with the community
They accept and integrate community feedback in their plans, designs, code, etc.
They earnestly try to make Beam better with their contributions
In particular, if a code contributor:
- They earnestly try to make Beam better with their own code
- They earnestly try to make Beam better with code review
- They accept and integrate feedback on their code
- They know, follow, and enforce Beam’s practices while reviewing/merging code - style, documentation, testing, backward compatibility, etc.