Open Bug 760153 Opened 12 years ago Updated 5 years ago

Generalize our commit access policy so it more clearly covers GitHub

Categories

(mozilla.org :: Governance, task)

Product:
mozilla.org
Component:
Governance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: gerv, Unassigned)

References

Details

http://www.mozilla.org/hacking/committer/ doesn't really talk about how one gets access to commit to the Mozilla repos on GitHub. 

My proposal is that it should say that you should go through the normal process for L2 access, and based on that, you can then request membership of any GitHub team. And such memberships should not be granted outside this process (which ensures that people have Committer's Agreements on file).

Such a request for membership should normally be granted; there is no need to prove you "need" it. (Although clearly, if someone commits in violation of review requirements etc. then a) they get the cluebat, and b) the person who vouched for them is on the hook for their behaviour.)

Gerv
This doesn't seem very compatible with current practices. I don't actually know, but I assume there are many people who can grant GitHub mozilla sub-repo access, and they presumably quite enjoy the current low-procedural-overhead. Bottle-necking those requests on our current commit access procedures is not going to be very popular, and probably won't scale very well (I think there aren't enough people currently handling the account request bugs to handle an extra influx of requests).
Adding James to this because I'm pretty sure he has access to the mozilla thingy on github.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #1)
> This doesn't seem very compatible with current practices.

100% agree, it's a dramatic shift from our current practices.

> I don't actually
> know, but I assume there are many people who can grant GitHub mozilla
> sub-repo access, and they presumably quite enjoy the current
> low-procedural-overhead.

True. Especially see my point about ADMINISTRATIVE access later.

> Bottle-necking those requests on our current commit
> access procedures is not going to be very popular, and probably won't scale
> very well (I think there aren't enough people currently handling the account
> request bugs to handle an extra influx of requests).

I'm not sure there would be an extra influx of requests. Pull requests make it much easier to get code committed without having commit access. Some sort of easy, non-human way to know who had a signed committer's agreement would be nice, though.


(In reply to Gervase Markham [:gerv] from comment #0)
> Such a request for membership should normally be granted; there is no need
> to prove you "need" it. (Although clearly, if someone commits in violation
> of review requirements etc. then a) they get the cluebat, and b) the person
> who vouched for them is on the hook for their behaviour.)

Honestly, this is a part of the L-system of access that seems counter to security best practices. Even people behaving in good faith may have their accounts hacked, and only granting commit (or administrative) access to repositories people do need access to seems like good sense just to minimize damage potential. This is a pretty straight application of the principle of least privilege.

This also doesn't address a unique feature of GitHub: repository administration access. GitHub basically has 3 kinds of teams, 2 of which are relevant here:

1) Team grants PULL access from (private) repos. Not really relevant for us.
2) Team grants PUSH & PULL access to and from repos.
3) Team grants PUSH, PULL and ADMINISTRATIVE to and from repos. This level of access also allows people to do things like add members to the team and create new repositories under the organization.

My preference has always been to create two teams per repo (or related group of repos) one with ADMINISTRATIVE and one with just PUSH & PULL. However, many teams are small and don't want the overhead, so everyone has ADMINISTRATIVE.

Finally, there is a set of organization "owners" (including me) that have PUSH, PULL and ADMINISTRATIVE access to every repo in the organization. I believe this list is too large right now, because (either GitHub changed or) we misunderstood that you only needed to be granted ADMINISTRATIVE access to be able to create new repos. Though you do still need to be an owner to create new teams or assign teams to repos.
I have thoughts on github stuff, but it would take me several hours to formulate a concise and coherent position on that.  So instead I'll play a different process card and point out that applying the current commit access policy to code repositories that don't have defined modules is pointless.

In Bug 760150 Nigel has asked for commit access to some webdev repos on github.  jsocol vouched for him.  jsocol isn't a peer or owner of any module listed at https://wiki.mozilla.org/Modules/All, so per the commit access policy his vouch doesn't count.  In fact, I can't find a single person who has authored a changeset in https://github.com/mozilla/input.mozilla.org who is an owner or peer of any module listed.
I had some thoughts on a solution and I had a chat with khuey on IRC about this.  khuey, brought up 2 things - one is that we have to hammer this into the existing commit access policy somehow and two is that we need to define modules for all this stuff.

So, I think a good option at this point is to split the repos in github.com/mozilla into modules like webdev, automation,  b2g, and have peers and owners as is our current procedure with everything that's in mozilla-owned infrastructure.
So, here's my strawman proposal:

1) Define modules for the relevant github repos through existing governance structures.
2) Treat repos stored in github as Level 1a repos.  That is, the requirement for getting PUSH access to a github repo is a vouch from the owner or peers of the relevant module.
3) ADMINISTRATIVE access will be restricted to the module owner/peers/and their delegates/whatever.

This ensures that we get committer's agreements on file for these repos while imposing the minimum process burden.

Comments?
We've already started drawing up what makes sense as modules. There isn't a 1-1 mapping of "module"<->"repo", though. For example, the input.mozilla.org repo and the input-lib repo are both part of the input.mozilla.org "module." I don't think that's a wrench in your proposal, just a bit of an FYI.
Yeah, I'm aware that there are cases like that.  It shouldn't be a big problem (we already deal with the multiple modules in one repo case for Firefox, with social controls and the review process).
Also keep in mind that github/mozilla has 421 repositories right now. Are you suggesting every one of those be mapped to its own module? Even if every module has 2 repos on average, you'll still have > 200 new modules.
What has to be done to progress this?  We have contributors waiting in the wings, who would no doubt be contributing more code if it was fixed.

/me volunteers to help with anything that needs doing.
I'm sorry; I haven't given this bug the attention it deserves.

The idea of defining modules for all this new stuff is an awesome one, and the correct fix for a number of things, not just this. Module ownership is Mozilla's community governance authority mechanism, and when it's not present in an area of activity, authority falls back by default on paid people, but can often do so in an opaque way which leaves non-paid people feeling like they have no visibility into decision making. So yay for more modules. :-)

So I like Kyle's plan in comment #6.

It's up to those working in the relevant areas to propose modules - the procedure is here:
https://wiki.mozilla.org/Modules
Even the top-level categories are not good for this :-| I would start by emailing a heads-up to the Module Ownership team, and then send them your module proposals for a once-over. If it doesn't seem controversial, post to mozilla.governance.

Gerv
Assignee: gerv → nobody

Kim, is this something you may be interested in? There are various commit access bugs open in different components, most of them not under 'Governance'.

Flags: needinfo?(kmoir)

Redirecting to glob, not sure if he has thoughts on this as he has been looking at developer workflow processes and documenting them or if this is more of a governance issue outside the scope of our team.

Flags: needinfo?(kmoir) → needinfo?(glob)

this is very much a governance issue, and falls into the category of "the whole module system is overdue an update".

Flags: needinfo?(glob)
You need to log in before you can comment on or make changes to this bug.