Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Phil Steitz <ph...@gmail.com>
> To: general@incubator.apache.org
> Sent: Thu, December 31, 2009 1:54:18 AM
> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
> 
> Joe Schaefer wrote:
> > ----- Original Message ----
> > 
> >> From: Phil Steitz 
> >> To: general@incubator.apache.org
> >> Sent: Wed, December 30, 2009 3:10:47 PM
> >> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
> >>
> >> Joe Schaefer wrote:
> >>> ----- Original Message ----
> >>>
> >>>> From: Phil Steitz 
> >>>> To: general@incubator.apache.org
> >>>> Sent: Wed, December 30, 2009 1:30:13 PM
> >>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
> >>>>
> >>>> Joe Schaefer wrote:
> >>>>> ----- Original Message ----
> >>>>>
> >>>>>> From: ant elder 
> >>>>>> To: general@incubator.apache.org
> >>>>>> Sent: Fri, December 11, 2009 5:22:13 AM
> >>>>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
> >>>>>>
> >>>>>> On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton
> >>>>>> wrote:
> >>>>>>> On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote:
> >>>>>>>> A quick search so there has been some discussion on commons-dev - [1]
> >>>>>>>>
> >>>>>>>> Does this really need to be incubated - the proposal says its intended
> >>>>>>>> to graduate to Apache Commons and replace the existing Validator 1.x
> >>>>>>>> component as a new 2.0 codebase, from the discussion on commons-dev
> >>>>>>>> everyone seems fine with that out come, and only 2 of the 7 proposed
> >>>>>>>> committers are not existing Validator or ASF committers - so couldn't
> >>>>>>>> this just go straight to commons as a code grant and make the two new
> >>>>>>>> guys committers in recognition of contibuting the new code?
> >>>>>>> I raised this on private@commons and reported back to dev@commons on
> >>>>>>> that discussion here:
> >>>>>>>
> >>>>>>> http://markmail.org/message/lkyjl6gaxawspgdt
> >>>>>>>
> >>>>>>> In summary though, there was very little support to go that route and
> >>>>>>> some objections.
> >>>>>>>
> >>>>>>> All commons components share the same set of mailing lists which makes
> >>>>>>> it easier for PMC members to provide oversight for the 30+ components
> >>>>>>> that live there. As part of this proposal we want to use the commons
> >>>>>>> mailing lists for commits and discussion so that by the time this
> >>>>>>> podling is ready to graduate the new committers and Commons PMC will
> >>>>>>> have a better knowledge of each other and there will be no issue with
> >>>>>>> voting in the new committers.
> >>>>>>>
> >>>>>>> The use of the commons mailing lists is in the proposal and was part
> >>>>>>> of the vote held on dev@commons to sponsor this incubation effort:
> >>>>>>>
> >>>>>>> http://markmail.org/message/mqdft736b5vasezs
> >>>>>>>
> >>>>>>> Niall
> >>>>>>>
> >>>>>> From the first email referenced was Roman ever asked if he'd mind
> >>>>>> submitting patches for a while to earn Karma if the code did go
> >>>>>> straight to commons? Seems a bit a of a shame to need to go the whole
> >>>>>> incubation process just for one commit access.
> >>>>>>
> >>>>>> Re the the poddling use the existing commons mailing lists its may be
> >>>>>> worth pointing out this recent thread:
> >>>>>> http://apache.markmail.org/message/ifinvq7wqmeoo5ix
> >>>>> Commons is badly busted if it can't allow a new person access to his/her
> >>>>> own code in a fucking sandbox.  Incubating this project because some 
> weenies 
> >>>> are
> >>>>> uncomfortable about the nature of the meritocracy over in commons isn't 
> the 
> >>>> solution:
> >>>>> have commons hold a public vote and make an actual decision.  If they vote 
> 
> >> to
> >>>>> incubate the damned thing, it's an incredibly stupid decision, but so be 
> it.
> >>>>>
> >>>> Hey Joe, the language could be toned down a bit, but I see your
> >>>> point.  On the other hand, here is the problem as I see it.
> >>>>
> >>>> In Commons, like other non-Incubator projects, we welcome new
> >>>> contributors and encourage them to get involved in the community and
> >>>> stick around long enough to earn ASF commit.  When people show up
> >>>> with significant patches, we ask them to file CLAs before we commit
> >>>> their code and if the contribution is "big" (not precisely defined,
> >>>> but we have been able to agree in all cases), we ask for a software
> >>>> grant and go through Incubator IP clearance.  We have several
> >>>> examples of people showing up with large amounts of code, engaging
> >>>> in the community and contributing patches to their own and other
> >>>> code and earning commit that way.  This has worked for us in the
> >>>> past and is consistent with how things are supposed to work - at
> >>>> least as I understand it - at the ASF, outside of the Incubator.  If
> >>>> we have changed our (ASF) view on what it means to become a
> >>>> committer, then maybe we are behind the times in Commons.  That
> >>>> would be somewhat ironic, since in the Jakarta days we were
> >>>> regularly accused of having too low a bar for commit.
> >>>>
> >>>> What we would have no problem at all with is following the process
> >>>> described above - just do IP clearance / code grant for the code and
> >>>> let the non-ASF committers earn commit.  This does not take forever
> >>>> and is not as terrible as some seem to think it is.  I can't recall
> >>>> a single "failure" (someone getting discouraged and giving up) and
> >>>> several successes over the past 6 years.
> >>>>
> >>>> I understand that in the Incubator people get commit immediately and
> >>>> that makes it easier for both them and the mentors.  As I understand
> >>>> it, part of the reason we have the Incubator is so that people who
> >>>> have no experience with the ASF and have not earned merit can both
> >>>> gain experience and demonstrate merit in a "mentored" environment.
> >>>> The mentoring and graduation requirements ensure that when projects
> >>>> graduate, their committers have earned full ASF commit.
> >>> I seriously doubt mentors take their role that seriously, otherwise
> >>> we wouldn't have so many long-term residents of the Incubator.
> >>>
> >>>> It could be that I have this wrong and just arriving with a lump of
> >>>> code that a project wants to incorporate is enough to earn ASF
> >>>> commit outside the Incubator nowadays.  If we collectively agreed to
> >>>> that and I missed the conversation, then I apologize for the late
> >>>> protest.  I honestly can't believe that we did agree to that; however.
> >>>>
> >>>> Note that this has nothing to do with expectations about who will
> >>>> succeed, who will not - it is about meritocracy being based on
> >>>> publicly earned merit. Good code is good and if unencumbered we can
> >>>> commit it to our projects.  Good people interested in open
> >>>> development make good committers and these we can include in our ASF
> >>>> committer community. It is our collective responsibility to give as
> >>>> many people as possible the opportunity to succeed in becoming
> >>>> committers; but they have to do more than just produce good code to
> >>>> earn commit.
> >>>>
> >>>> If we want to extend the Incubator function to work within projects,
> >>>> I am OK with that. That could be the right way to deal with
> >>>> situations such as this - though in this particular case, I still
> >>>> think just software grant/earn commit is best - and it could take
> >>>> some load off of the Incubator PMC. The role of the "sponsoring PMC"
> >>>> would then become in loco Incubator. I am open to this, but need to
> >>>> understand better how exactly it would work.
> >>>>
> >>>> Phil
> >>> I'm not looking to extend the Incubator even in the smallest way.  To me
> >>> the Incubator is a necessary evil, and not entirely a positive thing for
> >>> the ASF.  That it seems to be functional on some level is good enough for
> >>> the time being- at least we're back to graduating projects again.
> >>>
> >>> Where I disagree with your outlook is in the relative meaning of granting
> >>> someone commit.  To me it's just giving someone the full set of tools and
> >>> the right (conditional on peer review) to make changes to a codebase.  Each
> >>> community can and should make their own determination on what additional
> >>> meaning they wish to impart to committership, but communities need to be
> >>> flexible, not rigid, in how they make those determinations.
> >> So should commit require merit or not?  I understand the need for
> >> flexibility, but if we are going to have a meaningful "committer"
> >> role, we need to be consistent (at least within projects) what it
> >> means.  At commons, we are not rigid, but we do require sustained
> >> contributions (vaguely defined, but at least a few months) before we
> >> vote someone in as a committer.  This is because being voted in
> >> means something in terms of merit.  We could change that and divorce
> >> commit from merit - postponing the merit requirement until the PMC
> >> membership vote.  Is this what you mean?
> > 
> > I don't see any need for several months to pass before being able to figure
> > out if someone is participating to further the group's goals and understands
> > the group's unique style of work.  That is the distinguishing characteristic
> > of whether someone should be given full access to subversion IMO, not some
> > nebulous notion of accrued merit.
> 
> 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.

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


      

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

Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

[Ralph Goers <ra...@dslextreme.com>]

On Dec 31, 2009, at 7:20 PM, Joe Schaefer wrote:

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

I disagree that it should just be about ip clearance. If the Commons PMC has a history with the committers that come with the code then they surely can judge whether those people would be good members of the community. If they don't have any track record to go on then it is unreasonable to expect them to immediately accept them. The Commons PMC doesn't even do that for Members, except to grant them commit rights to the sandbox. However, IMO it would not be unreasonable to allow the code into the sandbox and give them only commit rights to their component. However, I'm not on the Commons PMC so my opinion is just that.

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

Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Ralph Goers <ra...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

[Ralph Goers <ra...@dslextreme.com>]

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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org