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.
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
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, November 22, 2016 9:16:33 AM Subject: Re: How should we expand commit access to SSG?
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.
I think we can trust people have good intentions and there is no need to separate access like this. Either we trust the contributors and they can change anything or we don't trust them and we don't let them push any commits.
Many of the changes affect all the products and this separation would complicate that I think.
Hi Martin,
The reason that I'm suggesting this approach is twofold.
First, people are *really* nervous about screwing up someone else's material when they dive into a monolithic repository. I've had several people comment on how, while they hate the fact that we have 100+ repos, they like the fact that they can't accidentally mess up the rest of the system.
Second, different maintainers have different levels of attentiveness and may want to shoot their master branch out ahead of the pack.
I look at the SSG project as a top level project that is concerned with a build structure and several sub-projects that are concerned with various different software components.
Therefore, it would be great to be able to independently version control and develop each of the sub-projects and just rely on the top level project as a build infrastructure.
Thanks,
Trevor
On Mon, Nov 28, 2016 at 11:23 AM, Martin Preisler mpreisle@redhat.com wrote:
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, November 22, 2016 9:16:33 AM Subject: Re: How should we expand commit access to SSG?
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.
I think we can trust people have good intentions and there is no need to separate access like this. Either we trust the contributors and they can change anything or we don't trust them and we don't let them push any commits.
Many of the changes affect all the products and this separation would complicate that I think.
-- Martin Preisler Identity Management and Platform Security | Red Hat, Inc. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 11/21/2016 11:45 AM, Shawn Wells wrote:
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!
I'm still learning about the SSG community, but my suggestion would be to keep the deliberation process as public as possible. My experiences with open source communities have taught me that many assume the worst intentions when a decision was made in private. ;)
You could send a briefing to the mailing list about a pending vote/deliberation/argument and hold a weekly/bi-weekly meeting on IRC to allow anyone to drop by and discuss it. This has worked fairly well in the complex OpenStack community.
Long story short, you're not overthinking it at all. Open source software communities are always challenging and an open source community focused on security is even more difficult. ;)
- -- Major Hayden
----- Original Message -----
From: "Major Hayden" major@mhtx.net To: scap-security-guide@lists.fedorahosted.org Sent: Monday, November 28, 2016 8:49:36 AM Subject: Re: How should we expand commit access to SSG?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 11/21/2016 11:45 AM, Shawn Wells wrote:
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!
I'm still learning about the SSG community, but my suggestion would be to keep the deliberation process as public as possible. My experiences with open source communities have taught me that many assume the worst intentions when a decision was made in private. ;)
You could send a briefing to the mailing list about a pending vote/deliberation/argument and hold a weekly/bi-weekly meeting on IRC to allow anyone to drop by and discuss it. This has worked fairly well in the complex OpenStack community.
Long story short, you're not overthinking it at all. Open source software communities are always challenging and an open source community focused on security is even more difficult. ;)
+1, although our community is nowhere near the size of OpenStack's. I think requesting commit access on mailing list and then discussing it in that thread should be enough.
In case of SSG we tend to give commit access to people who have gotten "more than a few" substantial PRs merged. This works fairly well but is not transparent.
We should probably keep that as a necessary prerequisite but set the number to something specific - say 5 PRs. I do not think we need to get overly serious and require sponsors and thinks like that. 5 high quality PRs goes a long way. And substantial means it's not jut a typo or identifier fix.
Thoughts?
On 11/28/2016 10:29 AM, Martin Preisler wrote:
We should probably keep that as a necessary prerequisite but set the number to something specific - say 5 PRs. I do not think we need to get overly serious and require sponsors and thinks like that. 5 high quality PRs goes a long way. And substantial means it's not jut a typo or identifier fix.
That seems reasonable and it follows patterns that are already in use for plenty of other open source projects. ;)
-- Major Hayden
scap-security-guide@lists.fedorahosted.org
-
Major Hayden -
Martin Preisler -
Shawn Wells -
Trevor Vaughan