----- Original Message -----
From: "Major Hayden" <major(a)mhtx.net>
To: scap-security-guide(a)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?
--
Martin Preisler
Identity Management and Platform Security | Red Hat, Inc.