I would suggest making sub-projects for each of the distributions and then use git submodules to tie it all together at the build level.

That way, you can restrict write access to particular users.

Alternatively, you could use protected branches and allow branch maintainers to manage those and have a small set of core mergers that bring it into the mainline.

Trevor

On Mon, Nov 21, 2016 at 12:45 PM, Shawn Wells <shawn@redhat.com> wrote:
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/

_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --