Becoming an Infrastructure team member

[Dave Neary]

Hi Ewoud,

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 wrote:
>> 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.

Thanks!
Dave.

-- 
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