You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Henri Yandell <ba...@apache.org> on 2006/08/08 22:53:29 UTC
Opening up the PMC
Being on a PMC means two actionable things. Firstly, you get a binding
vote; and secondly, you can subscribe to private@jakarta - a list which
should be pretty quiet (mostly it's just vote results now - would be nice
to move those to this list).
The purpose of the binding vote is that that allows you to perform
oversight on behalf of the foundation - it's not me making a release, it's
the foundation.
That's all there is. It's nothing special, just that we can yay or nay
something. There's not even any paperwork beyond the board ack email.
Given that - why do we have committers and pmc members? Why do we have
people in our community who have been accepted as committers and are
happily churning code, but are not allowed a binding vote? It's definitely
not because we have an enormously low bar of entry to being a committer.
My view is that we shouldn't keep wasting our time on such a separation.
There is no danger at all (given our size) to having a new committer
immediately join the PMC, and there are notable benefits in that we don't
have to keep remembering to add people to the pmc (which we really suck at
doing) and we'll have a more open environment (which we all like right?).
Also we won't have second class citizens who have to yet again sit and
wait while their elders remember to nominate them as an elder.
What do people think to the following:
1) Every existing committer not on the pmc receives an email asking if
they would like to join the pmc. Once that email is sent they are marked
in a file as having had the email sent and we can wash our hands until a
reply comes in.
2) Every new committer automatically gets added to the pmc.
---
I bring it up because the concept has cropped up elsewhere at the ASF and
given our large non-pmc to pmc ratio I think we'll have a lot of strong
views on the subject.
Hen
(Yeah, I recognize that the above is flamebait if we have any strong
opinions out there. Hopefully it'll stay constructive :) )
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by James Mitchell <jm...@apache.org>.
+1 -- Yea, I know, it's not a vote, but it's binding anyway ;)
I like this idea. IMHO, private@ probably should only be used to
discuss things that truly should not be public. As I just mentioned
on an entirely different list with a somewhat related topic, one
thing we might do, in cases where there might be some embarrassing
remarks would be to send a "I'm about to nominate Henri Yandell as a
committer in 3 days, speak now or shut up later"....ymmv ;)
--
James Mitchell
678.910.8017
On Aug 8, 2006, at 4:53 PM, Henri Yandell wrote:
>
> Being on a PMC means two actionable things. Firstly, you get a
> binding vote; and secondly, you can subscribe to private@jakarta -
> a list which should be pretty quiet (mostly it's just vote results
> now - would be nice to move those to this list).
>
> The purpose of the binding vote is that that allows you to perform
> oversight on behalf of the foundation - it's not me making a
> release, it's the foundation.
>
> That's all there is. It's nothing special, just that we can yay or
> nay something. There's not even any paperwork beyond the board ack
> email. Given that - why do we have committers and pmc members? Why
> do we have people in our community who have been accepted as
> committers and are happily churning code, but are not allowed a
> binding vote? It's definitely not because we have an enormously low
> bar of entry to being a committer.
>
> My view is that we shouldn't keep wasting our time on such a
> separation. There is no danger at all (given our size) to having a
> new committer immediately join the PMC, and there are notable
> benefits in that we don't have to keep remembering to add people to
> the pmc (which we really suck at doing) and we'll have a more open
> environment (which we all like right?). Also we won't have second
> class citizens who have to yet again sit and wait while their
> elders remember to nominate them as an elder.
>
> What do people think to the following:
>
> 1) Every existing committer not on the pmc receives an email asking
> if they would like to join the pmc. Once that email is sent they
> are marked in a file as having had the email sent and we can wash
> our hands until a reply comes in.
>
> 2) Every new committer automatically gets added to the pmc.
>
> ---
>
> I bring it up because the concept has cropped up elsewhere at the
> ASF and given our large non-pmc to pmc ratio I think we'll have a
> lot of strong views on the subject.
>
> Hen
>
> (Yeah, I recognize that the above is flamebait if we have any
> strong opinions out there. Hopefully it'll stay constructive :) )
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Sandy McArthur <sa...@apache.org>.
On 8/8/06, Henri Yandell <ba...@apache.org> wrote:
> 2) Every new committer automatically gets added to the pmc.
-0 I think the committer role as an initiation period of sorts is good thing.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Roland Weber <ht...@dubioso.net>.
Hi Henri,
> By being a part of the PMC (and active on the PMC if you're an active
> committer), then you are ensuring that the foundation is involved in
> decisions and not just you personally.
Thanks, that sounds much better indeed.
> Sorry to cause worry. It's the other way around from how you've
> interpreted it and my reason for the above opinion is that I'd be
> worried about someone who wanted to sit and code but wanted to continue
> to delegate responsibility to the pmc/foundation for their code.
No problem. Glad we talked about it :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: PMC nominations was Re: Opening up the PMC
Posted by Henri Yandell <ba...@apache.org>.
On Wed, 9 Aug 2006, Oleg Kalnichevski wrote:
> Henri,
> What is the procedure for PMC nominations these days? I would like to
> propose Roland for PMC nomination. He's been an indispensable member of
> the HttpComponents project for many years. What list am I supposed to
> send the proposal to? jakarta-private? jakarta-general?
It's been jakarta-private up til now; but it's becoming more common at the
ASF for the pmc votes to be on the public list (general@ for us), and to
mention on private@ a little bit before that you plan to do the vote.
So I guess do it on private, and hopefully we can change that soon(?).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
PMC nominations was Re: Opening up the PMC
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2006-08-09 at 15:05 -0400, Henri Yandell wrote:
>
> On Wed, 9 Aug 2006, Roland Weber wrote:
>
> > Hello Henri,
> >
> > I'm one of those whom it concerns: committer but not PMC.
> >
> >> So being on a PMC means that your legal protection is something you're
> >> supposed to be proactive about
> >
> > Meaning that a PMC member should get an insurance that covers the cost
> > of lawsuits, or contact a lawyer right away to discuss the legal
> > implications of a lawsuit that might be filed in a different country,
> > or what?
>
> Sorry, that's very badly worded on my part. I didn't mean it to be as
> scary as it sounds or to imply that being on a PMC requires more legal
> consultation than just being a developer of open source anywhere.
>
Henri,
What is the procedure for PMC nominations these days? I would like to
propose Roland for PMC nomination. He's been an indispensable member of
the HttpComponents project for many years. What list am I supposed to
send the proposal to? jakarta-private? jakarta-general?
Oleg
> By being a part of the PMC (and active on the PMC if you're an active
> committer), then you are ensuring that the foundation is involved in
> decisions and not just you personally. This increases the level to which
> the foundation has your back should a legal issue come up (not that any
> of this is defined, so I'm just passing on things as they've been
> explained to me over the last couple of years - hopefully accurately :)).
>
> >> I'm of the opinion that if we have a committer who doesn't want to be on
> >> the pmc, [...], that that committer should become a contributor again.
> >
> > Meaning that because I don't want to get an insurance or contact a
> > lawyer proactively, all the code I submit has to be checked in by
> > another committer, of whom we have too few anyway in HttpComponents?
> >
> > I hope I got you all wrong, because the way I understand it,
> > your proposal sounds really bad.
>
> Sorry to cause worry. It's the other way around from how you've
> interpreted it and my reason for the above opinion is that I'd be worried
> about someone who wanted to sit and code but wanted to continue to
> delegate responsibility to the pmc/foundation for their code.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Henri Yandell <ba...@apache.org>.
On Wed, 9 Aug 2006, Roland Weber wrote:
> Hello Henri,
>
> I'm one of those whom it concerns: committer but not PMC.
>
>> So being on a PMC means that your legal protection is something you're
>> supposed to be proactive about
>
> Meaning that a PMC member should get an insurance that covers the cost
> of lawsuits, or contact a lawyer right away to discuss the legal
> implications of a lawsuit that might be filed in a different country,
> or what?
Sorry, that's very badly worded on my part. I didn't mean it to be as
scary as it sounds or to imply that being on a PMC requires more legal
consultation than just being a developer of open source anywhere.
By being a part of the PMC (and active on the PMC if you're an active
committer), then you are ensuring that the foundation is involved in
decisions and not just you personally. This increases the level to which
the foundation has your back should a legal issue come up (not that any
of this is defined, so I'm just passing on things as they've been
explained to me over the last couple of years - hopefully accurately :)).
>> I'm of the opinion that if we have a committer who doesn't want to be on
>> the pmc, [...], that that committer should become a contributor again.
>
> Meaning that because I don't want to get an insurance or contact a
> lawyer proactively, all the code I submit has to be checked in by
> another committer, of whom we have too few anyway in HttpComponents?
>
> I hope I got you all wrong, because the way I understand it,
> your proposal sounds really bad.
Sorry to cause worry. It's the other way around from how you've
interpreted it and my reason for the above opinion is that I'd be worried
about someone who wanted to sit and code but wanted to continue to
delegate responsibility to the pmc/foundation for their code.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Roland Weber <ht...@dubioso.net>.
Hello Henri,
I'm one of those whom it concerns: committer but not PMC.
> So being on a PMC means that your legal protection is something you're
> supposed to be proactive about
Meaning that a PMC member should get an insurance that covers the cost
of lawsuits, or contact a lawyer right away to discuss the legal
implications of a lawsuit that might be filed in a different country,
or what?
> I'm of the opinion that if we have a committer who doesn't want to be on
> the pmc, [...], that that committer should become a contributor again.
Meaning that because I don't want to get an insurance or contact a
lawyer proactively, all the code I submit has to be checked in by
another committer, of whom we have too few anyway in HttpComponents?
I hope I got you all wrong, because the way I understand it,
your proposal sounds really bad.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Henri Yandell <ba...@apache.org>.
On Wed, 9 Aug 2006, Henning Schmiedehausen wrote:
> Hi,
>
> well, I always thought that the PMC also has a legal role for the code
> that it governs? So there might be committers that don't want to be on
> the PMC for that reason.
Yeah, it does. The binding vote of the pmc, which provides oversight for
the foundation (or 3 of which do), is expected to be used on legally
sensitive issues such as releases, dependencies etc. So it's the pmc's
responsibility to be making sure their binding votes are being used on
legal issues.
In return - the foundation supports these decisions by an order more than
it would support committer decisions. Not that we've had such legal cases,
so that might only be a theoretical distinction. As far as liability goes,
I think only the relevant officer and the directors are legally on the
line from the point of view of the foundation. A case would be brought
against Henning Schmiedehausen and the ASF and apparantly it's common that
the larger organization would plead the individual off the case.
So being on a PMC means that your legal protection is something you're
supposed to be proactive about and not hoping as a committer that the PMC
have got your back; but it all comes down the binding pmc vote and making
sure it's used at the right time.
I'm of the opinion that if we have a committer who doesn't want to be on
the pmc, whether or not we have them joining at the same time or after an
N month period, that that committer should become a contributor again.
There shouldn't be a negative to being added to a pmc.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
Hi,
well, I always thought that the PMC also has a legal role for the code
that it governs? So there might be committers that don't want to be on
the PMC for that reason.
I'm cautious +0 for this.
Best regards
Henning
On Tue, 2006-08-08 at 16:53 -0400, Henri Yandell wrote:
> Being on a PMC means two actionable things. Firstly, you get a binding
> vote; and secondly, you can subscribe to private@jakarta - a list which
> should be pretty quiet (mostly it's just vote results now - would be nice
> to move those to this list).
>
> The purpose of the binding vote is that that allows you to perform
> oversight on behalf of the foundation - it's not me making a release, it's
> the foundation.
>
> That's all there is. It's nothing special, just that we can yay or nay
> something. There's not even any paperwork beyond the board ack email.
> Given that - why do we have committers and pmc members? Why do we have
> people in our community who have been accepted as committers and are
> happily churning code, but are not allowed a binding vote? It's definitely
> not because we have an enormously low bar of entry to being a committer.
>
> My view is that we shouldn't keep wasting our time on such a separation.
> There is no danger at all (given our size) to having a new committer
> immediately join the PMC, and there are notable benefits in that we don't
> have to keep remembering to add people to the pmc (which we really suck at
> doing) and we'll have a more open environment (which we all like right?).
> Also we won't have second class citizens who have to yet again sit and
> wait while their elders remember to nominate them as an elder.
>
> What do people think to the following:
>
> 1) Every existing committer not on the pmc receives an email asking if
> they would like to join the pmc. Once that email is sent they are marked
> in a file as having had the email sent and we can wash our hands until a
> reply comes in.
>
> 2) Every new committer automatically gets added to the pmc.
>
> ---
>
> I bring it up because the concept has cropped up elsewhere at the ASF and
> given our large non-pmc to pmc ratio I think we'll have a lot of strong
> views on the subject.
>
> Hen
>
> (Yeah, I recognize that the above is flamebait if we have any strong
> opinions out there. Hopefully it'll stay constructive :) )
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Phil Steitz <ph...@steitz.com>.
Yoav Shapira wrote:
> Hi,
>
>> My view is that we shouldn't keep wasting our time on such a separation.
>
> I think the separation is valid. Jim put it nicely earlier today
> (paraphrased here): committership is the right to vote a code base,
> PMC membership is the right to oversee a project. In my mind there
> definitely is a separation, and the latter requires more trust.
+1 I see "PMC==committers" as an aspiration, not something that can
defined away.
> This
> is especially true for projects whose committership is granted (at
> first maybe) on a partial basis, e.g. only to some directory trees
> within the project's SVN repository. So if I were to go just with
> that, I'd say -0 (if only because I don't have the energy and
> bandwidth to contribute alternative suggestions, so I don't want to -1
> the issue).
>
> You mentioned that we're bad at remembering to add people to the PMC:
> agreed, but I don't think the solution to that is a policy-level one.
I agree here as well. We should be aiming to a) get as many committers
as possible both wanting and deserving the additional trust that PMC
membership represents and b) nominating them once they have earned that
trust and indicated that they are willing to participate in the
oversight of the project.
I agree that we can all improve the speed with which we nominate people,
but I bet if you did the super svn-analysis, you would find that people
with sustained contributions do tend to get nominated over time. I
think the large number of non-PMC committers is at least in part
attributable to "vanishing committers" or committers whose activity is
at best sporadic.
With my PMC member hat on, I would be hard pressed to +1 a mass addition
of PMC members based on historical commit votes from all across Jakarta,
with no support provided for any of the nominees.
> Instead, I would opt for a simple command-line tool, to be run at the
> PMC's discretion (or indeed, probably at any committers' discretion),
> that looks at svn-authorization and spits out who's a committer for
> project X but not on the PMC for that project. With the crew here,
> we'll probably have this tool done in your choice of the top 20
> programming languages in under an hour. Heck we can even make it a
> cron / gump / nag the PMC chair every month type of thing.
>
> The above said, I think Jakarta is a different beast. Because it's an
> umbrella project, it has many disparate groups of people doing their
> own thing. In a nicer world, those smaller groups would be
> responsible for their oversight, so we'd have multiple smaller PMCs
> instead of one big Jakarta one. And I think that's where we're
> heading gradually, as we graduate projects, make them dormant, move
> them elsewhere, etc.
>
> But because of the current structure of Jakarta and its current
> membership, I'd probably say +0. It's not optimal, but it might be
> the best solution for a large and largely mature umbrella-type
> project.
>
Here I disagree. When you think about it, making committers==PMC
analytic really amounts to dissolving the PMC. It could be that
dissolving Jakarta is a good idea sometime soon, but as long as it
exists as an apache project, it needs a PMC which is more than just a
collection of committers with binding votes on code. This is why PMCs
exist at apache and why you can't *define* the PMC to be the set of
committers.
As an alternative to Hen's "invite everyone" proposal, I would be fine
with allowing and encouraging self-nominations. That would bring out
committers who really want to be part of the PMC, but still allow us to
vote them in.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Henri Yandell <ba...@apache.org>.
On Tue, 8 Aug 2006, Yoav Shapira wrote:
> I think the separation is valid. Jim put it nicely earlier today
> (paraphrased here): committership is the right to vote a code base,
> PMC membership is the right to oversee a project. In my mind there
> definitely is a separation, and the latter requires more trust. This
Committers don't get the right to vote a code base though. They might
under some interpretations etc etc, but currently most of the ASF is going
with PMC=binding vote, committer=non-binding. What is involved with the
right to oversee a project beyond voting?
> is especially true for projects whose committership is granted (at
> first maybe) on a partial basis, e.g. only to some directory trees
> within the project's SVN repository. So if I were to go just with
> that, I'd say -0 (if only because I don't have the energy and
> bandwidth to contribute alternative suggestions, so I don't want to -1
> the issue).
*whistle while staring at feet*
POI's the only part of Jakarta with partial committership now.
> You mentioned that we're bad at remembering to add people to the PMC:
> agreed, but I don't think the solution to that is a policy-level one.
It's not the only reason though - and my solution equals zero work
compared to the still required work of a script to spit out etc (Geir's
done that already, though it might have been CVS days).
> The above said, I think Jakarta is a different beast. Because it's an
> umbrella project, it has many disparate groups of people doing their
> own thing. In a nicer world, those smaller groups would be
> responsible for their oversight, so we'd have multiple smaller PMCs
> instead of one big Jakarta one. And I think that's where we're
> heading gradually, as we graduate projects, make them dormant, move
> them elsewhere, etc.
Was a different beast. Disjoint umbrellas are an endangered species now -
umbrellas are good, but they need to be one community. A disjoint umbrella
means that Martin ends up being the main communication line between
subprojects; which'll burn him out.
That said - we are always going to have a lot of people not on the PMC. We
have 400+ committers, and they're mostly inactive and I'd be surprised if
even a small number wanted to be on the PMC. That's just a legacy bit that
once we've invited them we can ignore.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
> My view is that we shouldn't keep wasting our time on such a separation.
I think the separation is valid. Jim put it nicely earlier today
(paraphrased here): committership is the right to vote a code base,
PMC membership is the right to oversee a project. In my mind there
definitely is a separation, and the latter requires more trust. This
is especially true for projects whose committership is granted (at
first maybe) on a partial basis, e.g. only to some directory trees
within the project's SVN repository. So if I were to go just with
that, I'd say -0 (if only because I don't have the energy and
bandwidth to contribute alternative suggestions, so I don't want to -1
the issue).
You mentioned that we're bad at remembering to add people to the PMC:
agreed, but I don't think the solution to that is a policy-level one.
Instead, I would opt for a simple command-line tool, to be run at the
PMC's discretion (or indeed, probably at any committers' discretion),
that looks at svn-authorization and spits out who's a committer for
project X but not on the PMC for that project. With the crew here,
we'll probably have this tool done in your choice of the top 20
programming languages in under an hour. Heck we can even make it a
cron / gump / nag the PMC chair every month type of thing.
The above said, I think Jakarta is a different beast. Because it's an
umbrella project, it has many disparate groups of people doing their
own thing. In a nicer world, those smaller groups would be
responsible for their oversight, so we'd have multiple smaller PMCs
instead of one big Jakarta one. And I think that's where we're
heading gradually, as we graduate projects, make them dormant, move
them elsewhere, etc.
But because of the current structure of Jakarta and its current
membership, I'd probably say +0. It's not optimal, but it might be
the best solution for a large and largely mature umbrella-type
project.
The mechanics you suggested with the notification emails etc are fine
by me, no issue there if this initiative does get approved.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Henri Yandell wrote:
> What do people think to the following:
>
> 1) Every existing committer not on the pmc receives an email asking if
> they would like to join the pmc. Once that email is sent they are marked
> in a file as having had the email sent and we can wash our hands until a
> reply comes in.
>
> 2) Every new committer automatically gets added to the pmc.
-1
Becoming a committer is an essential first step. It allows everyone,
committer included, to figure out if the committer is really able to
spend the time and energy on the project they thought they would.
What is needed is an easier way of judging who should be PMC and isn't.
Something like a monthly script of non-pmc committers and their number
of commits and mail messages.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Re: Re: Opening up the PMC
Posted by Henri Yandell <ba...@generationjava.com>.
On Sat, 19 Aug 2006, Torsten Curdt wrote:
>> > Why that combination? ...feels quite unnatural to me - I am sure so it
>> will
>> > for the users.
>>
>> It's our list of small largely inactive subprojects. We know that none of
>> those are going to go TLP, and their dev lists are quiet by an order of
>> magnitude compared to an inactive TLP potential project like Slide.
>
> True ...but that grouping is not obvious to the users. Besides conditions
> *could* change.
The grouping is 'Jakarta' :)
I'm not sure the obviousness to users is important, this is the dev@
mailing list and not a user@ one.
>> > Combining mailinglist would definitely get a -1 from me. I don't want the
>> > few BCEL subscribers left to unsubscribe because they get annoyed
>> > because they are receiving mails they are not interested in.
>> >
>> > We might get away with that at commons - but in general I think it's
>> > quite a bad idea.
>>
>> We've a bunch of relatively small codebases and subprojects that on their
>> own are a stretch to maintain oversight over. It's a match for the Commons
>> approach of having those communities share the same space and help each
>> other on general issue topics, such as releases.
>
> Well, oversight does not really apply to the users. Besides developers
> could subscribe to all sub projects list. We could even ask comitters or
> at least PMC members to subscribe to all of them to achieve the same
> kind of oversight. ...it would just be more convenient for the users.
We could - but I don't see any reason why we should have so much make-work
to do as opposed to being on the same dev list.
> IMO rather have it too fine grained and combine than too general and you
> are stuck with what you don't want.
Too fine grained and combine hasn't been working well up to now. Do you
think the commons-dev merged approach is damaging?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Re: Re: Opening up the PMC
Posted by Torsten Curdt <tc...@apache.org>.
> > Why that combination? ...feels quite unnatural to me - I am sure so it will
> > for the users.
>
> It's our list of small largely inactive subprojects. We know that none of
> those are going to go TLP, and their dev lists are quiet by an order of
> magnitude compared to an inactive TLP potential project like Slide.
True ...but that grouping is not obvious to the users. Besides conditions
*could* change.
> > Combining mailinglist would definitely get a -1 from me. I don't want the
> > few BCEL subscribers left to unsubscribe because they get annoyed
> > because they are receiving mails they are not interested in.
> >
> > We might get away with that at commons - but in general I think it's
> > quite a bad idea.
>
> We've a bunch of relatively small codebases and subprojects that on their
> own are a stretch to maintain oversight over. It's a match for the Commons
> approach of having those communities share the same space and help each
> other on general issue topics, such as releases.
Well, oversight does not really apply to the users. Besides developers
could subscribe to all sub projects list. We could even ask comitters or
at least PMC members to subscribe to all of them to achieve the same
kind of oversight. ...it would just be more convenient for the users.
IMO rather have it too fine grained and combine than too general and you
are stuck with what you don't want.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Re: Opening up the PMC
Posted by Henri Yandell <ba...@apache.org>.
On Thu, 17 Aug 2006, Torsten Curdt wrote:
>> The problem with moving Commons up is that when you look at where Jakarta
>> needs to go, and when you look at where Commons generally is now; they are
>> the same places - and it's hard to distinguish between the focuses.
>
> Hm... interesting... funnily I have never seen it like that before.
> Always had the
> impression jakarta is for "products" while commons is for libraries.
> Sometimes
> it's just not that clear where to draw the line though.
Yup. Compare Jelly to ECS or Regexp.
>> Jakarta needs a way to blend community oversight with small numbers of
>> active committers per component. That's pretty much Commons. For a start,
>> I would merge BCEL, BSF, ECS, JCS, ORO and Regexp dev lists into either
>> commons-dev@jakarta or dev@jakarta.
>
> Why that combination? ...feels quite unnatural to me - I am sure so it will
> for the users.
It's our list of small largely inactive subprojects. We know that none of
those are going to go TLP, and their dev lists are quiet by an order of
magnitude compared to an inactive TLP potential project like Slide.
> Combining mailinglist would definitely get a -1 from me. I don't want the
> few BCEL subscribers left to unsubscribe because they get annoyed
> because they are receiving mails they are not interested in.
>
> We might get away with that at commons - but in general I think it's
> quite a bad idea.
We've a bunch of relatively small codebases and subprojects that on their
own are a stretch to maintain oversight over. It's a match for the Commons
approach of having those communities share the same space and help each
other on general issue topics, such as releases.
The reason I don't suggest moving to commons-dev is that that would
definitely be too much of a shock to those on the current dev lists, and
even with those lists being combined traffic is still going to be low. I
also don't suggest a merger of the user lists anytime soon.
>> 1) BCEL, BSF, ECS, JCS, ORO and Regexp dev lists merging
>> 2) Alexandria dies
>> 3) POI to TLP
>> 4) Consider merging user lists from 1)
>> 5) Flatten HttpComponents, Velocity, Taglibs.
>>
>> Some mad ideas :)
>
> Sorry that I have to agree with the last sentence in some extend ;-)
*grin*
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Re: Opening up the PMC
Posted by Torsten Curdt <tc...@apache.org>.
> The problem with moving Commons up is that when you look at where Jakarta
> needs to go, and when you look at where Commons generally is now; they are
> the same places - and it's hard to distinguish between the focuses.
Hm... interesting... funnily I have never seen it like that before.
Always had the
impression jakarta is for "products" while commons is for libraries. Sometimes
it's just not that clear where to draw the line though.
> Jakarta needs a way to blend community oversight with small numbers of
> active committers per component. That's pretty much Commons. For a start,
> I would merge BCEL, BSF, ECS, JCS, ORO and Regexp dev lists into either
> commons-dev@jakarta or dev@jakarta.
Why that combination? ...feels quite unnatural to me - I am sure so it will
for the users.
Combining mailinglist would definitely get a -1 from me. I don't want the
few BCEL subscribers left to unsubscribe because they get annoyed
because they are receiving mails they are not interested in.
We might get away with that at commons - but in general I think it's
quite a bad idea.
> 1) BCEL, BSF, ECS, JCS, ORO and Regexp dev lists merging
> 2) Alexandria dies
> 3) POI to TLP
> 4) Consider merging user lists from 1)
> 5) Flatten HttpComponents, Velocity, Taglibs.
>
> Some mad ideas :)
Sorry that I have to agree with the last sentence in some extend ;-)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Opening up the PMC
Posted by Nathan Bubna <nb...@gmail.com>.
On 8/14/06, Henri Yandell <ba...@generationjava.com> wrote:
>
>
> On Mon, 14 Aug 2006, Torsten Curdt wrote:
>
> > I am not really sure how to solve this. I am just ranting. For a few
> > projects I think they should go toplevel. For the ones I am involved
> > in at least jakarta commons surely deserves it (not looking into the
> > naming problem for now). Having a few more toplevel projects could
> > help to strip down the "general" jakarta PMC a bit ...and maybe then
> > the committer == PMC idea is more suitable ...maybe let's get a
> > smaller umbrella ;-)
>
> The problem with moving Commons up is that when you look at where Jakarta
> needs to go, and when you look at where Commons generally is now; they are
> the same places - and it's hard to distinguish between the focuses.
>
> Jakarta needs a way to blend community oversight with small numbers of
> active committers per component. That's pretty much Commons. For a start,
> I would merge BCEL, BSF, ECS, JCS, ORO and Regexp dev lists into either
> commons-dev@jakarta or dev@jakarta.
>
> Alexandria dies. POI should go to TLP - if it's not too inactive.
>
> That leaves Cactus, JMeter, Slide, Turbine, Velocity, HttpComponents,
> Taglibs. The latter three should follow Commons into flattening into
> Jakarta. One bit that will be interesting there is parent-poms in m2 - a
> flat Jakarta would not have Commons, HttpComponents, Velocity parent pom
> files. Velocity seems like it can flatten, but I might be lacking enough
> knowledge there.
>
> Unsure on the first 4 in the list above - keep them separate for the
> moment until ideas grow. Slide seems too inactive to go anywhere, we could
> put together a Testing space within Jakarta as a prototype for the
> testing.apache.org if people wanted to explore that, Turbine I've no clue
> on how well it can flatten.
>
> 1) BCEL, BSF, ECS, JCS, ORO and Regexp dev lists merging
> 2) Alexandria dies
> 3) POI to TLP
> 4) Consider merging user lists from 1)
> 5) Flatten HttpComponents, Velocity, Taglibs.
FYI, i (and a few other committers) are actually starting to push
Velocity the other direction: toward TLP. we're still talking about
it, and i'm not sure the community is fully behind it yet. still,
we're feeling like it would be better for the Velocity community to
keep our little umbrella. I still believe the core Velocity library
would fit just dandy in a flat component-ish Jakarta, but not so much
for VelocityTools. Further, there's another Velocity-based
framework-ish project out there that is interested in forging closer
ties and perhaps joining the ASF. we feel it'd be most beneficial to
them and us in that case to be able to bring them in as a Velocity
project, and that they'd be unlikely to be accepted in Jakarta these
days. anyway, just an FYI, we're not quite ready to take action on
this yet.
> Some mad ideas :)
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Opening up the PMC
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 14 Aug 2006, Torsten Curdt wrote:
> I am not really sure how to solve this. I am just ranting. For a few
> projects I think they should go toplevel. For the ones I am involved
> in at least jakarta commons surely deserves it (not looking into the
> naming problem for now). Having a few more toplevel projects could
> help to strip down the "general" jakarta PMC a bit ...and maybe then
> the committer == PMC idea is more suitable ...maybe let's get a
> smaller umbrella ;-)
The problem with moving Commons up is that when you look at where Jakarta
needs to go, and when you look at where Commons generally is now; they are
the same places - and it's hard to distinguish between the focuses.
Jakarta needs a way to blend community oversight with small numbers of
active committers per component. That's pretty much Commons. For a start,
I would merge BCEL, BSF, ECS, JCS, ORO and Regexp dev lists into either
commons-dev@jakarta or dev@jakarta.
Alexandria dies. POI should go to TLP - if it's not too inactive.
That leaves Cactus, JMeter, Slide, Turbine, Velocity, HttpComponents,
Taglibs. The latter three should follow Commons into flattening into
Jakarta. One bit that will be interesting there is parent-poms in m2 - a
flat Jakarta would not have Commons, HttpComponents, Velocity parent pom
files. Velocity seems like it can flatten, but I might be lacking enough
knowledge there.
Unsure on the first 4 in the list above - keep them separate for the
moment until ideas grow. Slide seems too inactive to go anywhere, we could
put together a Testing space within Jakarta as a prototype for the
testing.apache.org if people wanted to explore that, Turbine I've no clue
on how well it can flatten.
1) BCEL, BSF, ECS, JCS, ORO and Regexp dev lists merging
2) Alexandria dies
3) POI to TLP
4) Consider merging user lists from 1)
5) Flatten HttpComponents, Velocity, Taglibs.
Some mad ideas :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Opening up the PMC
Posted by Torsten Curdt <tc...@apache.org>.
> > But if you argue into that direction -no matter how often this has
> > been discussed already- I would rather question the idea of an
> > umbrella PMC then... (*ducks*)
>
> Time and energy to express the ideas you have in that direction ?
Let's try :-)
IMO it's quite awkward to have oversight over a project where I don't
even know people nor the codebase. Of course most of people on the PMC
are active in a couple of the different jakarta projects ...but still
not in every project.
Of course issues can be brought up and discussed once they are
explained to the people that haven't been aware of it. But still it's
quite strange that these people have a full counting PMC vote on the
affairs of that very project. It's just makes things a bit harder.
(Maybe that's why the PMC memeber selection process is currently
needed)
On the other hand I do understand that this can be a problem. Hell, we
hardly have enough *committers* on BCEL ...how should this project's
PMC be functional?
I am not really sure how to solve this. I am just ranting. For a few
projects I think they should go toplevel. For the ones I am involved
in at least jakarta commons surely deserves it (not looking into the
naming problem for now). Having a few more toplevel projects could
help to strip down the "general" jakarta PMC a bit ...and maybe then
the committer == PMC idea is more suitable ...maybe let's get a
smaller umbrella ;-)
*shrug* ...just some RTs - but surely no new ones...
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Martin van den Bemt <ml...@mvdb.net>.
Torsten Curdt wrote:
>
> But if you argue into that direction -no matter how often this has
> been discussed already- I would rather question the idea of an
> umbrella PMC then... (*ducks*)
Time and energy to express the ideas you have in that direction ?
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re: Opening up the PMC
Posted by Torsten Curdt <tc...@apache.org>.
Just a few comments (as I am a bit late)
At Cocoon every committer can join the PMC by just asking for it. The
idea is that committer do care and shape the project anyway. If you
don't care enough about the project - why would you be a committer? We
are quite open and were working out most of the things on the dev list
anyway. This seems to work pretty well for the Cocoon community.
...well, now with Jakarta this is a little different situation - as
stated before it's an umbrella project. Which actually makes the
position of the PMC a bit more complicated ...why should a committer
to commons have an impact on the direction of e.g. hivemind. So maybe
we need to be a bit more selective for the PMC members (as we are).
Maybe.
But if you argue into that direction -no matter how often this has
been discussed already- I would rather question the idea of an
umbrella PMC then... (*ducks*)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Martin van den Bemt <ml...@mvdb.net>.
Just catching up on mail (and pretty tired, so forgive me if not everything is clear / using words
not in an English dictionary. )
Henri Yandell wrote:
>
> What do people think to the following:
>
> 1) Every existing committer not on the pmc receives an email asking if
> they would like to join the pmc. Once that email is sent they are marked
> in a file as having had the email sent and we can wash our hands until a
> reply comes in.
>
> 2) Every new committer automatically gets added to the pmc.
>
I am -1 on both, at least not at this point of time. As you noted yourself, we have over 400
committers currently in Jakarta, which is a huge number. Being on the PMC means project oversight,
legal protection and having binding votes about releases. Do committers who have been inactive for a
long time and are not on the PMC have actually a need to be on the PMC to be able to correctly carry
out their inactiveness ?
I prefer the path the previous chair (wink) had chosen, to at least at the date people were made
committer and monitor those people where possible and at least ping the nominator (who is hopefully
also a kind of mentor to the new committer) after a period in time to ask how everything is going
and if it could be time to get him or her nominated for the PMC.
Phil also proposed the self-nominations. Directly asking for being something (being a committer /
PMC Member, the CEO at a company, etc) is not considered good practice normally, since your actions
should be nominating you, which is, in my view, happening currently, although maybe not as well as
we probably want it to be.
I will make some time this weekend to restructure and update the current pmc documents in subversion
to be able to easier to keep track of people (not meant as a big brother thing, but more as a "we
shouldn't forget" thing). If no one really needs this, than I will do it for just myself, since I
tend to misplace names a lot.
> ---
>
> I bring it up because the concept has cropped up elsewhere at the ASF
> and given our large non-pmc to pmc ratio I think we'll have a lot of
> strong views on the subject.
>
This ratio is not a very good measurement in the Jakarta case. A better ratio is when you add active
committers that are on the pmc and not on the pmc. My gutt feeling says the ratio could probably be
better (as Oleg just noticed), but is not completely broken.
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Martin Cooper <ma...@apache.org>.
On 8/8/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> +1
>
> If they are good enough to change/commit code then they should be able to
> vote. Isn't code the core of what the foundation provides anyways? (er
> something like that...)
Actually, the community is the core. The code flows from the community.
--
Martin Cooper
On 8/8/06, Henri Yandell <ba...@apache.org> wrote:
> >
> >
> > Being on a PMC means two actionable things. Firstly, you get a binding
> > vote; and secondly, you can subscribe to private@jakarta - a list which
> > should be pretty quiet (mostly it's just vote results now - would be
> nice
> > to move those to this list).
> >
> > The purpose of the binding vote is that that allows you to perform
> > oversight on behalf of the foundation - it's not me making a release,
> it's
> > the foundation.
> >
> > That's all there is. It's nothing special, just that we can yay or nay
> > something. There's not even any paperwork beyond the board ack email.
> > Given that - why do we have committers and pmc members? Why do we have
> > people in our community who have been accepted as committers and are
> > happily churning code, but are not allowed a binding vote? It's
> definitely
> > not because we have an enormously low bar of entry to being a committer.
> >
> > My view is that we shouldn't keep wasting our time on such a separation.
> > There is no danger at all (given our size) to having a new committer
> > immediately join the PMC, and there are notable benefits in that we
> don't
> > have to keep remembering to add people to the pmc (which we really suck
> at
> > doing) and we'll have a more open environment (which we all like
> right?).
> > Also we won't have second class citizens who have to yet again sit and
> > wait while their elders remember to nominate them as an elder.
> >
> > What do people think to the following:
> >
> > 1) Every existing committer not on the pmc receives an email asking if
> > they would like to join the pmc. Once that email is sent they are marked
> > in a file as having had the email sent and we can wash our hands until a
> > reply comes in.
> >
> > 2) Every new committer automatically gets added to the pmc.
> >
> > ---
> >
> > I bring it up because the concept has cropped up elsewhere at the ASF
> and
> > given our large non-pmc to pmc ratio I think we'll have a lot of strong
> > views on the subject.
> >
> > Hen
> >
> > (Yeah, I recognize that the above is flamebait if we have any strong
> > opinions out there. Hopefully it'll stay constructive :) )
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>
>
Re: Opening up the PMC
Posted by Jesse Kuhnert <jk...@gmail.com>.
+1
If they are good enough to change/commit code then they should be able to
vote. Isn't code the core of what the foundation provides anyways? (er
something like that...)
On 8/8/06, Henri Yandell <ba...@apache.org> wrote:
>
>
> Being on a PMC means two actionable things. Firstly, you get a binding
> vote; and secondly, you can subscribe to private@jakarta - a list which
> should be pretty quiet (mostly it's just vote results now - would be nice
> to move those to this list).
>
> The purpose of the binding vote is that that allows you to perform
> oversight on behalf of the foundation - it's not me making a release, it's
> the foundation.
>
> That's all there is. It's nothing special, just that we can yay or nay
> something. There's not even any paperwork beyond the board ack email.
> Given that - why do we have committers and pmc members? Why do we have
> people in our community who have been accepted as committers and are
> happily churning code, but are not allowed a binding vote? It's definitely
> not because we have an enormously low bar of entry to being a committer.
>
> My view is that we shouldn't keep wasting our time on such a separation.
> There is no danger at all (given our size) to having a new committer
> immediately join the PMC, and there are notable benefits in that we don't
> have to keep remembering to add people to the pmc (which we really suck at
> doing) and we'll have a more open environment (which we all like right?).
> Also we won't have second class citizens who have to yet again sit and
> wait while their elders remember to nominate them as an elder.
>
> What do people think to the following:
>
> 1) Every existing committer not on the pmc receives an email asking if
> they would like to join the pmc. Once that email is sent they are marked
> in a file as having had the email sent and we can wash our hands until a
> reply comes in.
>
> 2) Every new committer automatically gets added to the pmc.
>
> ---
>
> I bring it up because the concept has cropped up elsewhere at the ASF and
> given our large non-pmc to pmc ratio I think we'll have a lot of strong
> views on the subject.
>
> Hen
>
> (Yeah, I recognize that the above is flamebait if we have any strong
> opinions out there. Hopefully it'll stay constructive :) )
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: Opening up the PMC
Posted by Martin Cooper <ma...@apache.org>.
On 8/14/06, Danny Angus <Da...@slc.co.uk> wrote:
>
> > 1) Every existing committer not on the pmc receives an email asking if
> > they would like to join the pmc. Once that email is sent they are marked
> > in a file as having had the email sent and we can wash our hands until a
> > reply comes in.
>
> I know that this is something that we had as the "end-game" when all the
> re-org changes started.
>
> >
> > 2) Every new committer automatically gets added to the pmc.
>
> I would recommend a probation period, JAMES tends to let people find their
> feet as commiters then propose them for the PMC.
I agree with the probation period as well. In Struts, we look at PMC
membership 6 months after someone becomes a committer. As long as they've
stuck around and participated during that 6 months, we'll generally invite
them to join the PMC. If they've faded away in that timeframe, then we'll
let them go. This helps keep the PMC membership aligned with the people who
are active on the project. (Active people do fade away as well, over time,
so we'll periodically "prune" by moving people to emeritus status.)
As a retrofitting measure, I also kinda like Phil's idea of allowing
self-nominations. In conjunction with a probation period, this would help us
"remember" who should be invited to join the PMC.
--
Martin Cooper
Sometimes its weeks sometimes months, but recently it is everyone and
> having people eased in seems to work well.
>
> d.
>
>
>
> *******************************************************************************************************
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient please delete the
> message from your computer. You may not copy or forward it or use or
> disclose its contents to any other person. As Internet communications are
> capable of data corruption Student Loans Company Limited does not accept any
> responsibility for changes made to this message after it was sent. For this
> reason it may be inappropriate to rely on advice or opinions contained in an
> e-mail without obtaining written confirmation of it. Neither Student Loans
> Company Limited or the sender accepts any liability or responsibility for
> viruses as it is your responsibility to scan attachments (if any). Opinions
> and views expressed in this e-mail are those of the sender and may not
> reflect the opinions and views of The Student Loans Company Limited.
>
> This footnote also confirms that this email message has been swept for the
> presence of computer viruses.
>
>
> ********************************************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re: Opening up the PMC
Posted by Henri Yandell <ba...@apache.org>.
On Wed, 9 Aug 2006, Matt Benson wrote:
> --- Henri Yandell <ba...@apache.org> wrote:
>> On Tue, 8 Aug 2006, Matt Benson wrote:
>>
>>> Henri, out of sheer curiosity, where is it
>> documented
>>> that a commons committer doesn't have a binding
>> vote?
>>> The only thing I could find in the charter [1] was
>> a
>>> link to the Jakarta guidelines [2], which in turn
>>> links to a "Decision Making" page [3], which
>> states
>>> that "the only binding votes are those cast by a
>>> Committer" (the next sentence is pretty
>> interesting as
>>> well, though unrelated).
>>
>>
> http://www.apache.org/foundation/how-it-works.html#roles
>>
>> Our Decision Making page is dated in that respect,
>> probably worth deleting
>> and making sure that the foundation pages have
>> something with the
>> core important parts of it in them.
>
> Since your link was Apache-specific, and my link was
> Jakarta-specific, my assumption would be that Jakarta
> trumps the ASF in its grant of a vote to committers
> rather than PMC only. Ant does this as well; actually
> some changes are a vote of committers and some are PMC
> only, the specifics being outlined in the project
> bylaws. The alternative interpretation is that no
> project has the right to grant a binding vote beyond
> the PMC, thereby overruling the ASF guidelines you
> linked. But this interpretation would indicate a
> large upheaval: a quick look shows that the ASF
> "flagship" (HTTP server) grants committers a vote.
> Gump takes an Ant-like approach (not surprising since
> Gump's originators had worked on Ant). The XML TLP
> also says committers have a vote. IMHO it still looks
> as though Jakarta committers do have a binding vote
> unless the privilege granted at
> http://jakarta.apache.org/site/decisions.html is
> explicitly rescinded.
In theory I think you're right. Subproject process overrides foundation
process as long as it doesn't clash with foundation process. ie) We can't
have a sub-pmc for Jakarta ECS etc.
Many of the pages on voting out there predate the informal nudging from
the board that only PMC votes are binding on PMC issues, and probably also
predate the foundation page I mentioned. The Jakarta page definitely does
and clashes with the foundation process so needs a change.
The general interpretation seems to be that there are issues which
committers can vote on, and issues that have to be the PMC. Code issues
are often placed in the former, release and process in the latter. It's
only issues of a legal concern (I think) that have to be in the latter.
Very nice tables on the Ant bylaws btw :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Matt Benson <gu...@yahoo.com>.
--- Henri Yandell <ba...@apache.org> wrote:
> On Tue, 8 Aug 2006, Matt Benson wrote:
>
> > Henri, out of sheer curiosity, where is it
> documented
> > that a commons committer doesn't have a binding
> vote?
> > The only thing I could find in the charter [1] was
> a
> > link to the Jakarta guidelines [2], which in turn
> > links to a "Decision Making" page [3], which
> states
> > that "the only binding votes are those cast by a
> > Committer" (the next sentence is pretty
> interesting as
> > well, though unrelated).
>
>
http://www.apache.org/foundation/how-it-works.html#roles
>
> Our Decision Making page is dated in that respect,
> probably worth deleting
> and making sure that the foundation pages have
> something with the
> core important parts of it in them.
Since your link was Apache-specific, and my link was
Jakarta-specific, my assumption would be that Jakarta
trumps the ASF in its grant of a vote to committers
rather than PMC only. Ant does this as well; actually
some changes are a vote of committers and some are PMC
only, the specifics being outlined in the project
bylaws. The alternative interpretation is that no
project has the right to grant a binding vote beyond
the PMC, thereby overruling the ASF guidelines you
linked. But this interpretation would indicate a
large upheaval: a quick look shows that the ASF
"flagship" (HTTP server) grants committers a vote.
Gump takes an Ant-like approach (not surprising since
Gump's originators had worked on Ant). The XML TLP
also says committers have a vote. IMHO it still looks
as though Jakarta committers do have a binding vote
unless the privilege granted at
http://jakarta.apache.org/site/decisions.html is
explicitly rescinded.
FWIW,
Matt
>
> Hen
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> general-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Henri Yandell <ba...@apache.org>.
On Tue, 8 Aug 2006, Matt Benson wrote:
> Henri, out of sheer curiosity, where is it documented
> that a commons committer doesn't have a binding vote?
> The only thing I could find in the charter [1] was a
> link to the Jakarta guidelines [2], which in turn
> links to a "Decision Making" page [3], which states
> that "the only binding votes are those cast by a
> Committer" (the next sentence is pretty interesting as
> well, though unrelated).
http://www.apache.org/foundation/how-it-works.html#roles
Our Decision Making page is dated in that respect, probably worth deleting
and making sure that the foundation pages have something with the
core important parts of it in them.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Matt Benson <gu...@yahoo.com>.
--- Henri Yandell <ba...@apache.org> wrote:
>
> Being on a PMC means two actionable things. Firstly,
> you get a binding
> vote; and secondly, you can subscribe to
> private@jakarta - a list which
> should be pretty quiet (mostly it's just vote
> results now - would be nice
> to move those to this list).
Henri, out of sheer curiosity, where is it documented
that a commons committer doesn't have a binding vote?
The only thing I could find in the charter [1] was a
link to the Jakarta guidelines [2], which in turn
links to a "Decision Making" page [3], which states
that "the only binding votes are those cast by a
Committer" (the next sentence is pretty interesting as
well, though unrelated).
Thanks,
Matt
[1] http://jakarta.apache.org/commons/charter.html
[2] http://jakarta.apache.org/site/guidelines.html
[3] http://jakarta.apache.org/site/decisions.html
>
> The purpose of the binding vote is that that allows
> you to perform
> oversight on behalf of the foundation - it's not me
> making a release, it's
> the foundation.
>
> That's all there is. It's nothing special, just that
> we can yay or nay
> something. There's not even any paperwork beyond the
> board ack email.
> Given that - why do we have committers and pmc
> members? Why do we have
> people in our community who have been accepted as
> committers and are
> happily churning code, but are not allowed a binding
> vote? It's definitely
> not because we have an enormously low bar of entry
> to being a committer.
>
> My view is that we shouldn't keep wasting our time
> on such a separation.
> There is no danger at all (given our size) to having
> a new committer
> immediately join the PMC, and there are notable
> benefits in that we don't
> have to keep remembering to add people to the pmc
> (which we really suck at
> doing) and we'll have a more open environment (which
> we all like right?).
> Also we won't have second class citizens who have to
> yet again sit and
> wait while their elders remember to nominate them as
> an elder.
>
> What do people think to the following:
>
> 1) Every existing committer not on the pmc receives
> an email asking if
> they would like to join the pmc. Once that email is
> sent they are marked
> in a file as having had the email sent and we can
> wash our hands until a
> reply comes in.
>
> 2) Every new committer automatically gets added to
> the pmc.
>
> ---
>
> I bring it up because the concept has cropped up
> elsewhere at the ASF and
> given our large non-pmc to pmc ratio I think we'll
> have a lot of strong
> views on the subject.
>
> Hen
>
> (Yeah, I recognize that the above is flamebait if we
> have any strong
> opinions out there. Hopefully it'll stay
> constructive :) )
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> general-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Opening up the PMC
Posted by Danny Angus <Da...@slc.co.uk>.
> 1) Every existing committer not on the pmc receives an email asking if
> they would like to join the pmc. Once that email is sent they are marked
> in a file as having had the email sent and we can wash our hands until a
> reply comes in.
I know that this is something that we had as the "end-game" when all the
re-org changes started.
>
> 2) Every new committer automatically gets added to the pmc.
I would recommend a probation period, JAMES tends to let people find their
feet as commiters then propose them for the PMC.
Sometimes its weeks sometimes months, but recently it is everyone and
having people eased in seems to work well.
d.
*******************************************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
********************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org