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: <42D33169.9080503@toolazydogs.com>
References: <Pine.LNX.4.58.0507112144060.17586@saturn.opentools.org>
 <3FD9DE78-7281-4086-8055-F584CCAD9044@apache.org>
 <42D33169.9080503@toolazydogs.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C4FF6FC6-818A-4F95-B10F-D36279D70F82@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: Donations & Policies
Date: Tue, 12 Jul 2005 11:43:20 -0400
To: dev@geronimo.apache.org


On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:

>
> I think that we should have a single simple process.
> All vendors must propose the code donation to the community.   
> Embarrassing denials can be averted by creating a gmail account and  
> asking if people are interested in technology X going into Geronimo.

s/vendors/contributors/

Also, anyone can approach the PMC privately on  
pmc@geronimo.apache.org if they wish to discuss a contribution before- 
hand.  I see nothing wrong with that, and yes, if satisfied, we then  
ask the contributor to propose directly to the community on dev@

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

geir

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