New Commit Access Policy: Benefits For You

After discussion, we have now written and implemented a new Commit Access Policy. The aim here is to reduce bureaucracy and enable easier collaboration within the project and with those outside it.

In summary, there are 3 levels of access a person may have:

  • Level 1 – Try/User/Incubator access
  • Level 2 – General access (everything else)
  • Level 3 – Core product access (Firefox/Fennec/Thunderbird)

This policy has the following benefits for you:

  1. It is much easier for Mozilla community members to bring in external people to collaborate with.

    If you have general Mozilla commit access (level 2), you can create a user repo and file a bug to give level 1 access, which includes user repos, to anyone you want to collaborate with. It only needs your say-so (and you are responsible for their conduct).

    Also, new community members can get access to the try servers earlier in their Mozilla life. Please encourage people to ask for this early if it would help them.

  2. It is much easier for Mozilla community members to contribute across the project.

    Those with level 2 access (which is most people) can now check in everywhere except the core product repos (level 3) and those on the list of exceptions[1]. So if you write a patch to e.g. mozbot or a webtool or a website, you can check it in yourself (after review).

    People can move to working on a new project or area of the project without an impeding step of having to get some SCM auth file updated.

In addition, the technical changes on the back-end mean we are now storing approved access levels separately from individual SCM enablement – so we can disable dormant accounts, and yet re-enable them easily when necessary without having to go through a re-authorization step.

Please let me know if you have any further comments on this new system.

6 thoughts on “New Commit Access Policy: Benefits For You

  1. There is another change for level 3: there is no requirement that the superreviewer hadn’t reviewed a patch from the applicant. That had a net benefit on my application, since nearly half of the 31 superreviewers had already reviewed one or more of my patches.

  2. I think you should have something more generic for the named voucher. This or that component owner, for example. Anything can happen, and having to change all reference to the named voucher on the day for some reason it changes would be annoying.

  3. glandium: that’s actually a different change which happened at the same time. But I’m glad it benefitted you :-)

    Brian: L10n access is a bit special – see the note about it in section 1A.

    jmdesp: I’m not sure I understand your point…

Leave a Reply

Your email address will not be published. Required fields are marked *