incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [DISCUSS] Re-election of podling committers before graduation
Date Mon, 11 Feb 2008 18:35:18 GMT

On Feb 11, 2008, at 8:59 AM, William A. Rowe, Jr. wrote:

> Niclas Hedhman wrote:
>> On Monday 04 February 2008 04:11, Robert Burrell Donkin wrote:
>>> STM that something along these lines would be a more lightweight but
>>> equally effective process. we could ask the PPMC if it's pruned
>>> inactive committers from the graudation list.
>> Personally, I don't see a difference between inactive committers in  
>> a podling than for a TLP.

I think there is a big difference between pruning committers from a  
podling and doing so for a TLP.

A podling is created with anyone who can sign an ICLA, accepted as a  
committer. The understanding that everyone who signs up will actually  
show up. In practice, this is not true, not necessarily due to any bad  
faith on anyone's part. So at graduation, the incubator PMC has to  
decide whether there is a community with independent actors who are  
"committed" to making the project a continuing effort. If there are  
committers who are not actually contributing, it makes the PMC's job a  
lot harder. It also diminishes the concept of meritocracy when folks  
who never participated are granted privileges that they didn't earn.

On the other hand, a duly constituted PMC doesn't allow non- 
participants to become committers or PMC members. Everyone must be  
voted in as committer or PMC member.

>> Should existing projects "prune" their committer lists on an annual  
>> basis? I think there is no need.
>
> The only argument for doing so is subversion access by 'abandoned'  
> accounts.
> With the oversight of commit logs, in practice this is not an issue,  
> so the
> one aspect that root might be concerned with is a user who does not  
> use
> their people.apache.org shell login for a substantial period of  
> time.  And
> those cases would be better handled by infrastructure with an ASF-wide
> policy to achieve their goals of security for the foundation machines.
>
> So I don't see a difference with 'pruning' TLP committers.  The only  
> time
> I'd encourage it is to revoke bits that we never used (you'll notice  
> over
> the long history of a project folks are given commit privs and never  
> use
> them.  In this case, the project didn't have a chance to perform any
> oversight if the privilege was used correctly, time makes it less  
> likely
> that the project will pay appropriate attention.)
>
> This is almost the exact same issue with a podling; if a user never  
> actually
> participates, as the project graduates should they remain a committer?

The difference is that committers in a TLP have been granted this  
privilege based on their merit, not just by updating a wiki page  
saying that they're interested.
>
>
> My gut check suggests the projects should ask those never-active  
> committers
> if they plan to participate, or if are unlikely to ever do so.  If  
> not,
> adjust the committers access list appropriately (inviting them to  
> come back
> whenever they have cycles and interest to contribute)

We already have the concept of emeritus members who, having  
contributed in the past, are no longer active. I'd like to leave it up  
to each PMC to decide whether or when to change the status of previous  
committers/PMC members.

Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message