----- Original Message ----
> From: Ralph Goers <ralph.go...@dslextreme.com>
> To: general@incubator.apache.org
> Sent: Thu, December 31, 2009 9:27:26 PM
> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>
>
> 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.
It is the PMC that controls all aspects of the project, including whatever
rights
it wishes to confer to committers. Those rights can be distributed one
individual
at a time or as a class. A committer's opinion may be considered ahead of other
people's opionions, but it based on their individual merit, not their accrued
status.
And in the end it may be completely discarded by the PMC if it so chooses.
Look at the Subversion project as an example of a community with a large
committer
base and a full set of rules for how committers are given the right to work on
various
aspects of their svn tree. (A "full committer" in Subversion maps to a PMC
member
at Apache.) The rules are entirely social in nature, not enforced with authz
rules.
Getting back to the subject, my primary objection to what's being proposed is
that
commons should handle this as an ip clearance, not as a project incubation. If
commons insists that the individuals in question have to submit patches to their
own work product for a while, that is a suboptimal choice but I can respect it.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
