Identifying potential new committers, calling a vote for their recognition as a committer and processing the relevant documents are tasks to which the whole community can contribute.
Each project has a different approach to managing new committers. This page describes a common process found in many Apache projects. It also provides draft templates for the various communications that are necessary.
Some of the PMCs automatically make committers PMC members. The templates below
have conditional [if]
clauses for that.
If the PMC has separate process for approving PMC members, see
new PMC member.
The Contributor Ladder helps explain different roles.
TL;DR - Inviting a new Committer ¶
- Discuss the proposed committer (and optionally PMC member). (Use the committer discuss template.)
- If the discussion seems to be going positively, call a vote. (Use the committer vote template for committer, the committer + PMC member vote template for committer and PMC member.)
- Close the vote. (Use the committer vote results template for a committer vote, or the committer + PMC member vote results template for a committer + PMC member vote.)
- If the result is positive, invite the new committer. (Use the committer invite template.)
If they accept, then:
- If they already have an Apache id, grant appropriate commit privileges. Use the Whimsy tool to update the roster via Comitee Roster or PPMC Roster
- If they have already filed an ICLA, request creation of the committer account.
If they need to change anything in a previously filed ICLA, wait until the new ICLA is filed,
then request the account.
- Wait until root says it is done
- PMC Chair updates LDAP group membership which enables svn, gitbox and other access. If the committer uses GitHub, let them know that they are responsible for linking it to their ASF account.
- Add committer to the appropriate access groups for any services that your project uses, which are not tied to ASF LDAP.
- Notify the committer of completion. (Use the committer welcome template
- If committer is also to be a PMC member, the PMC Chair or other PMC members must update the PMC roster See new PMC member for more detail.
- Announce the new committer. (Use the new committer announcement template.
Guidelines for assessing new candidates for committership ¶
Each project must decide what is the correct measure for inviting a new committer to their project. There are, however, several things that we encourage you to consider.
Any PMC member can (and should!) nominate project contributors for a committer vote. Don’t assume that the PMC chair, or some senior project member, will do this. Watch the contributors, and nominate promising participants.
Remember that we do all of our development in revision control. Errors are reversible learning opportunities. Thus, inviting someone “too early” has very little risk associated with it. On the other hand, inviting someone too late has the very real risk that they’ll get frustrated and leave, and you’ll have missed that opportunity forever. Setting the bar too high has been the eventual death of many projects.
Think of adding committers as an investment in the future of your project, rather than as a reward for good behavior. Committers whom you add today will be the backbone of your project tomorrow, or five years from now. New committers are the only way to ensure the long-term sustainability of your project. Look for contributors who seem to have new ways of thinking.
Think of a committer as someone who is committed to the project, rather than just someone who writes code. Contributions in other areas, such as design, end-user support, event management, documentation, or project promotion, should also be welcomed into the project by inviting them as committers, and, eventually, as PMC members.
Finally, if you have specific requirements for committers (such as a period of time, or number of contributions) we encourage you to document that on your website. People like to know what their “career path” is in a project, rather than feeling that it is merely at the whim of a secret committee. If you see someone who seems to be on the path, point them to this document, so that they know what to expect, and what they can do to become a better contributor. See also Becoming A Committer for general advice you might offer.
The following are some points to consider when assessing a candidate’s qualifications for committership.
Ability to work cooperatively with peers. ¶
How do we evaluate?
- By the interactions they have through email.
- By how they respond to criticism.
- By how they participate in the group decision-making process.
Ability to be a mentor. ¶
How do we evaluate?
- By the interactions they have through email.
- By how clear they are and how willing they are to identify or even create appropriate background materials.
Community ¶
How do we evaluate?
- By the interactions they have through email.
- Do they help to answer questions raised on the mailing list; do they show a helpful attitude and respect for other people’s ideas?
Commitment ¶
How do we evaluate?
- By time already given to the project.
- By how well they stick with the process through tough issues.
- By how they help on not-so-fun tasks.
Personal skill/ability ¶
How do we evaluate?
- A solid general understanding of the project.
- Quality of discussion in email.
- Whether their patches (where applicable) are easy to apply with only a cursory review.
New Committer Process ¶
This section describes a typical Apache project’s process for handling the vote to add a new committer. Templates mentioned in the process appear later in this document.
Discussion ¶
We do the discussion and vote on the private@
mailing list to enable a frank
discussion. Any PMC member may propose a potential committer or PMC
member. This is not the sole responsibility or right of the PMC
chair.
You can use the committer discussion template to start the discussion
We invite people to join as committers/PMC members, not GitHub ids. It is fine to refer to the candidate’s GitHub id for context, but the person should be referred to by their name. It is not necessary to have their full legal name (that will be kept private) but it is important to use their name, as they refer to themselves in email. If a person is known only by their GitHub id, it is ok to ask them for their real name prior to holding a VOTE.
We need to be sure that they are committed people with whom we can work. They will be our peers. We will have already observed that they are committed to the project and graceful toward users and other developers.
Don’t wait too long before proposing and don’t be too hasty. There is a trade-off and something about timeliness. A point is reached where it becomes obvious that we should invite them. This encourages them and keeps them enthusiastic. If we leave it too long, then we risk them becoming disillusioned.
On the private@
list we can each say exactly what we feel about each person,
with no holds barred. Keep the discussion concise. The praise part can
be done later in public. Keep in mind, however, that if the member becomes
a PMC member later, they will have access to this discussion.
Vote ¶
If the proposed candidate seems to be received positively by a majority of those responding, it’s time to start a vote.
In some projects, new committers are automatically also made PMC members. If this is the case in your project, use the committer + PMC member vote template instead.
Start a separate [VOTE] thread for each new person. This makes it much easier to review the email archives.
Let the Vote thread run for one week.
A positive result is achieved when there are at least 3 +1 votes and no vetoes, as per the ASF voting process document.
Announcing results ¶
After a positive result, record the result on the PMC list with a [RESULT][VOTE]
subject
and then invite the candidate, using the committer vote results template
for a new committer, or the committer + PMC member vote results template
for a committer and PMC member.
We give candidates a chance to decline committership in private. They can post a reply to the PMC mailing list.
After we reach a decision on the private@
list, and after the steps above, we
announce the new committer on the dev
list
Alternately, use the committer + PMC member announce template for new committer + PMC member.
You can use the new committer welcome template to welcome the new committer to your project community. You are, however, encouraged to create your own version of this template, customized to your particular project community.
Other notes about the process are available on the main Apache site.
Committer Account Creation ¶
Please see the account creation instructions.
In summary:
If the ICLA identifies the project and a valid Apache ID, and the
[RESULT][VOTE]
message has been posted to the PMC private list,
the account creation request is made by the
secretary or assistant secretary who files the ICLA.
Otherwise, the new account request should be made by the PMC Chair (or any ASF Member if the chair is unavailable).
The PMC chair needs to use the ASF New Account Request form to send a new account request. Members may use ASF New Account Request page.
Please supply the mail archives URL as proof of the vote results.
Email Templates ¶
The following templates are recommended ways to phrase your email communications around inviting a new committer, to ensure that everyone understands your intent.