Becoming A Mozilla Committer
This document outlines the procedure for getting commit access to the Mozilla Foundation repositories.
You will need to demonstrate you know what's going on, and find a person or people who have adequate authority and will vouch for your competence.
Here is a list of the steps that need to happen to become a Mozilla committer. Employment with any particular entity (including the Mozilla Foundation or Corporation) does not change the need to follow these steps.
- Read the Commit Access Policy, and decide which level of access you need to apply for.
File a bug in the "Repository Account Requests" component.
- Make the bug title of the form "Commit Access (Level X) for Fred Bloggs email@example.com"
- Say what email address you want to use as your login name
- If you need access to particular trees on the exceptions list, list them
- Attach your SSH public key to the bug - a file with extension ".pub". (Please mark it as
text/plainwhen attaching it!)
- GitHub has a useful tutorial on generating SSH keys.
- Make sure you are happy with the Commit Access Requirements.
- Add a comment to the bug saying “I have read, and agree to abide by, the Commit Access Requirements.”
- Get your voucher(s), and/or the owner of the exception tree you want access for, to add a comment to the bug saying they support your application.
- So, to recap, the bug needs:
- Declaration of what level you want and the email address to use
- SSH public key
- Comments from all the necessary vouchers
- A Mozilla representative will double-check that the needed info is recorded and, if so, reassign the bug to IT to have your account created.
- A Mozilla IT representative will update the bug with account creation information and close the bug.
You will need one or more vouchers. The Commit Access Policy sets out who is allowed to vouch, and it depends on what level of access you are requesting. Each voucher must already have commit access and be confident enough in you to be associated with your check-ins. Your vouchers are responsible for your bustages in the unfortunate event that you break things and leave. They are responsible for making sure you know and follow the rules in general, act promptly to fix regressions, are aware of and respect tree closures, etc. The vouchers' responsibility extends for three months after you are granted source code commit access. If you've lived in the tree without significant issues for three months, we assume you're ready to stand on your own. If somehow there are persistent problems during the first three months, the vouchers have the authority to request revocation of your access during this period. Vouching is a big responsibility, so people will make this commitment only after due consideration. A voucher who helps people who aren't prepared get access to the source tree will find that their own credibility suffers as well.
Revoking Commit Access
If someone consistently causes difficulties with these source repositories due to poor behavior or other serious problems then commit access may be revoked. We have no precise process for this as it has been a rare or nonexistent problem to date. The process for this is for one or more committers with concerns to notify the owner of the Commit Access Policy sub-module if you have clear examples of someone whom you believe has reached this level of problem. Do not do so carelessly, or based on passing irritation or without a sense that you are not alone in your concerns. The Commit Access Policy owner will investigate or cause an investigation to occur, privately at first and perhaps completely privately.
If your account in a particular SCM is inactive for more than 6 months, it may be deactivated. However, the knowledge that you have achieved a particular level of access is retained. Therefore, getting your account reactivated is a simple matter of filing a bug asking IT to turn it back on. Such bugs should be dealt with extremely quickly.