On 03/11/2013 04:14 PM, Ewoud Kohl van Wijngaarden wrote:
On Mon, Feb 25, 2013 at 05:26:26PM +0100, Ewoud Kohl van Wijngaarden
> As I see it one big problem is trust. In traditional open source you
> submit patches until the trust is built. With infra this is harder.
> quaid suggested the following flow:
> 1. Join our meeting and/or active on the ML
> 2. Give SSH to look around on the server
> 3. Add limited sudo to that SSH access
> 4. Full sudo
> With puppet we can make larger parts of our infra public without SSH and
> even accept patches, but that's longer run since we have to set that up
> and get it going first.
I think this process (which is more or less what we have now) looks fine!
I know in other projects, there's no way that you would give someone
access to (say) add a new extension to MediaWiki until he had proposed
the addition of a few extensions first - explaining what it would be
useful for, and showing awareness of things like community health, code
security and the potential impact for spam management. Also, submitting
patches to mediawiki themes, extensions, etc. is a great way to show
taste & judgement, and familiarity with the project.
There's a balancing act between giving access pro-actively, perhaps too
soon, and waiting too long, and frustrating a potentially valuable
contributor. The tipping point is when the person wants to do something
useful/valuable, and has shown that he knows how to do it without
messing other stuff up, but no-one else has the time or skills to do it.
Rydekull's recent re-activation of the oVirt wiki bot is a good example.
We should also minimise the risk that a new guy can irremediably ruin a
server - back-ups, configs in puppet & software deployed in git all help
to mitigate this.
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13