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