Home / About Mozilla / Policies /

Becoming A Mozilla Committer

This document outlines the procedure for getting commit access to the Mozilla Foundation repositories.

In all cases, you need to demonstrate you know what's going on, find a person or people who have adequate authority and will vouch for your competence, and complete and sign a Committer's Agreement.

Procedure

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.

  1. Read the Commit Access Policy, and decide which level of access you need to apply for.
  2. File a bug in the "Repository Account Requests" component.
    • Make the bug title of the form "Commit Access (Level X) for Fred Bloggs"
    • 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
  3. Attach your SSH public key to the bug - a file with extension ".pub". (Please mark it as text/plain when attaching it!)
  4. Send us a completed Committer's Agreement.
  5. Update the bug to note that you've sent in the Agreement.
  6. 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.
  7. An appropriate Mozilla representative will update the bug when they have received your signed Agreement.
  8. 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
    • Comment from Mozilla that agreement has been received
  9. 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.
  10. A Mozilla IT representative will update the bug with account creation information and close the bug.

Contributor Form

You'll need to fill out and submit the Committer's Agreement (both sections 1 and 6) to get your account set up. Read it carefully - signing it indicates you understand and agree to our legal requirements. Breaking these rules could cause legal problems for Mozilla and may cause us to revoke your access. If you have any questions, ask us.

Vouchers

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 his or her 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.

Dormant Accounts

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.

Problems With Your Account