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
- 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.