Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <42D4611D.1000206@toolazydogs.com>
References: <Pine.LNX.4.58.0507112144060.17586@saturn.opentools.org>
 <3FD9DE78-7281-4086-8055-F584CCAD9044@apache.org>
 <42D33169.9080503@toolazydogs.com>
 <C4FF6FC6-818A-4F95-B10F-D36279D70F82@apache.org>
 <42D4611D.1000206@toolazydogs.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <76288319-22FA-4B9A-A8EF-C95EB13A2ADF@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: Donations & Policies
Date: Tue, 12 Jul 2005 22:01:34 -0400
To: dev@geronimo.apache.org


On Jul 12, 2005, at 8:32 PM, Alan D. Cabrera wrote:

> Geir Magnusson Jr. wrote, On 7/12/2005 8:43 AM:
>
>
>>
>> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
>>
>>
>>>
>>> All code donations go into
>>>
>>> /geronimo/incubator/donationx/*
>>>
>>> The contributors would get restricted committer access to their   
>>> project; granting committer access gives us better visibility  
>>> how  well the person works in a community setting.  They and,  
>>> hopefully  Geronimo committers, would whip it into shape.  The  
>>> community would  provide guidance and, hopefully, vote it into  
>>> Geronimo once its  ready and all the appropriate paper work was  
>>> obtained.
>>> The "probationary" committers would, hopefully, get voted into   
>>> Geronimo, regardless of their projects status.  I have never  
>>> heard  of a motivated developer not getting committer access.
>>>
>>>
>>
>> I'd like to propose a slight modification.  That we give them   
>> committer access w/o a formal, restricted ACL, but a clear   
>> understanding that there's a place where they are bring brought in  
>> to  work, and if they wish to participate elsewhere, they do so  
>> via  standard engagement of working with others, learning about  
>> the area,  proposing changes on dev@ etc, until they and others  
>> are comfortable,  etc.
>>
>> Any change can be vetoed, and any change can be rolled back.  I  
>> think  we should assume a level of trust, and if broken, commit  
>> priv can be  revoked.
>>
>> Just consider for a little while.  I believe that this won't be a   
>> popular suggestion, but the risk is small, and the upside great,  
>> it  keeps things simple, and I believe leads to a more unified,  
>> richer  community. :)
>>
>
>
> I don't think that the extended privs would necessarily lead to "a  
> more unified, richer  community" but would, instead, increase the  
> burden on those Geronimo committers charged with monitoring the  
> contribution under probation.

Let me elaborate - the burden is the same.  We are responsible for  
the entire codebase.  Whether or not the new committers have an ACL  
that lets the write to modules/kernel doesn't remove our  
responsibility for the new code that was brought in.

I can picture a process where there is no probation.  We'd be saying  
that the contribution of the code is, to the PMC, reasonable  
demonstration of commitment (this is a judgement we'd have to make  
each and every time for every offered contribution), and that we are  
willing to trust that they'll work on that contribution in a "good  
way" with us.  For the other parts of the Geronimo codebase, we ask  
that they never just go jumping into anything, but work with the  
other committers to be sure that they are working in a way compatible  
with the existing community.

Anyone who violates that trust that we offered will have committer  
privs revoked.   Anyone who respects the trust offered will naturally  
blend into the rest of the committer community.

Any bad code change can be vetoed (and I think that we must become  
more comfortable with vetoing and more comfortable as accepting it in  
a non-personal, technical manner...)

I think that this is the cleanest, simplest and most elegant way.   
OTOH, I do recognize that there's a large element of trust as well as  
a real lack of exposure and experience with the new people we'd be  
bringing in.  OTOOH, there are no guarantees in life :)

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org