commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [all] Committer criteria
Date Mon, 01 May 2006 20:00:32 GMT
On 5/1/06, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> On Mon, 2006-05-01 at 10:46 -0700, Henri Yandell wrote:
> > I've been pondering if our critieria for granting committership is out of date.
>
> i'm not sure that we really have any objective criteria: just a
> subjective tradition :)
>
> personally speaking, i will not nominate a new committer unless i am
> convinced that i have the time to provide oversight and help for as long
> as i think i can be of assistance.

Right, I think this is a pretty good limiting item of criteria.
Nomination implies official mentorship - much like the Google Summer
of Code. With a defined period.

ie) We might nominate Chris to work on compress for 2 months with
Mario mentoring - we would ask Mario for a report at the end of the 2
months.

> this is also a considerable
> investment of my energy so i need to be convinced that it will be worth
> it. this means i need to be able to form a judgement from a number of
> contributions. i prefer to wait until those contributions demonstrate an
> understand of the way that apache and jakarta works.

Personally I don't think anyone really knows how it works and we're
all just slowly picking things up on the moving target that is
macro-community consensus.

Jumping right in is the best way to pick up the understanding,
otherwise the 'way it works' becomes an understanding that someone has
to send in a few patches etc - not necessarily of value once they are
a committer. You could say that the

>
> i am very liberal in supporting karma for committers already at apache.

+1. Far as I'm concerned, I'll +1 anyone at Apache who wants commit
rights. I've been pondering an email on sandbox->proper promotions
suggesting it be more obvious that if you want to become a released
component, having 3 interested ASF committers is all it should take.

If Cocoon had a component they wanted to release here, and they had 3
committers interested in it, the fact none are members of Jakarta
would make no difference (I think...after a bit of community navel
gazing).


> > So, for people like Chris who are actively trying to get involved, are
> > we setting a bar that just causes us pain? I don't think there are any
> > social or legal issues that say we have to wait on people to submit a
> > bunch of patches, and who cares if we end up with yet more inactive
> > committers, each active committer will be worth 9 inactive ones.
>
> a few observations
>
> 1 infrastructure would definitely care: ATM every committer requires
> shell and a quantity of setup. both stress our limited volunteer
> infrastructure. hopefully this issue should go away sometime soon.

Agreed. I doubt we'd be increasing it dramatically though, we're but
one tiny (sub)project among many and we're not that active on adding
new committers currently.

> 2 it is very possible some members may have philosophical objections to
> committership being given away too freely. some other notable projects
> set high bars for committers.

I asked around on #asf about that prior to posting. Two reasons that
jumped up were legal and technical (see next question for legal).
Commons code is easy in many cases - and the components are nicely
decoupled, so I think the technical is not as big a deal here as it is
in some projects.

> 3 would this increase worries about oversight? allowing committers
> without a track record would need a lot more active supervision. it may
> just displace the issue. if there aren't enough people willing to patch
> the codebase, then are there going to be enough to supervise the
> codebase?

This is the bit I'd always assumed drove the need to limit the rate of
adoption. This is where the PMC and Cliff/SVN came in. The main time
that oversight is needed is on a release - which gets voted on by the
PMC. Monitoring every commit seemed less essential than it used to be.


Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message