---
layout: section
title: "Become A Committer"
permalink: /contribute/become-a-committer/
section_menu: section-menu/contribute.html
---
<!--
Licensed 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.
-->

# Become a Committer

An Apache Beam
[committer](https://www.apache.org/foundation/how-it-works.html#committers) 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](https://www.apache.org/dev/committers.html#committer-responsibilities)
for more about being a committer in the Apache Software Foundation.

The [PMC](https://www.apache.org/foundation/how-it-works.html#pmc-members)
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](https://lists.apache.org/list.html?dev@beam.apache.org) and [statistics](https://lists.apache.org/trends.html?dev@beam.apache.org)
 - [user@ archives](https://lists.apache.org/list.html?user@beam.apache.org) and [statistics](https://lists.apache.org/trends.html?user@beam.apache.org)
 - [`apache-beam` StackOverflow tag](https://stackoverflow.com/questions/tagged/apache-beam)
 - Git metrics for [Beam](https://github.com/apache/beam/graphs/contributors)
   and the [Beam site](https://github.com/apache/beam-site/graphs/contributors)
 - Code reviews given and received on
   [Beam](https://github.com/apache/beam/pulls) and the [Beam
   site](https://github.com/apache/beam-site/pulls)
 - 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](https://www.apache.org/foundation/policies/conduct.html). 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](https://www.apache.org/dev/committers.html#committer-responsibilities).

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

