SSG originated from NSA. They collaborated with Red Hat to help build a community and author content for RHEL. The community has since expanded -- both in terms of people from across the world and content beyond Red Hat related things. Success!

As our community and content expands, we should figure out how to handle commit access to the SSG repo. Some 95 people have submitted code patches to SSG [0]. 18 of them have currently have commit/merge access. The vast majority of the merge-access group are Red Hat staff, followed by trusted partners like Gabe/redhatrises and Joe/joenall, a then smidge of government (NSA, DISA FSO).

With content being developed and maintained for Ubuntu and WRLinux, I think it makes sense to those "core maintainers" commit access. These are the people who care most deeply for that body of content and have shown good judgement to determine what's best for the overall code base, their particularly content of interest, and broader community. These individuals would still follow normal PR processes for their own code, but could merge PRs of others.

IMHO, the "Managing Participants" section of Karl Fogel's 'Producing Open Source Software' book has a well thought out approach:
http://producingoss.com/en/committers.html

In short: It's not about complexity or frequency or code contributions because there are many non-programmer contributors. Elevate privileges of those who show good judgement and community stewardship.

Then there's the procedural side. Who has a say in who gets commit access? Where does deliberation happen? Having a 'public vote' on the mailing list risks turning into a popularity contest. Having a 'secret council' risks loosing community trust. Both situations are equally unappealing. I'm not really sure to handle this. And I recognize I'm likely over thinking this!

Historically, it has been fairly apparent who should get merge access and when. Generally these decisions were met by the community with "yeah, $person totally makes sense!" Access was granted by Jeff Blank or myself after we ran it by a few other communicate members. Simon (now Martin) maintain appropriate accesses for the full-time Red Hat engineers. This model has worked well for us so I propose keeping with it. The guiding principal remains good judgement and community stewardship.

We now have many new community members and several new bodies of content being developed. Even if we remain on the same process it seems healthy to revisit the conversation on-list.


[0] http://people.redhat.com/swells/gitstats/ssg/