On Dec 31, 2009, at 3:40 PM, Joe Schaefer wrote:

>> 
>> As I said, we do not have a hard and fast rule on length of time,
>> but this "nebulous notion" is what makes the ASF work.
> 
> If that were true the incubator would need to be completely reworked, 
> because the process we use here is basically a filter on those that
> offer to participate- graduating projects select from their committer
> rosters who they'd like to carry on as committers or add to the PMC
> when they go top-level.

And the incubator is not your typical ASF project.  By design, getting the 
right to commit is fairly easy. It is necessary to aid projects get off the 
ground.

> 
>>  The point of having a version control system
>>> in place is that we can be lax in how we dish out permissions to it 
>>> *because*
>>> it's easy to fix mistakes *after* they happen.  The overriding goal is to 
>>> weed
>>> out people who consume more collective energy than they give back, not to 
>> bestow
>>> an honorific title on those that clear the bar.
>> 
>> No, you have it backwards.  Merit is earned and with it comes
>> influence. You don't get it instantly and then lose it. I don't
>> think "weeding out" those who consume more than they contribute as
>> an organizing principle would work.  It is certainly not the way we
>> have been operating up to now at the ASF.
> 
> You have conflated the symbols of authority with true authority- merit
> has nothing to do with one's committer status.  Being a committer doesn't 
> confer instant credibility any more than being a non-committer means one
> is clueless.  If a committer doesn't know how to work productively with
> his/her peers, his/her work won't have any recogizable merit to those people,
> which in the end is what matters most.  Just because someone has commit 
> doesn't
> mean they have any control over the direction of a project, or even their own
> fate- that rests with the PMC.

In every ASF community I have been involved in some amount of community 
participation has had to take place before being granted commit rights. No one 
wants to find out that a person can't work productively with his/her peers 
after they have been granted commit rights. This varies from community to 
community but never have I experienced commit rights being given without some 
vetting. The closest to that was Commons, which is fairly lenient for people 
who already have commit rights elsewhere or are a member. But even there some 
level of commitment has to be demonstrated.  On the other hand, in these 
communities once granted commit rights are rarely taken away unless the person 
asks to become emeritus or for some fairly extreme reason - which in my 
experience has been rare. 

Some projects delay granting commit rights because they also make the person a 
PMC member at the same time. In others, commit rights are handed out a little 
more freely but PMC membership takes quite a bit more time. Each project is 
free to handle it in the way they feel is best for their community.

In all these communities anyone who has commit access has more influence then 
someone who doesn't, if for no other reason than they can take a patch from a 
Jira issue and commit it while everyone else can't. In most projects even 
though a committers vote won't officially count their vote on an issue still 
carries more weight than someone without that right. 

So to claim that being granted commit rights doesn't have anything to do with 
one's "authority" is incorrect.

Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to