You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apps-dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/12/04 05:59:02 UTC
Charter.txt
I added the text to the draft charter to Avalon CVS in the following
location: ${jakarta-avalon}/src/proposal/CHARTER.txt
We can take this charter and pick it apart piece by piece. I suggest
that we start section by section coming up with the best wording. What
is currently there should be considered only a starting point based on
the charter from an existing Apache TLP.
We can incorporate comments from other folks doing the same in other
newly formed TLPs.
Stephen has already made clear his dislike of the word "unanimous",
but before we blindly remove that word, we need to come to community
consensus.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>
> Steve, your fears are duly noted. Keep in mind that it is the PMC that
> must be unanimous--not the general committer populus.
>
> I am sure that people who have a proven track record of being able to
> work with others can come to agreement. I am also sure that unanimous
> has to work any time there is a legal issue at stake. Remember PMC
> does not make technical decisions so there is unlikely to be an undue
> amount of blocking--and never for frivolent reasons.
>
> PMC is responsible to oversee the legal aspects of this community.
Two points:
1) If a PMC gets to the point of being deadlocked to the point where it
is no longer functional, it will simply be disolved. Conceivably, at
that point, proposals for a new PMC may be entertained by the board.
2) Code commits, arguably the most technical aspect of *any* project,
are to be done in accordance to a "consensus based development process".
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>
> Steve, your fears are duly noted. Keep in mind that it is the PMC that
> must be unanimous--not the general committer populus.
>
> I am sure that people who have a proven track record of being able to
> work with others can come to agreement. I am also sure that unanimous
> has to work any time there is a legal issue at stake. Remember PMC
> does not make technical decisions so there is unlikely to be an undue
> amount of blocking--and never for frivolent reasons.
>
> PMC is responsible to oversee the legal aspects of this community.
Two points:
1) If a PMC gets to the point of being deadlocked to the point where it
is no longer functional, it will simply be disolved. Conceivably, at
that point, proposals for a new PMC may be entertained by the board.
2) Code commits, arguably the most technical aspect of *any* project,
are to be done in accordance to a "consensus based development process".
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>>> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>>
>>> <stuff/>
>>>
>>> I wonder if I'm the only one who feels that you two guys want to
>>> engineer the Avalon charter to route around one another.
>>
>>
>>
>> Are you referring to Stephen and I?
>
>
> No, I'm referring to Mr. Peter Donald and Mr. Stephen McConnell
Stefano:
I think your drawing a rather negative conclusion here. As one of the
guys that your referring to above I would like to clear up something
that appears to be a widely held misconception. What I want to achieve
is not a solution to "routing around one another" - if fact, quite the
opposite. I want to ensure that the PMC can confront and resolve issues
if they arise.
Cheers, Steve.
p.s. You can call be Steve if you like!
:-)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: -1 technical vetoes
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> It has been said that -1s are vetos, and majority votes where
> it's clear that a voting is in progress on majority rules.
Seems reasonable. Short and simple.
I think that instead of adding even more bureaucracy to the
voting process with -VETO, -0.99, -0.9999... etc. we should
go with the usual +1/-1.
If someone vetoes anything, you can always ask if it is a
veto, and if so, if there are any ways to make that
someone take back the veto.
Voting isn't rocket science, and I don't think we should
need complex rules for it. Especially this veto thing
has been given a real good "what is a valid veto", which
shouldn't really be an issue, given sensible people. I would
also assert that given non-sensible people, no voting
procedure will help.
As has been stated here, the important part isn't the
voting, it is the discussion leading up to the vote.
After that, voting is a formality.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: -1 technical vetoes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leif Mortenson wrote:
> What about setting it up so that a -1 is a vote by default. If someone
> really
> wants to pull the veto card then they can specifically write -VETO or
> something
> like that. This way people can safely vote their disapproval without it
> being
> as strong as a veto. The ability to veto any vote will still be
> preserved this way.
>
> -1 can be viewed as a simple vote without stepping on any toes. If a user
> writes VETO on a vote, then they should be required to explain themselves
> thoroughly.
We had this discussion on the incubator list.
It has been said that -1s are vetos, and majority votes where it's clear
that a voting is in progress on majority rules.
This is the reason why I restated here the suggestion that had been done
there to use -0.99 and variants to suggest strong disagreement without
getting to a veto, in the cases where is would apply, and never use -1
just to express a non-binding opinion.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: -1 technical vetoes
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leif Mortenson [mailto:leif@tanukisoftware.com]
>
> What about setting it up so that a -1 is a vote by default.
> If someone
> really
> wants to pull the veto card then they can specifically write -VETO or
> something
> like that. This way people can safely vote their disapproval
> without it
> being
> as strong as a veto. The ability to veto any vote will still be
> preserved this way.
>
> -1 can be viewed as a simple vote without stepping on any
> toes. If a user
> writes VETO on a vote, then they should be required to
> explain themselves
> thoroughly.
Unfortunately that doesn't work. Not expressing your oppinion
in voting is giving the message "I don't care what you do in this
matter". I don't want to change the expected semantic from that
to "I am against your proposal" which is what a -1 expresses.
Honestly, the -1 vote means that there needs to be some more
discussion. It might be that the concept is sound, but the
implementation needs to be reworked. It might be that the
concept and implementation are good, but we need test cases
to prove it. ALL -1 votes should provide a topic for community
discussion, and in the end should be resolvable by the community.
If that means that the proposal gets dropped for the time
being (i.e. several -1 votes) then the person can either
choose to take a different approach with what they were
proposing or they can drop it themselves.
The -1 is a safety net. Different people have different
backgrounds, and if one person has been burned by a bad design
or a security hole, they will be able to recognize the culprit
in new code being proposed.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: -1 technical vetoes
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leif,
> What about setting it up so that a -1 is a vote by default.
Please understand that the ASF already has clear procedures for voting, and
it was NOT my point to change the process in any way! My intent was simply
to suggest a mindset that a -1 vote on technical matters (where they are
binding vetoes) be used constructively to ensure that critical issues are
resolved, not used as a roadblock. That is why I made the suggestion that a
voter include in the justification for the -1 the conditions necessary to be
resolved. So that there is immediate constructive input to start the
resolution processs.
As Berin said, "the -1 vote means that there needs to be some more
discussion. [ALL] -1 votes should provide a topic for community discussion,
and in the end should be resolvable by the community. [The] -1 is a safety
net."
If people simply want to disagree without a binding veto, they can vote -0.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: -1 technical vetoes
Posted by Leif Mortenson <le...@tanukisoftware.com>.
What about setting it up so that a -1 is a vote by default. If someone
really
wants to pull the veto card then they can specifically write -VETO or
something
like that. This way people can safely vote their disapproval without it
being
as strong as a veto. The ability to veto any vote will still be
preserved this way.
-1 can be viewed as a simple vote without stepping on any toes. If a user
writes VETO on a vote, then they should be required to explain themselves
thoroughly.
Cheers,
Leif
Noel J. Bergman wrote:
>Costin Manolache wrote:
>
>
>>I think the most important thing in tomcat evolution the idea that if 3
>>committers are voting +1 and need something, there is enough reason to
>>not vote -1 ( especially if it can be implemented as an option).
>>
>>
>
>My take is that -1 votes on technical issues (vetoes) should (a) only be
>given when the voter has important technical issue(s) to raise; (b) be
>expressed as conditional: "My vote is -1 until/unless the following issue(s)
>are resolved"; and (c) those issues should generally arise, and be
>addressed, long before the need for a formal vote.
>
>Does anyone disagree? If so, under what circumstances?
>
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
-1 technical vetoes
Posted by "Noel J. Bergman" <no...@devtech.com>.
Costin Manolache wrote:
> I think the most important thing in tomcat evolution the idea that if 3
> committers are voting +1 and need something, there is enough reason to
> not vote -1 ( especially if it can be implemented as an option).
My take is that -1 votes on technical issues (vetoes) should (a) only be
given when the voter has important technical issue(s) to raise; (b) be
expressed as conditional: "My vote is -1 until/unless the following issue(s)
are resolved"; and (c) those issues should generally arise, and be
addressed, long before the need for a formal vote.
Does anyone disagree? If so, under what circumstances?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Costin Manolache <cm...@yahoo.com>.
Stefano Mazzocchi wrote:
...
> Reminds me of the Tomcat 3.x vs. 4.x mess where Costin and Craig hated
> each other. Now that both are gone, Tomcat is going to be finally unified.
For the record: I didn't hate Craig and I don't think he hates me.
And none of us is "gone".
Both Craig and I ( and many other tomcat people ) were right on a number of
issues and wrong on others, and the 'unified' tomcat is hopefully the set
of "right" from all sides.
Also for the record: it was _never_ about Craig and me. If someone thinks
that, he didn't understand anything. There are a lot of other people
involved, principles, goals, tradeoffs and interests.
I assume avalon is in a similar situation - and it's better to have
correct information.
I think the most important thing in tomcat evolution the idea that if 3
committers are voting +1 and need something, there is enough reason to
not vote -1 ( especially if it can be implemented as an option). And of
course, the majority vote - without that we wouldn't be where we are.
Costin
>
> Do we have to reach that point or you two are smart enough to understand
> the value of cooperation?
>
> That's what I'm worried about, not some stupid voting rules.
>
> > I believe we both have
>> valid points, and I proposed what I think is a valid compromise.
>> Hopefully Stephen will agree to that middle ground.
>
> Anyway, I find it funny that even if your name was not mentionned, you
> felt attacked :) We call that 'coda di paglia' in italian :-) [that
> would be translated as 'straw tail' in english, but I'm sure it doesn't
> make sense to you]
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Sam Ruby <ru...@apache.org>.
Stefano Mazzocchi wrote:
> Peter Donald wrote:
>
>> On Thu, 5 Dec 2002 08:47, Stefano Mazzocchi wrote:
>>
>>> It seems (at least to me) that Peter likes the fact to be able to
>>> 'block' directions that he doesn't like.
>>
>> Not quite accurate. I would like to have people listen to each other
>> and ultimately the developers get to decide where something goes - not
>> some beuracratic process.
>
> Good, I fully resonate with this vision.
>
> Hopefully, nobody will play the 'roadblock' just because he/she believes
> nobody is listening or getting it while, in fact, the community decided
> against him/her.
>
> But if that happens, there will be ways to remove that roadblock so I
> don't see needs to over-beaurocraticize the whole thing.
I suspect that there is a subtle difference between what both of you
mean by "the developers". I'd like to see an Avalon where, when
somebody submits a patch, the result is owned by the entire Avalon
community. If somebody desires some other result, then the patch should
be submitted elsewhere.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Thu, 5 Dec 2002 08:47, Stefano Mazzocchi wrote:
>
>>It seems (at least to me) that Peter likes the fact to be able to
>>'block' directions that he doesn't like.
>
>
> Not quite accurate. I would like to have people listen to each other and
> ultimately the developers get to decide where something goes - not some
> beuracratic process.
Good, I fully resonate with this vision.
Hopefully, nobody will play the 'roadblock' just because he/she believes
nobody is listening or getting it while, in fact, the community decided
against him/her.
But if that happens, there will be ways to remove that roadblock so I
don't see needs to over-beaurocraticize the whole thing.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 5 Dec 2002 08:47, Stefano Mazzocchi wrote:
> It seems (at least to me) that Peter likes the fact to be able to
> 'block' directions that he doesn't like.
Not quite accurate. I would like to have people listen to each other and
ultimately the developers get to decide where something goes - not some
beuracratic process.
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> > I believe we both have
> > valid points, and I proposed what I think is a valid compromise.
> > Hopefully Stephen will agree to that middle ground.
>
> Anyway, I find it funny that even if your name was not
> mentionned, you
> felt attacked :) We call that 'coda di paglia' in italian :-) [that
> would be translated as 'straw tail' in english, but I'm sure
> it doesn't
> make sense to you]
I didn't feel attacked, but there was my name, Stephen's name, and
Peter's name all in the list. Since there has been more back and
forth between me and Stephen lately, I thought that I was included
in your context.
It's a misunderstanding. I have thick skin, don't worry ;P
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>
>>Stephen McConnell wrote:
>>
>>>
>>>Peter Donald wrote:
>>>
>>>
>>>>On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>>>>
>>>>
>>>>
>>>>>Stephen has already made clear his dislike of the word
>>>>
>>"unanimous",
>>
>>>>>but before we blindly remove that word, we need to come
>>>>
>>to community
>>
>>>>>consensus.
>>>>
>>>>I am +1 on unanimous because it forces consensus for
>>>
>>forward motion.
>>
>>>>It may mean things take longer to get decided but usually the
>>>>decisions are better for it.
>>>>
>>>
>>>And thereby grant the right to a single individual to block
>>
>>progress.
>>
>>>That takes away the ability of the PMC to function. If when
>>
>>you take
>>
>>>away it ability to function you have taken away its ability
>>
>>to represent
>>
>>>the comunity and its ability to meet its obligations to the board.
>>
>>I wonder if I'm the only one who feels that you two guys want to
>>engineer the Avalon charter to route around one another.
>
>
> Are you referring to Stephen and I?
No, I'm referring to Mr. Peter Donald and Mr. Stephen McConnell
> That is not the case.
I know, dude, I know, don't worry.
> We
> both feel burned by events in the past, and neither of us wants
> the same mistake to repeat itself.
Yes. This is the case for you. But I don't perceive this being the case
for the relationship between these two gentlemen.
It seems (at least to me) that Peter likes the fact to be able to
'block' directions that he doesn't like. And Stephen hates the fact that
he has the power to do that because he feels that he's going to do it.
I find *this* something so disruptive that no voting rule can possible
heal it.
Reminds me of the Tomcat 3.x vs. 4.x mess where Costin and Craig hated
each other. Now that both are gone, Tomcat is going to be finally unified.
Do we have to reach that point or you two are smart enough to understand
the value of cooperation?
That's what I'm worried about, not some stupid voting rules.
> I believe we both have
> valid points, and I proposed what I think is a valid compromise.
> Hopefully Stephen will agree to that middle ground.
Anyway, I find it funny that even if your name was not mentionned, you
felt attacked :) We call that 'coda di paglia' in italian :-) [that
would be translated as 'straw tail' in english, but I'm sure it doesn't
make sense to you]
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Stephen McConnell wrote:
> >
> >
> > Peter Donald wrote:
> >
> >> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> >>
> >>
> >>> Stephen has already made clear his dislike of the word
> "unanimous",
> >>> but before we blindly remove that word, we need to come
> to community
> >>> consensus.
> >>
> >> I am +1 on unanimous because it forces consensus for
> forward motion.
> >> It may mean things take longer to get decided but usually the
> >> decisions are better for it.
> >>
> >
> > And thereby grant the right to a single individual to block
> progress.
> > That takes away the ability of the PMC to function. If when
> you take
> > away it ability to function you have taken away its ability
> to represent
> > the comunity and its ability to meet its obligations to the board.
>
> I wonder if I'm the only one who feels that you two guys want to
> engineer the Avalon charter to route around one another.
Are you referring to Stephen and I? That is not the case. We
both feel burned by events in the past, and neither of us wants
the same mistake to repeat itself. I believe we both have
valid points, and I proposed what I think is a valid compromise.
Hopefully Stephen will agree to that middle ground.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I wonder if I'm the only one who feels that you two guys want to
> engineer the Avalon charter to route around one another.
You are not even remotely the only one. And I honestly don't believe that
either of them realizes it. More on that in a message I've been working on.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I wonder if I'm the only one who feels that you two guys want to
> engineer the Avalon charter to route around one another.
You are not even remotely the only one. And I honestly don't believe that
either of them realizes it. More on that in a message I've been working on.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Stephen McConnell wrote:
> >
> >
> > Peter Donald wrote:
> >
> >> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> >>
> >>
> >>> Stephen has already made clear his dislike of the word
> "unanimous",
> >>> but before we blindly remove that word, we need to come
> to community
> >>> consensus.
> >>
> >> I am +1 on unanimous because it forces consensus for
> forward motion.
> >> It may mean things take longer to get decided but usually the
> >> decisions are better for it.
> >>
> >
> > And thereby grant the right to a single individual to block
> progress.
> > That takes away the ability of the PMC to function. If when
> you take
> > away it ability to function you have taken away its ability
> to represent
> > the comunity and its ability to meet its obligations to the board.
>
> I wonder if I'm the only one who feels that you two guys want to
> engineer the Avalon charter to route around one another.
Are you referring to Stephen and I? That is not the case. We
both feel burned by events in the past, and neither of us wants
the same mistake to repeat itself. I believe we both have
valid points, and I proposed what I think is a valid compromise.
Hopefully Stephen will agree to that middle ground.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Stephen McConnell wrote:
> >
> >
> > Peter Donald wrote:
> >
> >> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> >>
> >>
> >>> Stephen has already made clear his dislike of the word
> "unanimous",
> >>> but before we blindly remove that word, we need to come
> to community
> >>> consensus.
> >>
> >> I am +1 on unanimous because it forces consensus for
> forward motion.
> >> It may mean things take longer to get decided but usually the
> >> decisions are better for it.
> >>
> >
> > And thereby grant the right to a single individual to block
> progress.
> > That takes away the ability of the PMC to function. If when
> you take
> > away it ability to function you have taken away its ability
> to represent
> > the comunity and its ability to meet its obligations to the board.
>
> I wonder if I'm the only one who feels that you two guys want to
> engineer the Avalon charter to route around one another.
Are you referring to Stephen and I? That is not the case. We
both feel burned by events in the past, and neither of us wants
the same mistake to repeat itself. I believe we both have
valid points, and I proposed what I think is a valid compromise.
Hopefully Stephen will agree to that middle ground.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I wonder if I'm the only one who feels that you two guys want to
> engineer the Avalon charter to route around one another.
You are not even remotely the only one. And I honestly don't believe that
either of them realizes it. More on that in a message I've been working on.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>>
>>
>>> Stephen has already made clear his dislike of the word "unanimous",
>>> but before we blindly remove that word, we need to come to community
>>> consensus.
>>>
>>
>>
>> I am +1 on unanimous because it forces consensus for forward motion.
>> It may mean things take longer to get decided but usually the
>> decisions are better for it.
>>
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability to represent
> the comunity and its ability to meet its obligations to the board.
I wonder if I'm the only one who feels that you two guys want to
engineer the Avalon charter to route around one another.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>
> Steve, your fears are duly noted. Keep in mind that it is the PMC that
> must be unanimous--not the general committer populus.
>
> I am sure that people who have a proven track record of being able to
> work with others can come to agreement. I am also sure that unanimous
> has to work any time there is a legal issue at stake. Remember PMC
> does not make technical decisions so there is unlikely to be an undue
> amount of blocking--and never for frivolent reasons.
>
> PMC is responsible to oversee the legal aspects of this community.
Two points:
1) If a PMC gets to the point of being deadlocked to the point where it
is no longer functional, it will simply be disolved. Conceivably, at
that point, proposals for a new PMC may be entertained by the board.
2) Code commits, arguably the most technical aspect of *any* project,
are to be done in accordance to a "consensus based development process".
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>>
>>
>>> Stephen has already made clear his dislike of the word "unanimous",
>>> but before we blindly remove that word, we need to come to community
>>> consensus.
>>>
>>
>>
>> I am +1 on unanimous because it forces consensus for forward motion.
>> It may mean things take longer to get decided but usually the
>> decisions are better for it.
>>
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability to represent
> the comunity and its ability to meet its obligations to the board.
I wonder if I'm the only one who feels that you two guys want to
engineer the Avalon charter to route around one another.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>>
>>
>>> Stephen has already made clear his dislike of the word "unanimous",
>>> but before we blindly remove that word, we need to come to community
>>> consensus.
>>>
>>
>>
>> I am +1 on unanimous because it forces consensus for forward motion.
>> It may mean things take longer to get decided but usually the
>> decisions are better for it.
>>
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability to represent
> the comunity and its ability to meet its obligations to the board.
I wonder if I'm the only one who feels that you two guys want to
engineer the Avalon charter to route around one another.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The paragraph should simply be stricken. It doesn't mesh with reality.
OK. I'd have thought so too, but since it came from the XML Charter ...
[see below]
> The Board has never approved a PMC charter. Whatever the XML guys
> wrote, it hasn't been reviewed and ratified by the Board.
Color me very surprised. Shocked even. From the earlier comment from Sam
Ruby: "Independent of prior charters that may have been approved, I intend
to review future charters with an eye for (1) effectively demonstrating
oversight and (2) adherance to the "collaborative, consensus based
development process" that is supposed to characterize all Apache projects",
I assumed that it was the ASF Board that had done the approving.
Well, doesn't that meet the classic definition of ass-u-me. Or at least my
half of it. :-(
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Greg Stein <gs...@lyra.org>.
In article <NB...@devtech.com>, "Noel J.
Bergman" <no...@devtech.com> wrote:
>> > - "In the unlikely event that a member of the PMC becomes disruptive
>> > to the process or ceases to contribute for an extended period, said
>> > member may be removed by unanimous vote of remaining PMC members."
>
>> can't we just delete that paragraph? It sounds pretty negative. Seems
>> to me that a disfunctional PMC is best remedied by intervention of "the
>> next higher body",
The next higher body is the PMC Chair. As of the last Board meeting,
Chairs can now alter the composition of the PMC without needing to send a
resolution to the Board for voting upon. However, the Chair *does* need to
send a notification to the Board about the change, a Direct must ACK the
notification, and then it takes effect 72 hours after that. This gives the
Board a chance to deal with rogue changes to the PMC composition, but
otherwise leaves it to the PMC Chair to add/remove members as appropriate.
The paragraph should simply be stricken. It doesn't mesh with reality.
> That clause exists in the original charter taken from xml.apache.org,
> and approved by the ASF Board.
Nope. The Board has never approved a PMC charter. Whatever the XML guys
wrote, it hasn't been reviewed and ratified by the Board.
> Your negative response to that clause
> may be a conditioned perception based upon reading it within the current
> nature of this community. You EXPECT disruption.
Whatever the case, it should go away.
Cheers,
-g
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Leo Simons <le...@apache.org>.
On Thu, 2002-12-05 at 20:37, Berin Loritsch wrote:
> > - in the mission part: "avalon.apache.org exists to promote the use of
> > Avalon components." Good idea to change this to promote _and
> > facilitate_?
>
> Sounds good. I just threw that together, and we really need to work on
> the mission part together.
I mostly like it, actually :D
still thinking....
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> comments:
>
> - avalon is called "avalon.apache.org" throughout. Shouldn't we simply
> call it Apache Avalon?
+1. I just thought it would be wierd to have xml.apache.org throughout
for ourselves.
> - in the mission part: "avalon.apache.org exists to promote the use of
> Avalon components." Good idea to change this to promote _and
> facilitate_?
Sounds good. I just threw that together, and we really need to work on
the mission part together. I debated wether to have a starting place or
leave it as a placeholder.
> - "In the unlikely event that a member of the PMC becomes disruptive to
> the process or ceases to contribute for an extended period, said
> member may be removed by unanimous vote of remaining PMC members."
>
> can't we just delete that paragraph? It sounds pretty negative. Seems to
> me that a disfunctional PMC is best remedied by intervention of "the
> next higher body", though I'm not quite sure who that is (the officer or
> the board I guess)
The next higher body is the board. from what I understand.
> - "SUBPROJECTS
> ===========
> avalon.apache.org is comprised of subprojects; a subproject is a
> component whose scope is well defined. Each subproject has its own
> set of developers."
>
> I think the subproject model has proven not to work too well (I believe
> that's part of the reason for reorganizing the ASF in the first place).
> Can we just remove the whole 'subproject' notion from the charter
> completely? I especially dislike "each subproject has its own set of
> developers".
>
> - "Committers are developers who have read/write access to the source
> code repository."
>
> Jakarta docs say "A Committer has write access to the source code
> repository and gains voting rights allowing them to affect the future of
> the subproject". Shouldn't we have a reference to voting rights in here?
There is question whether we will even have subprojects.
>
> - "THE DEVELOPMENT PROCESS
> =======================
> The development process is intentionally lightweight; like other
> Apache projects"
>
> would be nice to "incorporate by reference" here. There's not a doc
> ready for any of that yet I guess.
The only things I have seen are the Incubator voting docs and the
Apache bylaws.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Simons <le...@apache.org>.
(headsup)
Hey people,
I've just made quite a few changes to the charter draft. Not about the
stuff discussed atm (voting et al), but some changes just about
everywhere else. All comments welcome :D
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > - "In the unlikely event that a member of the PMC becomes disruptive to
> > the process or ceases to contribute for an extended period, said
> > member may be removed by unanimous vote of remaining PMC members."
> can't we just delete that paragraph? It sounds pretty negative. Seems to
> me that a disfunctional PMC is best remedied by intervention of "the
> next higher body",
That clause exists in the original charter taken from xml.apache.org, and
approved by the ASF Board. Your negative response to that clause may be a
conditioned perception based upon reading it within the current nature of
this community. You EXPECT disruption.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Simons <le...@apache.org>.
comments:
- avalon is called "avalon.apache.org" throughout. Shouldn't we simply
call it Apache Avalon?
- in the mission part: "avalon.apache.org exists to promote the use of
Avalon components." Good idea to change this to promote _and
facilitate_?
- "In the unlikely event that a member of the PMC becomes disruptive to
the process or ceases to contribute for an extended period, said
member may be removed by unanimous vote of remaining PMC members."
can't we just delete that paragraph? It sounds pretty negative. Seems to
me that a disfunctional PMC is best remedied by intervention of "the
next higher body", though I'm not quite sure who that is (the officer or
the board I guess)
- "SUBPROJECTS
===========
avalon.apache.org is comprised of subprojects; a subproject is a
component whose scope is well defined. Each subproject has its own
set of developers."
I think the subproject model has proven not to work too well (I believe
that's part of the reason for reorganizing the ASF in the first place).
Can we just remove the whole 'subproject' notion from the charter
completely? I especially dislike "each subproject has its own set of
developers".
- "Committers are developers who have read/write access to the source
code repository."
Jakarta docs say "A Committer has write access to the source code
repository and gains voting rights allowing them to affect the future of
the subproject". Shouldn't we have a reference to voting rights in here?
- "THE DEVELOPMENT PROCESS
=======================
The development process is intentionally lightweight; like other
Apache projects"
would be nice to "incorporate by reference" here. There's not a doc
ready for any of that yet I guess.
that's it for now...more thoughts to come.....
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-12-04 at 17:34, Noel J. Bergman wrote:
> > And thereby grant the right to a single individual to block progress.
> > That takes away the ability of the PMC to function.
>
> Please see http://incubator.apache.org/drafts/voting.html and check with Sam
> Ruby. The draft document currently states: "votes on procedural issues
> follow the common format of majority rule unless otherwise stated." See
> also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF
> Board, why should the PMC voting policy be any different?
>
> I reiterate my earlier suggestion that the PMC Charter draw upon and
> incorporate by reference existing ASF policy documents.
yes please! I think having the Avalon PMC follow the same rules the
board follows is a good idea. I also think having the avalon community
follow the same rules as the rest of apache "the standard apache voting
guidelines 'n stuff" is good.
cheers,
- Leo, trying to make up his mind on the drafts
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>And thereby grant the right to a single individual to block progress.
>>That takes away the ability of the PMC to function.
>>
>>
>
>Please see http://incubator.apache.org/drafts/voting.html and check with Sam
>Ruby. The draft document currently states: "votes on procedural issues
>follow the common format of majority rule unless otherwise stated." See
>also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF
>Board, why should the PMC voting policy be any different?
>
>I reiterate my earlier suggestion that the PMC Charter draw upon and
>incorporate by reference existing ASF policy documents.
>
>
YES, YES, YES, YES, YES....
Thank you Noel!
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>And thereby grant the right to a single individual to block progress.
>>That takes away the ability of the PMC to function.
>>
>>
>
>Please see http://incubator.apache.org/drafts/voting.html and check with Sam
>Ruby. The draft document currently states: "votes on procedural issues
>follow the common format of majority rule unless otherwise stated." See
>also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF
>Board, why should the PMC voting policy be any different?
>
>I reiterate my earlier suggestion that the PMC Charter draw upon and
>incorporate by reference existing ASF policy documents.
>
>
YES, YES, YES, YES, YES....
Thank you Noel!
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>And thereby grant the right to a single individual to block progress.
>>That takes away the ability of the PMC to function.
>>
>>
>
>Please see http://incubator.apache.org/drafts/voting.html and check with Sam
>Ruby. The draft document currently states: "votes on procedural issues
>follow the common format of majority rule unless otherwise stated." See
>also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF
>Board, why should the PMC voting policy be any different?
>
>I reiterate my earlier suggestion that the PMC Charter draw upon and
>incorporate by reference existing ASF policy documents.
>
>
YES, YES, YES, YES, YES....
Thank you Noel!
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function.
Please see http://incubator.apache.org/drafts/voting.html and check with Sam
Ruby. The draft document currently states: "votes on procedural issues
follow the common format of majority rule unless otherwise stated." See
also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF
Board, why should the PMC voting policy be any different?
I reiterate my earlier suggestion that the PMC Charter draw upon and
incorporate by reference existing ASF policy documents.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > And thereby grant the right to a single individual to block
> progress.
> > That takes away the ability of the PMC to function. If when
> you take
> > away it ability to function you have taken away its ability
> > to represent the comunity and its ability to meet its obligations
> > to the board.
>
> 1) That's the downside of concensus-based development.
This is for the PMC--or should only be for the PMC.
> 2) If the person is "disruptive" he can be kicked out.
Yes, but I classify disruptive as someone who is trying to
sabotage the project--not someone who merely disagrees.
If someone intentionally wipes out the CVS repository, I
classify that as disruptive. Things like that.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > And thereby grant the right to a single individual to block
> progress.
> > That takes away the ability of the PMC to function. If when
> you take
> > away it ability to function you have taken away its ability
> > to represent the comunity and its ability to meet its obligations
> > to the board.
>
> 1) That's the downside of concensus-based development.
This is for the PMC--or should only be for the PMC.
> 2) If the person is "disruptive" he can be kicked out.
Yes, but I classify disruptive as someone who is trying to
sabotage the project--not someone who merely disagrees.
If someone intentionally wipes out the CVS repository, I
classify that as disruptive. Things like that.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function.
Please see http://incubator.apache.org/drafts/voting.html and check with Sam
Ruby. The draft document currently states: "votes on procedural issues
follow the common format of majority rule unless otherwise stated." See
also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF
Board, why should the PMC voting policy be any different?
I reiterate my earlier suggestion that the PMC Charter draw upon and
incorporate by reference existing ASF policy documents.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function.
Please see http://incubator.apache.org/drafts/voting.html and check with Sam
Ruby. The draft document currently states: "votes on procedural issues
follow the common format of majority rule unless otherwise stated." See
also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF
Board, why should the PMC voting policy be any different?
I reiterate my earlier suggestion that the PMC Charter draw upon and
incorporate by reference existing ASF policy documents.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > And thereby grant the right to a single individual to block
> progress.
> > That takes away the ability of the PMC to function. If when
> you take
> > away it ability to function you have taken away its ability
> > to represent the comunity and its ability to meet its obligations
> > to the board.
>
> 1) That's the downside of concensus-based development.
This is for the PMC--or should only be for the PMC.
> 2) If the person is "disruptive" he can be kicked out.
Yes, but I classify disruptive as someone who is trying to
sabotage the project--not someone who merely disagrees.
If someone intentionally wipes out the CVS repository, I
classify that as disruptive. Things like that.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability
> to represent the comunity and its ability to meet its obligations
> to the board.
1) That's the downside of concensus-based development.
2) If the person is "disruptive" he can be kicked out.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability
> to represent the comunity and its ability to meet its obligations
> to the board.
1) That's the downside of concensus-based development.
2) If the person is "disruptive" he can be kicked out.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> >Steve, your fears are duly noted. Keep in mind that it is
> the PMC that
> >must be unanimous--not the general committer populus.
> >
> >
> THAT IS WHAT I AM TOTALLY OPPOSED TO.
> If the PMC cannot reach agreement on something because it put
> in place
> policies that effectively can lead to blocking its own
> ability to take
> action - you have destoyed the PMC.
Let's look at the pieces one at a time, and decide as a community.
> >I am sure that people who have a proven track record of being able to
> >work with others can come to agreement. I am also sure that
> unanimous
> >has to work any time there is a legal issue at stake. Remember PMC
> >does not make technical decisions so there is unlikely to be an undue
> >amount of blocking--and never for frivolent reasons.
>
> The MUST BE zero possibility for blocking. Without that -
> how will the
> PMC every reach closure on a dispute where you dono't have concensus
> because one party who happends to be a PMC member can block
> the decision
> process?
If you are refering to a removal process, then they are excluded
from the vote--it is a clear conflict of interest.
Honestly, the types of changes where unanimous decisions are required
impact the legal status of this community. The only time that we
will have a problem is if one party throws together a proposal, puts
it up for vote, and tries to hammer it through. I *refuse* to be
subject to that kind of bumrushing tactic and expect to be held
legally bound to it.
If the PMC works together to come up with a proposal by a concerted
effort, and all parties are aware of what is in the proposal, then
the voting process is merely a formality. The bottom line is that
the process *does* work in other communities. The only reason why
it wouldn't work in this community is if the PMC members are too
self-serving.
> >PMC is responsible to oversee the legal aspects of this community.
>
> Exactly!
> That is why it cannot be hamstrung with *nice* policies for
> how we think
> the would *should* be. It *must* be structured so that it
> can *always*
> deal with *real* world.
Funny, it is from an existing and functioning TLP that lives in the
real world. They behave like professionals, and look to the overall
good of the XML community--not their respective corporation's good.
It *can* function for us, and it *should* function for us. Those
measures are there to slow down changes that can have a dramatic
impact on our community. We all have to be on the same page.
If I legally have to sign something, I have to be willing to do it.
How can we be the disenting voice and be "forced" to sign something
we disagree with? The types of changes that should require
unanimous PMC vote are:
* Creating and ratifying legal documents, like the charter and
resolution.
* Removing *disruptive/destructive* committers from Avalon in the
unlikely event that we would experience one of them. Another
variation would be removing someone from the PMC--but not from
committer status. In the latter case, the guilty PMC member
would be excluded from the vote due to conflict of interest.
Elections of PMC members are done by nomination and vote. Selection
of the chair should be done by 2/3 majority of the PMC. A chair's
term should be 3 months, where it is up for re-election at that
time--unless the chair resigns before that time, in which case an
emergency election will take place.
In reality there are only two things that I firmly believe we should
have unanimous PMC consensus, and the rest I am inclined to agree
with you.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> >Steve, your fears are duly noted. Keep in mind that it is
> the PMC that
> >must be unanimous--not the general committer populus.
> >
> >
> THAT IS WHAT I AM TOTALLY OPPOSED TO.
> If the PMC cannot reach agreement on something because it put
> in place
> policies that effectively can lead to blocking its own
> ability to take
> action - you have destoyed the PMC.
Let's look at the pieces one at a time, and decide as a community.
> >I am sure that people who have a proven track record of being able to
> >work with others can come to agreement. I am also sure that
> unanimous
> >has to work any time there is a legal issue at stake. Remember PMC
> >does not make technical decisions so there is unlikely to be an undue
> >amount of blocking--and never for frivolent reasons.
>
> The MUST BE zero possibility for blocking. Without that -
> how will the
> PMC every reach closure on a dispute where you dono't have concensus
> because one party who happends to be a PMC member can block
> the decision
> process?
If you are refering to a removal process, then they are excluded
from the vote--it is a clear conflict of interest.
Honestly, the types of changes where unanimous decisions are required
impact the legal status of this community. The only time that we
will have a problem is if one party throws together a proposal, puts
it up for vote, and tries to hammer it through. I *refuse* to be
subject to that kind of bumrushing tactic and expect to be held
legally bound to it.
If the PMC works together to come up with a proposal by a concerted
effort, and all parties are aware of what is in the proposal, then
the voting process is merely a formality. The bottom line is that
the process *does* work in other communities. The only reason why
it wouldn't work in this community is if the PMC members are too
self-serving.
> >PMC is responsible to oversee the legal aspects of this community.
>
> Exactly!
> That is why it cannot be hamstrung with *nice* policies for
> how we think
> the would *should* be. It *must* be structured so that it
> can *always*
> deal with *real* world.
Funny, it is from an existing and functioning TLP that lives in the
real world. They behave like professionals, and look to the overall
good of the XML community--not their respective corporation's good.
It *can* function for us, and it *should* function for us. Those
measures are there to slow down changes that can have a dramatic
impact on our community. We all have to be on the same page.
If I legally have to sign something, I have to be willing to do it.
How can we be the disenting voice and be "forced" to sign something
we disagree with? The types of changes that should require
unanimous PMC vote are:
* Creating and ratifying legal documents, like the charter and
resolution.
* Removing *disruptive/destructive* committers from Avalon in the
unlikely event that we would experience one of them. Another
variation would be removing someone from the PMC--but not from
committer status. In the latter case, the guilty PMC member
would be excluded from the vote due to conflict of interest.
Elections of PMC members are done by nomination and vote. Selection
of the chair should be done by 2/3 majority of the PMC. A chair's
term should be 3 months, where it is up for re-election at that
time--unless the chair resigns before that time, in which case an
emergency election will take place.
In reality there are only two things that I firmly believe we should
have unanimous PMC consensus, and the rest I am inclined to agree
with you.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> >Steve, your fears are duly noted. Keep in mind that it is
> the PMC that
> >must be unanimous--not the general committer populus.
> >
> >
> THAT IS WHAT I AM TOTALLY OPPOSED TO.
> If the PMC cannot reach agreement on something because it put
> in place
> policies that effectively can lead to blocking its own
> ability to take
> action - you have destoyed the PMC.
Let's look at the pieces one at a time, and decide as a community.
> >I am sure that people who have a proven track record of being able to
> >work with others can come to agreement. I am also sure that
> unanimous
> >has to work any time there is a legal issue at stake. Remember PMC
> >does not make technical decisions so there is unlikely to be an undue
> >amount of blocking--and never for frivolent reasons.
>
> The MUST BE zero possibility for blocking. Without that -
> how will the
> PMC every reach closure on a dispute where you dono't have concensus
> because one party who happends to be a PMC member can block
> the decision
> process?
If you are refering to a removal process, then they are excluded
from the vote--it is a clear conflict of interest.
Honestly, the types of changes where unanimous decisions are required
impact the legal status of this community. The only time that we
will have a problem is if one party throws together a proposal, puts
it up for vote, and tries to hammer it through. I *refuse* to be
subject to that kind of bumrushing tactic and expect to be held
legally bound to it.
If the PMC works together to come up with a proposal by a concerted
effort, and all parties are aware of what is in the proposal, then
the voting process is merely a formality. The bottom line is that
the process *does* work in other communities. The only reason why
it wouldn't work in this community is if the PMC members are too
self-serving.
> >PMC is responsible to oversee the legal aspects of this community.
>
> Exactly!
> That is why it cannot be hamstrung with *nice* policies for
> how we think
> the would *should* be. It *must* be structured so that it
> can *always*
> deal with *real* world.
Funny, it is from an existing and functioning TLP that lives in the
real world. They behave like professionals, and look to the overall
good of the XML community--not their respective corporation's good.
It *can* function for us, and it *should* function for us. Those
measures are there to slow down changes that can have a dramatic
impact on our community. We all have to be on the same page.
If I legally have to sign something, I have to be willing to do it.
How can we be the disenting voice and be "forced" to sign something
we disagree with? The types of changes that should require
unanimous PMC vote are:
* Creating and ratifying legal documents, like the charter and
resolution.
* Removing *disruptive/destructive* committers from Avalon in the
unlikely event that we would experience one of them. Another
variation would be removing someone from the PMC--but not from
committer status. In the latter case, the guilty PMC member
would be excluded from the vote due to conflict of interest.
Elections of PMC members are done by nomination and vote. Selection
of the chair should be done by 2/3 majority of the PMC. A chair's
term should be 3 months, where it is up for re-election at that
time--unless the chair resigns before that time, in which case an
emergency election will take place.
In reality there are only two things that I firmly believe we should
have unanimous PMC consensus, and the rest I am inclined to agree
with you.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Wednesday, December 04, 2002 6:16 AM
>>To: Avalon Developers List
>>Subject: Re: Charter.txt
>>
>>
>>
>>
>>Peter Donald wrote:
>>
>>
>>
>>>On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>>>
>>>
>>>
>>>
>>>>Stephen has already made clear his dislike of the word "unanimous",
>>>>but before we blindly remove that word, we need to come to community
>>>>consensus.
>>>>
>>>>
>>>>
>>>>
>>>I am +1 on unanimous because it forces consensus for forward
>>>
>>>
>>motion. It may
>>
>>
>>>mean things take longer to get decided but usually the
>>>
>>>
>>decisions are better
>>
>>
>>>for it.
>>>
>>>
>>>
>>And thereby grant the right to a single individual to block progress.
>>That takes away the ability of the PMC to function. If when you take
>>away it ability to function you have taken away its ability
>>to represent
>>the comunity and its ability to meet its obligations to the board.
>>
>>
>
>Steve, your fears are duly noted. Keep in mind that it is the PMC that
>must be unanimous--not the general committer populus.
>
>
THAT IS WHAT I AM TOTALLY OPPOSED TO.
If the PMC cannot reach agreement on something because it put in place
policies that effectively can lead to blocking its own ability to take
action - you have destoyed the PMC.
>I am sure that people who have a proven track record of being able to
>work with others can come to agreement. I am also sure that unanimous
>has to work any time there is a legal issue at stake. Remember PMC
>does not make technical decisions so there is unlikely to be an undue
>amount of blocking--and never for frivolent reasons.
>
>
The MUST BE zero possibility for blocking. Without that - how will the
PMC every reach closure on a dispute where you dono't have concensus
because one party who happends to be a PMC member can block the decision
process?
>PMC is responsible to oversee the legal aspects of this community.
>
>
Exactly!
That is why it cannot be hamstrung with *nice* policies for how we think
the would *should* be. It *must* be structured so that it can *always*
deal with *real* world.
Cheers, Steve.
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Wednesday, December 04, 2002 6:16 AM
>>To: Avalon Developers List
>>Subject: Re: Charter.txt
>>
>>
>>
>>
>>Peter Donald wrote:
>>
>>
>>
>>>On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>>>
>>>
>>>
>>>
>>>>Stephen has already made clear his dislike of the word "unanimous",
>>>>but before we blindly remove that word, we need to come to community
>>>>consensus.
>>>>
>>>>
>>>>
>>>>
>>>I am +1 on unanimous because it forces consensus for forward
>>>
>>>
>>motion. It may
>>
>>
>>>mean things take longer to get decided but usually the
>>>
>>>
>>decisions are better
>>
>>
>>>for it.
>>>
>>>
>>>
>>And thereby grant the right to a single individual to block progress.
>>That takes away the ability of the PMC to function. If when you take
>>away it ability to function you have taken away its ability
>>to represent
>>the comunity and its ability to meet its obligations to the board.
>>
>>
>
>Steve, your fears are duly noted. Keep in mind that it is the PMC that
>must be unanimous--not the general committer populus.
>
>
THAT IS WHAT I AM TOTALLY OPPOSED TO.
If the PMC cannot reach agreement on something because it put in place
policies that effectively can lead to blocking its own ability to take
action - you have destoyed the PMC.
>I am sure that people who have a proven track record of being able to
>work with others can come to agreement. I am also sure that unanimous
>has to work any time there is a legal issue at stake. Remember PMC
>does not make technical decisions so there is unlikely to be an undue
>amount of blocking--and never for frivolent reasons.
>
>
The MUST BE zero possibility for blocking. Without that - how will the
PMC every reach closure on a dispute where you dono't have concensus
because one party who happends to be a PMC member can block the decision
process?
>PMC is responsible to oversee the legal aspects of this community.
>
>
Exactly!
That is why it cannot be hamstrung with *nice* policies for how we think
the would *should* be. It *must* be structured so that it can *always*
deal with *real* world.
Cheers, Steve.
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Wednesday, December 04, 2002 6:16 AM
>>To: Avalon Developers List
>>Subject: Re: Charter.txt
>>
>>
>>
>>
>>Peter Donald wrote:
>>
>>
>>
>>>On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>>>
>>>
>>>
>>>
>>>>Stephen has already made clear his dislike of the word "unanimous",
>>>>but before we blindly remove that word, we need to come to community
>>>>consensus.
>>>>
>>>>
>>>>
>>>>
>>>I am +1 on unanimous because it forces consensus for forward
>>>
>>>
>>motion. It may
>>
>>
>>>mean things take longer to get decided but usually the
>>>
>>>
>>decisions are better
>>
>>
>>>for it.
>>>
>>>
>>>
>>And thereby grant the right to a single individual to block progress.
>>That takes away the ability of the PMC to function. If when you take
>>away it ability to function you have taken away its ability
>>to represent
>>the comunity and its ability to meet its obligations to the board.
>>
>>
>
>Steve, your fears are duly noted. Keep in mind that it is the PMC that
>must be unanimous--not the general committer populus.
>
>
THAT IS WHAT I AM TOTALLY OPPOSED TO.
If the PMC cannot reach agreement on something because it put in place
policies that effectively can lead to blocking its own ability to take
action - you have destoyed the PMC.
>I am sure that people who have a proven track record of being able to
>work with others can come to agreement. I am also sure that unanimous
>has to work any time there is a legal issue at stake. Remember PMC
>does not make technical decisions so there is unlikely to be an undue
>amount of blocking--and never for frivolent reasons.
>
>
The MUST BE zero possibility for blocking. Without that - how will the
PMC every reach closure on a dispute where you dono't have concensus
because one party who happends to be a PMC member can block the decision
process?
>PMC is responsible to oversee the legal aspects of this community.
>
>
Exactly!
That is why it cannot be hamstrung with *nice* policies for how we think
the would *should* be. It *must* be structured so that it can *always*
deal with *real* world.
Cheers, Steve.
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, December 04, 2002 6:16 AM
> To: Avalon Developers List
> Subject: Re: Charter.txt
>
>
>
>
> Peter Donald wrote:
>
> >On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> >
> >
> >>Stephen has already made clear his dislike of the word "unanimous",
> >>but before we blindly remove that word, we need to come to community
> >>consensus.
> >>
> >>
> >
> >I am +1 on unanimous because it forces consensus for forward
> motion. It may
> >mean things take longer to get decided but usually the
> decisions are better
> >for it.
> >
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability
> to represent
> the comunity and its ability to meet its obligations to the board.
Steve, your fears are duly noted. Keep in mind that it is the PMC that
must be unanimous--not the general committer populus.
I am sure that people who have a proven track record of being able to
work with others can come to agreement. I am also sure that unanimous
has to work any time there is a legal issue at stake. Remember PMC
does not make technical decisions so there is unlikely to be an undue
amount of blocking--and never for frivolent reasons.
PMC is responsible to oversee the legal aspects of this community.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, December 04, 2002 6:16 AM
> To: Avalon Developers List
> Subject: Re: Charter.txt
>
>
>
>
> Peter Donald wrote:
>
> >On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> >
> >
> >>Stephen has already made clear his dislike of the word "unanimous",
> >>but before we blindly remove that word, we need to come to community
> >>consensus.
> >>
> >>
> >
> >I am +1 on unanimous because it forces consensus for forward
> motion. It may
> >mean things take longer to get decided but usually the
> decisions are better
> >for it.
> >
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability
> to represent
> the comunity and its ability to meet its obligations to the board.
Steve, your fears are duly noted. Keep in mind that it is the PMC that
must be unanimous--not the general committer populus.
I am sure that people who have a proven track record of being able to
work with others can come to agreement. I am also sure that unanimous
has to work any time there is a legal issue at stake. Remember PMC
does not make technical decisions so there is unlikely to be an undue
amount of blocking--and never for frivolent reasons.
PMC is responsible to oversee the legal aspects of this community.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, December 04, 2002 6:16 AM
> To: Avalon Developers List
> Subject: Re: Charter.txt
>
>
>
>
> Peter Donald wrote:
>
> >On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> >
> >
> >>Stephen has already made clear his dislike of the word "unanimous",
> >>but before we blindly remove that word, we need to come to community
> >>consensus.
> >>
> >>
> >
> >I am +1 on unanimous because it forces consensus for forward
> motion. It may
> >mean things take longer to get decided but usually the
> decisions are better
> >for it.
> >
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability
> to represent
> the comunity and its ability to meet its obligations to the board.
Steve, your fears are duly noted. Keep in mind that it is the PMC that
must be unanimous--not the general committer populus.
I am sure that people who have a proven track record of being able to
work with others can come to agreement. I am also sure that unanimous
has to work any time there is a legal issue at stake. Remember PMC
does not make technical decisions so there is unlikely to be an undue
amount of blocking--and never for frivolent reasons.
PMC is responsible to oversee the legal aspects of this community.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> And thereby grant the right to a single individual to block progress.
> That takes away the ability of the PMC to function. If when you take
> away it ability to function you have taken away its ability
> to represent the comunity and its ability to meet its obligations
> to the board.
1) That's the downside of concensus-based development.
2) If the person is "disruptive" he can be kicked out.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>
>
>>Stephen has already made clear his dislike of the word "unanimous",
>>but before we blindly remove that word, we need to come to community
>>consensus.
>>
>>
>
>I am +1 on unanimous because it forces consensus for forward motion. It may
>mean things take longer to get decided but usually the decisions are better
>for it.
>
And thereby grant the right to a single individual to block progress.
That takes away the ability of the PMC to function. If when you take
away it ability to function you have taken away its ability to represent
the comunity and its ability to meet its obligations to the board.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>
>
>>Stephen has already made clear his dislike of the word "unanimous",
>>but before we blindly remove that word, we need to come to community
>>consensus.
>>
>>
>
>I am +1 on unanimous because it forces consensus for forward motion. It may
>mean things take longer to get decided but usually the decisions are better
>for it.
>
And thereby grant the right to a single individual to block progress.
That takes away the ability of the PMC to function. If when you take
away it ability to function you have taken away its ability to represent
the comunity and its ability to meet its obligations to the board.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
>
>
>>Stephen has already made clear his dislike of the word "unanimous",
>>but before we blindly remove that word, we need to come to community
>>consensus.
>>
>>
>
>I am +1 on unanimous because it forces consensus for forward motion. It may
>mean things take longer to get decided but usually the decisions are better
>for it.
>
And thereby grant the right to a single individual to block progress.
That takes away the ability of the PMC to function. If when you take
away it ability to function you have taken away its ability to represent
the comunity and its ability to meet its obligations to the board.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> Stephen has already made clear his dislike of the word "unanimous",
> but before we blindly remove that word, we need to come to community
> consensus.
I am +1 on unanimous because it forces consensus for forward motion. It may
mean things take longer to get decided but usually the decisions are better
for it.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> Stephen has already made clear his dislike of the word "unanimous",
> but before we blindly remove that word, we need to come to community
> consensus.
I am +1 on unanimous because it forces consensus for forward motion. It may
mean things take longer to get decided but usually the decisions are better
for it.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: What does 'consensus' really mean? [was Re: Charter.txt]
Posted by David Weitzman <da...@optonline.net>.
David Weitzman wrote:
> This is somewhat off the topic of software development though, so I'll
shut
> up for now ;)
I've started a small wiki page at
http://c2.com/cgi/wiki?OpenSourceManagement where general open source
management issues can be discussed. Maybe someone in Avalon has a
reflection to insert. Whatever. The mailing list is busy enough without my
help (you've had at least one casualty already!). In fact, I mentioned
confused mailing lists in the little content that there is on the wiki.
Anyway, I'll pop back into lurker mode now.
David Weitzman
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: What does 'consensus' really mean? [was Re: Charter.txt]
Posted by David Weitzman <da...@optonline.net>.
Leo Sutic wrote:
> excellent message. I have thought about the interest/position
> problem and basically reached the conclusion that a group
> where people can't be open about their interests as opposed
> to their positions is pretty much doomed to not working.
That's quite a sharp observation -- you've stumbled upon the negotiator's
dillemma. The idea is that some people cannot, often for quite valid
reasons, be completely honest about their interests. The 'natural' event
when two random people are negotiating is that each one will fear exposing
his interests. For example, here's one interest that a person might not
voice: "I wasn't so happy about the @author proposal -- I've worked
extremely hard I feel I deserve recognition for it." To say such a thing
might sound selfish.
Here's a better example, though. Bob wants to buy something from Joe. Bob
thinks it looks like $50 dollars worth of gadget, Joe knows that it's only
really worth $39.95.
Bob: How much does it cost?
Joe: How much will you pay for it?
Bob: Hmmm. $50 dollars
Joe could leave it at that and be quite happy, but he thinks he can get more
out of this sucker
Joe: Are you trying to con me? It worth at *least* 65
Bob: $58
Joe: Ok
In this situation, both 'players' are trying to hide their intial interests
because they don't want to be manhandled. What do they really want? Bob
wants to buy a trinket and Joe wants to sell one. Joe, unfortunately, knows
some key information (the actuall price) and is well aware of the advantage
that he has from the start. Both players end up 'claiming value' -- trying
to get as much as they can, rather than achieving a mutually acceptable
compromise.
That's why mediation works so well. All parties can trust a mediator with
confidential information and he can use it to move the discussion towards
the mutual gain outcome.
http://www.colorado.edu/conflict/peace/treatment/lax7543.htm
I'm going to try to find my photocopied version of Lax and Sebenius's
article on the Negotiator's Dillemma. It can never hurt to read it another
time.
I think the problem can be solved if everyone is committed to acheiving the
best possible outcome, and if everyone is receptive to the subtle hints of
interest behind every position -- does that position belong with a new
interest you haven't discussed before?
Any way, I'm off now.
David Weitzman
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: What does 'consensus' really mean? [was Re: Charter.txt]
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
>>From: David Weitzman [mailto:daveweit@optonline.net]
>>
>>**Interests vs. Positions**
>>Bob's position (a suggestion course of action or judgment):
>>Steady development of Phoenix must continue!
>>
>>Bob's interest:
>>What I really want is for my legacy code to continue working
>
>
> David,
>
> excellent message. I have thought about the interest/position
> problem and basically reached the conclusion that a group
> where people can't be open about their interests as opposed
> to their positions is pretty much doomed to not working.
Bingo.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: What does 'consensus' really mean? [was Re: Charter.txt]
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: David Weitzman [mailto:daveweit@optonline.net]
>
> **Interests vs. Positions**
> Bob's position (a suggestion course of action or judgment):
> Steady development of Phoenix must continue!
>
> Bob's interest:
> What I really want is for my legacy code to continue working
David,
excellent message. I have thought about the interest/position
problem and basically reached the conclusion that a group
where people can't be open about their interests as opposed
to their positions is pretty much doomed to not working.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: What does 'consensus' really mean? [was Re: Charter.txt]
Posted by "Noel J. Bergman" <no...@devtech.com>.
> This is somewhat off the topic of software development
> though, so I'll shut up for now ;)
Actually, it was a nice message, and quite germaine for community developed
software. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
What does 'consensus' really mean? [was Re: Charter.txt]
Posted by David Weitzman <da...@optonline.net>.
Berin Loritsch wrote:
> we need to come to community consensus.
Everyone else wrote:
> Blah di blah! We aren't capable of reaching consensus! It'll all end in
tears!
For me the word consensus means a bit more than it does for many people. I
took a course this summer out of an urban and regional planning department
about conflict resolution -- negotiation and mediation. It was very
enlightening. You might want to try reading something by Lawrence Susskind
(http://web.mit.edu/publicdisputes/) or browsing around Google
(http://directory.google.com/Top/Society/Law/Organizations/Alternative_Dispu
te_Resolution/?tc=1 and similar).
It turns out that consensus building is not quite as straightforward as it
seems, but can be extremely effective when implemented properly. On the
other hand, some methods of 'consensus building' really just lead to more
unpleasantness.
>From what I've read, I'm somewhat suspicious of the notion that everything
can be worked out in a semi-informal way by majority vote. There are some
big issues on the table. It would be interesting if Apache started a
mediation committee of neutral facilitators, but I don't expect such a thing
to actually happen (it'd be extremely cool though, and might prove to be a
tremendous asset given the current changing state of things).
There's actually quite a lot of interesting stuff involved in consensus
building, but I don't really know the internet sources. Here is just one
example of the sort of things people need to think about.
**Interests vs. Positions**
Bob's position (a suggestion course of action or judgment): Steady
development of Phoenix must continue!
Bob's interest: What I really want is for my legacy code to continue working
John Smith suggests: What if the uber-container was completely Phoenix
compatible from the start? Trying to implement several forms of
compatibility might even help us to maintain a modular code structure with
healthy abstraction.
Bob's response: I guess that would work out, but what about issues A, B, and
C (i.e. short term before uber-container is ready for production)?
(at this point everyone discusses how A, B, and C might be addressed, etc.
A, B, and C should probably be related to a clearly identified interest, but
such procedural policies are specified in the 'ground rules')
It's really important to distinguish interests from positions.
**end example**
There are a lot of sound principles, like 'ground rules' (discussion happens
in an organized and respectful fashion, etc. Ideally the community agrees
on ground rules together), 'joint-gains' (everything doesn't have to be all
or nothing at all -- be creative and look for solutions that don't ignore
anyone's concerns) and a bunch of other cool stuff. Not only that, the
principles are not just abstract speculation -- they've been proven to work
time and time again.
This is somewhat off the topic of software development though, so I'll shut
up for now ;)
Dave
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote:
> Stephen has already made clear his dislike of the word "unanimous",
> but before we blindly remove that word, we need to come to community
> consensus.
I am +1 on unanimous because it forces consensus for forward motion. It may
mean things take longer to get decided but usually the decisions are better
for it.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Noel J. Bergman wrote:
>
>>> Looking at the three proposals, can we take pieces from all?
>>> * Auto PMC membership for committers who have been active for
>>> at least six months.
>>> * Charter and Bylaw voting time period is a week
>>> * A motion passes with 2/3 majority vote of quorum
>>> * In the event that quorum cannot be met, voting remains open
>>> until quorum is met.
>>> * Size of quorum shall be [insert your percentage here], with
>>> a floor of 3 people (i.e. if percentage of PMC is less than
>>> three, then Quorum is still 3)
>>
>>
>>
>> So basically, the three variables are:
>>
>> 1) Minimum period within which to count votes [1 week]
>> 2) The definition of a quorum (3+, 33%, 50%) [ ? ]
>> 3) Percentage required to carry the vote [ 66% ]
>>
>> Is that correct?
>
>
> That's what I am thinking. The 3+ is an absolute minimum. I.e.
> if Quorum is 33% and there are only 6 PMC members, quorum is still
> 3 (i.e. 50% of the PMC). As the PMC grows to something like 21,
> 33% is 7, so that is used instead of the 3.
>
> I personally would prefer 50% Quorum to have better representation,
> but I am not going to obstruct something else. (I think that 33%
> should be considered an absolute minimum percentage).
Berin:
Quick check - aside from the question of what is legally binding,
do you see the following two as viable (assuming a minimum voting
period of one week):
Case Quorum Majority
1. 50% 50%
2. 33% 66%
> Also, as with most communities using quorum (including home owners
> associations) there is the idea of a rolling time period. I.e.
> voting remains open as long as necessary to reach quorum--even if
> it exceeds the 1 week period.
I think you have to cap this. You can easily end up with several rolling
votes that get lost in the time. I would prefer no rolling extension,
instead, its up to the individial to re-raise the issue in the light of
the fact that the membership was unwilling to express its opinion.
Cheers, Steve.
>
>
> ---------------------------------------------
> Introducing NetZero Long Distance
> 1st month Free!
> Sign up today at: www.netzerolongdistance.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Berin Loritsch <bl...@apache.org>.
Noel J. Bergman wrote:
>>Looking at the three proposals, can we take pieces from all?
>>* Auto PMC membership for committers who have been active for
>> at least six months.
>>* Charter and Bylaw voting time period is a week
>>* A motion passes with 2/3 majority vote of quorum
>>* In the event that quorum cannot be met, voting remains open
>> until quorum is met.
>>* Size of quorum shall be [insert your percentage here], with
>> a floor of 3 people (i.e. if percentage of PMC is less than
>> three, then Quorum is still 3)
>
>
> So basically, the three variables are:
>
> 1) Minimum period within which to count votes [1 week]
> 2) The definition of a quorum (3+, 33%, 50%) [ ? ]
> 3) Percentage required to carry the vote [ 66% ]
>
> Is that correct?
That's what I am thinking. The 3+ is an absolute minimum. I.e.
if Quorum is 33% and there are only 6 PMC members, quorum is still
3 (i.e. 50% of the PMC). As the PMC grows to something like 21,
33% is 7, so that is used instead of the 3.
I personally would prefer 50% Quorum to have better representation,
but I am not going to obstruct something else. (I think that 33%
should be considered an absolute minimum percentage).
Also, as with most communities using quorum (including home owners
associations) there is the idea of a rolling time period. I.e.
voting remains open as long as necessary to reach quorum--even if
it exceeds the 1 week period.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>> 1) Minimum period within which to count votes [1 week]
>>>
>>>
>
>Please note that my [1 week] was a shorthand for what I saw as the
>suggestion from Berin, not my own. Although I think that a week is a
>reasonable value.
>
>
I think its reasonable as well. It is clear that the 72 duration,
although 100% ligitamate, was considered by many as too short. A week
duration effectively takes this to 168 hours.
>
>
>>Berin mentioned extension of the period if quorum has not been met.
>>If such a notion is introduced we must also have a cut-off point
>>where a motion fails because quorum was not met (e.g. three weeks).
>>I would also be happy with no extension semantics.
>>
>>
>
>Either one works for me.
>
>
>
>>> 2) The definition of a quorum (3+, 33%, 50%) [ ? ]
>>>
>>>
>>This one (for me) is strong influenced by two factors
>>
>>
>
>I think that it makes sense that if the idea of elections is dropped in
>favor of allowing any active and interested Committer to be a PMC member,
>you might incorporate your notion of a Committer having to ask to be on the
>PMC, and having to renew the request per period (6 months to a year).
>
>
This is functionally equivalent to the notion of periodic elections - so
yep it works for me because it ensures engagement.
>Given that, you should have an engaged PMC, and should be able to stick with
>the 50% quorum. If someone else wants a lower standard, let them propose
>it.
>
>
>
>>> 3) Percentage required to carry the vote [ 66% ]
>>>
>>>
>
>Again, the 66% was my shorthand for Berin's apparent suggestion. I'd go
>with a simple majority (and a 50% quorum).
>
I agree - given a 50% quorum I would prefer to see simple majority.
However, there should the identification of cases requiring 2/3
majority - for example, the modification of the charter or the
established policies and procedures.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 1) Minimum period within which to count votes [1 week]
Please note that my [1 week] was a shorthand for what I saw as the
suggestion from Berin, not my own. Although I think that a week is a
reasonable value.
> Berin mentioned extension of the period if quorum has not been met.
> If such a notion is introduced we must also have a cut-off point
> where a motion fails because quorum was not met (e.g. three weeks).
> I would also be happy with no extension semantics.
Either one works for me.
> > 2) The definition of a quorum (3+, 33%, 50%) [ ? ]
> This one (for me) is strong influenced by two factors
I think that it makes sense that if the idea of elections is dropped in
favor of allowing any active and interested Committer to be a PMC member,
you might incorporate your notion of a Committer having to ask to be on the
PMC, and having to renew the request per period (6 months to a year).
Given that, you should have an engaged PMC, and should be able to stick with
the 50% quorum. If someone else wants a lower standard, let them propose
it.
> > 3) Percentage required to carry the vote [ 66% ]
Again, the 66% was my shorthand for Berin's apparent suggestion. I'd go
with a simple majority (and a 50% quorum).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Looking at the three proposals, can we take pieces from all?
>>* Auto PMC membership for committers who have been active for
>> at least six months.
>>* Charter and Bylaw voting time period is a week
>>* A motion passes with 2/3 majority vote of quorum
>>* In the event that quorum cannot be met, voting remains open
>> until quorum is met.
>>* Size of quorum shall be [insert your percentage here], with
>> a floor of 3 people (i.e. if percentage of PMC is less than
>> three, then Quorum is still 3)
>>
>>
>
>So basically, the three variables are:
>
> 1) Minimum period within which to count votes [1 week]
>
Berin mentioned extension of the period if quorum has not been met. If
such a notion is introduced we must also have a cut-off point where a
motion fails because quorum was not met (e.g. three weeks). I would
also be happy with no extension semantics.
> 2) The definition of a quorum (3+, 33%, 50%) [ ? ]
>
This one (for me) is strong influenced by two factors - firstly
legality. When the PMC votes it is taken decisions that are binding on
the board. The second factor is engagement - if we have an auto
membership model then quorum must be low. If we have active opt-in than
quorum needs to relative to majority.
>
> 3) Percentage required to carry the vote [ 66% ]
>
Percentage is linked to quorum. With a higher majority, the balance is a
lower quorum. The quorum question should be validated in terms of
legality with respect to the binding nature of the PMC decisions.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Looking at the three proposals, can we take pieces from all?
> * Auto PMC membership for committers who have been active for
> at least six months.
> * Charter and Bylaw voting time period is a week
> * A motion passes with 2/3 majority vote of quorum
> * In the event that quorum cannot be met, voting remains open
> until quorum is met.
> * Size of quorum shall be [insert your percentage here], with
> a floor of 3 people (i.e. if percentage of PMC is less than
> three, then Quorum is still 3)
So basically, the three variables are:
1) Minimum period within which to count votes [1 week]
2) The definition of a quorum (3+, 33%, 50%) [ ? ]
3) Percentage required to carry the vote [ 66% ]
Is that correct?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>On Sat, 2002-12-07 at 10:13, Stephen McConnell wrote:
>
>
>>>For the week please. People might change their vote if lobbied /
>>>persuaded.
>>>
>>>
>>This has already been churned over - the conclusion was the introduction
>>of a extension period of one week if the initial vote does not meet
>>quorum. Here is the extract of the details concerning vote duration that
>>address this point.
>>
>> (f) Vote Duration
>>
>> Any vote conducted by the PMC may be closed within 7 days of its
>> initiation providing that quorum has been met in accordance with
>> Article 1 (b). A vote not meeting quorum during the initial 7
>> day period shall default to a 14 day duration. On expiration of
>> a 14 day vote duration, if quorum has not been achieved, the
>> vote shall be consider as a failed vote.
>>
>>The desire is to ensure we don't have long running votes, but ensure
>>adequate time for participation.
>>
>>
>
>Steve, I don't think you get what Paul means. Paul's diff IIUC is:
>
>< Any vote conducted by the PMC may be closed within 7 days of its
>
>
>> Any vote conducted by the PMC may be closed 7 days after its
>>
>>
>
>ie don't close votes _within_ a week but _after_ a week.
>
>sounds okay to me.
>
>
Here is a version including the "after" keyword:
(f) Vote Duration
Any vote conducted by the PMC may be closed after 7 days following
initiation providing that quorum has been met in accordance with
Article 1 (b). A vote not meeting quorum during the initial 7
day period shall default to a 14 day duration. On expiration of
a 14 day vote duration, if quorum has not been achieved, the
vote shall be consider as a failed vote.
I've already added this change to the CVS version.
Cheers, Steve.
>cheers,
>
>- Leo
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Leo Simons <le...@apache.org>.
On Sat, 2002-12-07 at 10:13, Stephen McConnell wrote:
> > For the week please. People might change their vote if lobbied /
> > persuaded.
>
>
> This has already been churned over - the conclusion was the introduction
> of a extension period of one week if the initial vote does not meet
> quorum. Here is the extract of the details concerning vote duration that
> address this point.
>
> (f) Vote Duration
>
> Any vote conducted by the PMC may be closed within 7 days of its
> initiation providing that quorum has been met in accordance with
> Article 1 (b). A vote not meeting quorum during the initial 7
> day period shall default to a 14 day duration. On expiration of
> a 14 day vote duration, if quorum has not been achieved, the
> vote shall be consider as a failed vote.
>
> The desire is to ensure we don't have long running votes, but ensure
> adequate time for participation.
Steve, I don't think you get what Paul means. Paul's diff IIUC is:
< Any vote conducted by the PMC may be closed within 7 days of its
> Any vote conducted by the PMC may be closed 7 days after its
ie don't close votes _within_ a week but _after_ a week.
sounds okay to me.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen
>> I'll stand by my request to keep the minimum period to a week.
>
>
>
> The minimum period is one week (a.k.a. 7 days)!
The text makes it look like if quorum is reached inside the seven day
period, then seven days can be cut short.
>> As such I -1 (vote) the charter.
>
>
>
> Well - its not actually under vote at this stage.
>
> ;-)
I forward lodge my -1, just I canse I blink and miss the vote (again).
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>>>> * In the event that quorum cannot be met, voting remains open
>>>>> until quorum is met.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> +1
>>>
>>>
>>>
>>>
>>> For the week please. People might change their vote if lobbied /
>>> persuaded.
>>
>>
>>
>>
>> This has already been churned over - the conclusion was the
>> introduction of a extension period of one week if the initial vote
>> does not meet quorum. Here is the extract of the details concerning
>> vote duration that address this point.
>>
>> (f) Vote Duration
>>
>> Any vote conducted by the PMC may be closed within 7 days of its
>> initiation providing that quorum has been met in accordance with
>> Article 1 (b). A vote not meeting quorum during the initial 7
>> day period shall default to a 14 day duration. On expiration of
>> a 14 day vote duration, if quorum has not been achieved, the
>> vote shall be consider as a failed vote.
>>
>> The desire is to ensure we don't have long running votes, but ensure
>> adequate time for participation.
>
>
> I'll stand by my request to keep the minimum period to a week.
The minimum period is one week (a.k.a. 7 days)!
>
> As such I -1 (vote) the charter.
Well - its not actually under vote at this stage.
;-)
Cheers, Steve.
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>>> * In the event that quorum cannot be met, voting remains open
>>>> until quorum is met.
>>>
>>>
>>>
>>>
>>> +1
>>
>>
>>
>> For the week please. People might change their vote if lobbied /
>> persuaded.
>
>
>
> This has already been churned over - the conclusion was the
> introduction of a extension period of one week if the initial vote
> does not meet quorum. Here is the extract of the details concerning
> vote duration that address this point.
>
> (f) Vote Duration
>
> Any vote conducted by the PMC may be closed within 7 days of its
> initiation providing that quorum has been met in accordance with
> Article 1 (b). A vote not meeting quorum during the initial 7
> day period shall default to a 14 day duration. On expiration of
> a 14 day vote duration, if quorum has not been achieved, the
> vote shall be consider as a failed vote.
>
> The desire is to ensure we don't have long running votes, but ensure
> adequate time for participation.
I'll stand by my request to keep the minimum period to a week.
As such I -1 (vote) the charter.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>> * In the event that quorum cannot be met, voting remains open
>>> until quorum is met.
>>
>>
>>
>> +1
>
>
> For the week please. People might change their vote if lobbied /
> persuaded.
This has already been churned over - the conclusion was the introduction
of a extension period of one week if the initial vote does not meet
quorum. Here is the extract of the details concerning vote duration that
address this point.
(f) Vote Duration
Any vote conducted by the PMC may be closed within 7 days of its
initiation providing that quorum has been met in accordance with
Article 1 (b). A vote not meeting quorum during the initial 7
day period shall default to a 14 day duration. On expiration of
a 14 day vote duration, if quorum has not been achieved, the
vote shall be consider as a failed vote.
The desire is to ensure we don't have long running votes, but ensure
adequate time for participation.
Cheers, Steve.
>
> -ph
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>> * In the event that quorum cannot be met, voting remains open
>> until quorum is met.
>
>
> +1
For the week please. People might change their vote if lobbied / persuaded.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Berin Loritsch wrote:
>
>> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>> Berin Loritsch wrote:
>>
>> [...]
>
>
>>>> * Projects that depend on Avalon have the ability to nominate
>>>> one representative each to the PMC.
>>>
>>>
>>> The idea is nice, but don't think it would scale. If 40 projects
>>> start depending on Avalon? And depending on which grounds?
>>> I repeat, I like the idea, let's see if we can make this thing into
>>> something.
>>
>>
>> The idea is to provide a mechanism where other projects can have
>> representation. Perhaps we can limit the elegible projects to
>> those who have a minimum number of active committers? I.e. if
>> it has a healthy community like JAMES or Cocoon, they should be
>> eligible to have representation. If it is a one man project
>> or a two-three man project, then they should be involved as
>> individuals.
>
>
> Hmmm... if representation is about making themselves heard they
> already do it on the mailing lists. But I think you are talking about
> full voting rights in the PMS, and I like the idea of having this kind
> of concrete representation.
>
> In many states there are two parliamentary branches, and in some one
> is about regions/states. What about having an Avalon uoter-project PMC
> branch... hmmm, mind me, I'm really dumping my thoughts here, I like
> the idea and wabt to find a solution...
>
> Ir simply stating that a certain % of the PMC is voted regularly by
> Avalon-using projects by voting people that are not necessarily Avalon
> committers.
>
> IE every year the committers of projects that the Avalon PMC decides
> are part of the voting can vote let's say 20% of the PMC from people
> that are not necessarily part of the Avalon community.
Its easy - give the standing chair discression.
>
>>> I'd also like to see the chair nominated by all the committers, not
>>> only the PMC. This would make the PMC truly representative of the
>>> community while keeping the entrance by invitation to the PMC.
>>
>>
>>
>> Ok. How about this for the chair position:
>>
>> * Any of the PMC members are eligible for the chair position.
>
>
> ok.
Qualification requested:
* any of the proposed PMC members are elegible for the chair position
* or, following election of the PMC members, the new PMC alects
the new chair (this feels like the best option to me) - chair
handlover occurs at the next board meeting
>
>
>> * The community decides which of the PMC members are nominated
>> to the position.
>
>
> community as in all mailing list subscribers? ok.
Disagree - I think the chair should be elected by the PMC.
>
>> * The PMC makes the final vote on the Chair based on the
>> nominated individuals.
>
>
> I'd say the committers all, not only the PMC. The Chair, like a
> "president", should represent all the community, not only the PMC.
> Hence all can suggest the name and committers can thus "partecipate"
> in the PMC by taking bart in the Chair votes.
Ok, I like the principal - but if your going to go down this route -
then seperate PMC memberhip elections from chair election. Get the PMC
names established first, maybe let the PMC shortlist 3 candidates, then
give the community the final oiption.
>
>
>> * The chair position will be up for revote every 3 months.
>
>
> I'd say at least 6, preferably more. One year is too much, but having
> four chairs per year seems too much for me.
> Give the chair time at least to give a couple of reports to the board.
I'm ok with 6-12 months - preferabley linke to the PMC rotation.
>
>
> There is a possible issue though... the Chair now is appointed by the
> board, how can this be done? Should the board vote on this every time
> we change the chair? Hmmm...
Yep.
The standing chair stays in place until the next board meeting and his
parting obligation is to annouce his/her resignation and the nomination
of the new chair.
>
>> NOTE: I don't want to impose any limitation on the number
>> of consecutive terms a chair can serve.
>
>
> I agree.
>
Dito.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Berin Loritsch wrote:
>
> [...]
>>>* Projects that depend on Avalon have the ability to nominate
>>> one representative each to the PMC.
>>
>>The idea is nice, but don't think it would scale. If 40
>>projects start
>>depending on Avalon? And depending on which grounds?
>>I repeat, I like the idea, let's see if we can make this thing into
>>something.
>
> The idea is to provide a mechanism where other projects can have
> representation. Perhaps we can limit the elegible projects to
> those who have a minimum number of active committers? I.e. if
> it has a healthy community like JAMES or Cocoon, they should be
> eligible to have representation. If it is a one man project
> or a two-three man project, then they should be involved as
> individuals.
Hmmm... if representation is about making themselves heard they already
do it on the mailing lists. But I think you are talking about full
voting rights in the PMS, and I like the idea of having this kind of
concrete representation.
In many states there are two parliamentary branches, and in some one is
about regions/states. What about having an Avalon uoter-project PMC
branch... hmmm, mind me, I'm really dumping my thoughts here, I like the
idea and wabt to find a solution...
Ir simply stating that a certain % of the PMC is voted regularly by
Avalon-using projects by voting people that are not necessarily Avalon
committers.
IE every year the committers of projects that the Avalon PMC decides are
part of the voting can vote let's say 20% of the PMC from people that
are not necessarily part of the Avalon community.
>>I'd also like to see the chair nominated by all the
>>committers, not only
>>the PMC. This would make the PMC truly representative of the
>>community
>>while keeping the entrance by invitation to the PMC.
>
>
> Ok. How about this for the chair position:
>
> * Any of the PMC members are eligible for the chair position.
ok.
> * The community decides which of the PMC members are nominated
> to the position.
community as in all mailing list subscribers? ok.
> * The PMC makes the final vote on the Chair based on the
> nominated individuals.
I'd say the committers all, not only the PMC. The Chair, like a
"president", should represent all the community, not only the PMC. Hence
all can suggest the name and committers can thus "partecipate" in the
PMC by taking bart in the Chair votes.
> * The chair position will be up for revote every 3 months.
I'd say at least 6, preferably more. One year is too much, but having
four chairs per year seems too much for me.
Give the chair time at least to give a couple of reports to the board.
There is a possible issue though... the Chair now is appointed by the
board, how can this be done? Should the board vote on this every time we
change the chair? Hmmm...
> NOTE: I don't want to impose any limitation on the number
> of consecutive terms a chair can serve.
I agree.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Berin Loritsch wrote:
>
> [...]
>
> > it looks like we should stick
> > as close to the board pattern as possible. So it looks best for:
> >
> > * Strict majority ( > 50% ) with a quorum of 50% of the PMC. I
> > honestly like something to win with more than 51% because in my
> > opinion if the resolution can be written better it will win by
> > more. Nevertheless, this is representative enough of the
> > community that I will not resist it as long as point number 2
> > is accepted.
> >
> > * PMC votes are open for a minimum of one week.
> >
> > * If quorum cannot be met within one week, voting remains open
> > until quorum is met. Should we have a time limit on this? For
> > example, if an issue is on the table for a year, and quorum
> > has not been made yet on an issue it makes little sense to
> > keep it on the table.
>
> IMHO if the quorum cannot be met in, let's say 2-3 weeks, we
> should have
> it dropped automatically.
> Imagine that after 5 months someone issues a +1 and we reach
> the quorum,
> but in the meantime conditions have changed...
Agreed. If we accept the voting extension point, then it should
be capped at two (2) weeks. Otherwise if quorum has not been meet,
the issue is considered to have failed. It can be re-raised at
a later time. (After all they might have put it up for vote right
around the Christmas/New Years time period when a lot of people
might be missing).
> > * PMC members are nominated by the community, and voted in by
> > the existing PMC. Do we have minimum qualifications? I.e.
> > should the PMC members be active committers in the community
> > for six months?
>
> IMHO PMC members are to be invited in as committers are, with
> a similar
> qualification system.
Ok. Sounds good.
> > * Projects that depend on Avalon have the ability to nominate
> > one representative each to the PMC.
>
> The idea is nice, but don't think it would scale. If 40
> projects start
> depending on Avalon? And depending on which grounds?
> I repeat, I like the idea, let's see if we can make this thing into
> something.
The idea is to provide a mechanism where other projects can have
representation. Perhaps we can limit the elegible projects to
those who have a minimum number of active committers? I.e. if
it has a healthy community like JAMES or Cocoon, they should be
eligible to have representation. If it is a one man project
or a two-three man project, then they should be involved as
individuals.
>
> I'd also like to see the chair nominated by all the
> committers, not only
> the PMC. This would make the PMC truly representative of the
> community
> while keeping the entrance by invitation to the PMC.
Ok. How about this for the chair position:
* Any of the PMC members are eligible for the chair position.
* The community decides which of the PMC members are nominated
to the position.
* The PMC makes the final vote on the Chair based on the
nominated individuals.
* The chair position will be up for revote every 3 months.
NOTE: I don't want to impose any limitation on the number
of consecutive terms a chair can serve. If someone is
doing a good job and acting responsibly in the position,
then why mess with a good thing? I.e. if Nicola proves
himself to be nonpartial and really a benefit to the
community in this position I would vote for him again.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
[...]
> it looks like we should stick
> as close to the board pattern as possible. So it looks best for:
>
> * Strict majority ( > 50% ) with a quorum of 50% of the PMC. I
> honestly like something to win with more than 51% because in my
> opinion if the resolution can be written better it will win by
> more. Nevertheless, this is representative enough of the
> community that I will not resist it as long as point number 2
> is accepted.
>
> * PMC votes are open for a minimum of one week.
>
> * If quorum cannot be met within one week, voting remains open
> until quorum is met. Should we have a time limit on this? For
> example, if an issue is on the table for a year, and quorum
> has not been made yet on an issue it makes little sense to
> keep it on the table.
IMHO if the quorum cannot be met in, let's say 2-3 weeks, we should have
it dropped automatically.
Imagine that after 5 months someone issues a +1 and we reach the quorum,
but in the meantime conditions have changed...
> * PMC members are nominated by the community, and voted in by
> the existing PMC. Do we have minimum qualifications? I.e.
> should the PMC members be active committers in the community
> for six months?
IMHO PMC members are to be invited in as committers are, with a similar
qualification system.
> * Projects that depend on Avalon have the ability to nominate
> one representative each to the PMC.
The idea is nice, but don't think it would scale. If 40 projects start
depending on Avalon? And depending on which grounds?
I repeat, I like the idea, let's see if we can make this thing into
something.
I'd also like to see the chair nominated by all the committers, not only
the PMC. This would make the PMC truly representative of the community
while keeping the entrance by invitation to the PMC.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >>> Back to the discussion on procedures for the PMC. Based on the
> >>> emails so far, it seems to me that there are a three
> proposals that
> >>> meet both our objectives.
> >>>
> >>> Noel has suggested a majority voting process that is based on
> >>> the Board process that includes the notion of quorum based on
> >>> Apache bylaws Section 5.8. Quorum and Voting (i.e. 50% of
> >>> PMC members).
> >>>
> >>> You have also suggested a qualified majority (2/3) process that
> >>> also includes the notion of a quorum. In an earlier email you
> >>> referenced quorum in relation to Apache bylaws Section 3.9
> >>> dealing with general members (i.e. 33% of the PMC).
> >>>
> >>> A third proposal from Sam Ruby is based on auto-PMC-membership,
> >>> majority voting rules and presumably a fixed quorum of 3.
> >>
> >
> >
> > Looking at the three proposals, can we take pieces from all?
> >
> > * Auto PMC membership for committers who have been active for
> > at least six months.
>
>
> I actually prefer the active opt-in process. This ensures
> that we don't
> auto place people on the PMC who don't want to be on the PMC.
> It also
> would ensure that the PMC membership is an engaged membership. This
> could be achieved by requiring re-election at periodic
> intervals. This
> could be achived by including a requirement for PMC elections every
> year, and limiting the term of membership to one year.
>
> >
> >
> > * Charter and Bylaw voting time period is a week
>
> +1
>
> >
> > * A motion passes with 2/3 majority vote of quorum
>
>
> Assuming active opt-in as described above, then:
>
> A 2/3 majority with a 33% quorum is ok providing this is considered
> legally binding from the board perspective. Otherwise, 50%
> majority with
> a 50% quorum.
>
> >
> > * In the event that quorum cannot be met, voting remains open
> > until quorum is met.
>
> +1
>
> >
> > * Size of quorum shall be [insert your percentage here], with
> > a floor of 3 people (i.e. if percentage of PMC is less than
> > three, then Quorum is still 3)
> >
> >
> > BTW, what percentage of PMC membership would you like to see
> > for quorum? 50% or 33%? I am flexible on this point.
Ok. Considering all the stuff above, it looks like we should stick
as close to the board pattern as possible. So it looks best for:
* Strict majority ( > 50% ) with a quorum of 50% of the PMC. I
honestly like something to win with more than 51% because in my
opinion if the resolution can be written better it will win by
more. Nevertheless, this is representative enough of the
community that I will not resist it as long as point number 2
is accepted.
* PMC votes are open for a minimum of one week.
* If quorum cannot be met within one week, voting remains open
until quorum is met. Should we have a time limit on this? For
example, if an issue is on the table for a year, and quorum
has not been made yet on an issue it makes little sense to
keep it on the table.
* PMC members are nominated by the community, and voted in by
the existing PMC. Do we have minimum qualifications? I.e.
should the PMC members be active committers in the community
for six months?
* Projects that depend on Avalon have the ability to nominate
one representative each to the PMC.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>> Back to the discussion on procedures for the PMC. Based on the
>>> emails so far, it seems to me that there are a three proposals that
>>> meet both our objectives.
>>>
>>> Noel has suggested a majority voting process that is based on
>>> the Board process that includes the notion of quorum based on
>>> Apache bylaws Section 5.8. Quorum and Voting (i.e. 50% of
>>> PMC members).
>>>
>>> You have also suggested a qualified majority (2/3) process that
>>> also includes the notion of a quorum. In an earlier email you
>>> referenced quorum in relation to Apache bylaws Section 3.9
>>> dealing with general members (i.e. 33% of the PMC).
>>>
>>> A third proposal from Sam Ruby is based on auto-PMC-membership,
>>> majority voting rules and presumably a fixed quorum of 3.
>>
>
>
> Looking at the three proposals, can we take pieces from all?
>
> * Auto PMC membership for committers who have been active for
> at least six months.
I actually prefer the active opt-in process. This ensures that we don't
auto place people on the PMC who don't want to be on the PMC. It also
would ensure that the PMC membership is an engaged membership. This
could be achieved by requiring re-election at periodic intervals. This
could be achived by including a requirement for PMC elections every
year, and limiting the term of membership to one year.
>
>
> * Charter and Bylaw voting time period is a week
+1
>
> * A motion passes with 2/3 majority vote of quorum
Assuming active opt-in as described above, then:
A 2/3 majority with a 33% quorum is ok providing this is considered
legally binding from the board perspective. Otherwise, 50% majority with
a 50% quorum.
>
> * In the event that quorum cannot be met, voting remains open
> until quorum is met.
+1
>
> * Size of quorum shall be [insert your percentage here], with
> a floor of 3 people (i.e. if percentage of PMC is less than
> three, then Quorum is still 3)
>
>
> BTW, what percentage of PMC membership would you like to see
> for quorum? 50% or 33%? I am flexible on this point.
See above.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Berin Loritsch <bl...@apache.org>.
>> Back to the discussion on procedures for the PMC. Based on the emails
>> so far, it seems to me that there are a three proposals that meet both
>> our objectives.
>>
>> Noel has suggested a majority voting process that is based on
>> the Board process that includes the notion of quorum based on
>> Apache bylaws Section 5.8. Quorum and Voting (i.e. 50% of
>> PMC members).
>>
>> You have also suggested a qualified majority (2/3) process that
>> also includes the notion of a quorum. In an earlier email you
>> referenced quorum in relation to Apache bylaws Section 3.9
>> dealing with general members (i.e. 33% of the PMC).
>>
>> A third proposal from Sam Ruby is based on auto-PMC-membership,
>> majority voting rules and presumably a fixed quorum of 3.
Looking at the three proposals, can we take pieces from all?
* Auto PMC membership for committers who have been active for
at least six months.
* Charter and Bylaw voting time period is a week
* A motion passes with 2/3 majority vote of quorum
* In the event that quorum cannot be met, voting remains open
until quorum is met.
* Size of quorum shall be [insert your percentage here], with
a floor of 3 people (i.e. if percentage of PMC is less than
three, then Quorum is still 3)
BTW, what percentage of PMC membership would you like to see
for quorum? 50% or 33%? I am flexible on this point.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>>
>> Stephen, what is the biggest problem with the Avalon community?
>> Just that, the community. The thing is that we the community have
>> to come up with the bylaws that run our community. If the community is
>> not happy with the bylaws that the PMC sets up by blind majority, they
>> will go elsewhere.
>>
>> I think it is more important at this juncture to get the community
>> on board and forget about your pet agenda.
>
> Berin:
>
> Lets take a step back for a moment and look at what we are both
> attempting to achieve.
<snip/>
> Back to the discussion on procedures for the PMC. Based on the emails
> so far, it seems to me that there are a three proposals that meet both
> our objectives.
>
> Noel has suggested a majority voting process that is based on
> the Board process that includes the notion of quorum based on
> Apache bylaws Section 5.8. Quorum and Voting (i.e. 50% of
> PMC members).
>
> You have also suggested a qualified majority (2/3) process that
> also includes the notion of a quorum. In an earlier email you
> referenced quorum in relation to Apache bylaws Section 3.9
> dealing with general members (i.e. 33% of the PMC).
>
> A third proposal from Sam Ruby is based on auto-PMC-membership,
> majority voting rules and presumably a fixed quorum of 3.
>
> The difference between the first two is subtle - the benefit of
> increasing the quorum is that it ensures "representation" - the downside
> is related to availability of members. The impact of "majority" as
> opposed to "qualified majority" favors consensus. Of the two, I think I
> prefer your proposal. The third proposal is interesting because it
> ensures representation and in general makes life simpler (it is also
> possibly my favorite out of the three). However - to properly included
> the third proposal would need to set the timeframe for voting to be
> something like a week instead of 72 hours.
So you are saying that you would like a 2/3 majority?
I highly favor a week voting frame. There are times where I cannot
get to this list for 4 whole days, and it would give me a chance to
review all the information and make an informed choice. I think that
a week is probably the best length of time--it is not so long as to
unduly drag out a process while not being so short that it does not
provide a reasonable enough time to respond properly.
BTW, I think we have a basis we can work with.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I not trying to lower a standard - just trying to understand and compare
> proposals on the table.
Ok, my misunderstanding of what I thought you indicated as preferences. :-)
I summarized Berin's merged proposal in another message, along with the
three variables that were contained.
> The board meeting quorum is 50% and majority decisions.
> The closer we stick to board procedures the better.
Hence my suggestion. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Based on the emails so far, it seems to me that there are
>>a three proposals that meet both our objectives.
>>
>
>I'd like to clarify. Are you trying to lower the standard for a quorum from
>50% of PMC members to a minimum of 3 PMC members voting over some period of
>time? [By the way, I also had incorporated the notion of time since there
>wouldn't be an actual meeting unlike for an ASF Board Meeting.]
>
I not trying to lower a standard - just trying to understand and compare
proposals on the table.
Both your proposal and Berin's proposal including a time reference - I
figure that Berin's suggestion of one week would be fine.
>
>As you stated: "the benefit of increasing the quorum is that it ensures
>representation - the downside is related to availability of members."
>
>There *might* be an obstacle with respect to the definition of a quorum.
>You are proposing that regardless of the size of the PMC that a quorum made
>of less than 50% be able to legally bind the organization. But if the ASF
>allows that, I really couldn't care less what the Community agrees upon as a
>quorum, so long as everyone is comfortable.
>
This is an important point. The board meeting quorum is 50% and
majority decisions. The closer we stick to board procedures the better.
>
>>>From your conclusion that the third proposal is (possibly) your favorite, I
>derive that you want all activce Committers to be represented on the PMC,
>majority vote (rather than 2/3), and a lower standard for a quorum. Is that
>correct?
>
I really don't have a conclusion yet. I see benefits in each - in your
proposal we are clearly very close to the policies of the board and
legal integrity. In Berin's proposal the notion of a qualified majority
comes in, and the quorum goes down (one balances against the other) and
favours concensus. In the third proposal we have greater representation
but its also the furthest from the board position.
>
>Again, just trying to pull together the mechanism from your prose.
>
If you prepared a bar graph for the three proposals you would see three
bars of basically equivalent height. The differences are subtle. One
favours representation, one favours concensus, and a third favours
legality. I havn't draw a conclusion - but I am trying to draw some graphs.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Based on the emails so far, it seems to me that there are
> a three proposals that meet both our objectives.
I'd like to clarify. Are you trying to lower the standard for a quorum from
50% of PMC members to a minimum of 3 PMC members voting over some period of
time? [By the way, I also had incorporated the notion of time since there
wouldn't be an actual meeting unlike for an ASF Board Meeting.]
As you stated: "the benefit of increasing the quorum is that it ensures
representation - the downside is related to availability of members."
There *might* be an obstacle with respect to the definition of a quorum.
You are proposing that regardless of the size of the PMC that a quorum made
of less than 50% be able to legally bind the organization. But if the ASF
allows that, I really couldn't care less what the Community agrees upon as a
quorum, so long as everyone is comfortable.
>From your conclusion that the third proposal is (possibly) your favorite, I
derive that you want all activce Committers to be represented on the PMC,
majority vote (rather than 2/3), and a lower standard for a quorum. Is that
correct?
Again, just trying to pull together the mechanism from your prose.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> Your going to consider me really picky - but what the hell - it is
>> important. What we *need* is agreement by the PMC members on a
>> charter and as things stand today - and that is basically a majority
>> opinion of the elected PMC members until such time that we declare
>> charter modification as something special under a set of PMC
>> by-laws. And, yes - it would *nice* to have PMC member concensus,
>> even community concensus - but these attributes are not obligations
>> on the PMC members and do not impact the decision procedure.
>
>
> Stephen, what is the biggest problem with the Avalon community?
> Just that, the community. The thing is that we the community have
> to come up with the bylaws that run our community. If the community is
> not happy with the bylaws that the PMC sets up by blind majority, they
> will go elsewhere.
>
> I think it is more important at this juncture to get the community
> on board and forget about your pet agenda.
Berin:
Lets take a step back for a moment and look at what we are both
attempting to achieve.
You want to make sure that the process under which the
PMC makes decisions cannot be abused through rushing of
something then results in a majority decision, and becomes
law. I think (and I'm sure you will agree with this) that
PMC decisions will be on important issues, and such we must
ensure that there is a process that ensures adequate
discussion and representation. You have raised the vote to
recommend the formation of an Avalon PMC as an example of
the type of process that you consider inappropriate. Your
issue is the timeframe for the vote - in the case of the
PMC vote that was 72 hours. I agree with you that PMC
voting processes should be longer then this.
I want to make sure the procedures that are put in place
for PMC decision making cannot be used a single individual
to hold up the will of majority.
There is another aspect concerning the process we employ to achieve
resolution of the above points.
You priority is to ensure that the whatever we establish,
it is based on the consensus of this community. This is a
position I am completely supportive on. My disagreement above
was on the grounds of a conflict between the "standing
procedure" the PMC has today, and what was implied by your
earlier email that suggested the adoption of committer
procedures for handling the work on charter and procedures.
While I am totally with you on the principal of a total
consensus based process, I think it is equally important
that we respect the rules that exist (even if we don't like
them) just as we will respect future procedures that we
establish.
I think we can achieve community consensus on a set of policies
and procedures - and once that is achieved, the PMC will have
to vote on something using the existing PMC procedures.
Back to the discussion on procedures for the PMC. Based on the emails
so far, it seems to me that there are a three proposals that meet both
our objectives.
Noel has suggested a majority voting process that is based on
the Board process that includes the notion of quorum based on
Apache bylaws Section 5.8. Quorum and Voting (i.e. 50% of
PMC members).
You have also suggested a qualified majority (2/3) process that
also includes the notion of a quorum. In an earlier email you
referenced quorum in relation to Apache bylaws Section 3.9
dealing with general members (i.e. 33% of the PMC).
A third proposal from Sam Ruby is based on auto-PMC-membership,
majority voting rules and presumably a fixed quorum of 3.
The difference between the first two is subtle - the benefit of
increasing the quorum is that it ensures "representation" - the downside
is related to availability of members. The impact of "majority" as
opposed to "qualified majority" favors consensus. Of the two, I think I
prefer your proposal. The third proposal is interesting because it
ensures representation and in general makes life simpler (it is also
possibly my favorite out of the three). However - to properly included
the third proposal would need to set the timeframe for voting to be
something like a week instead of 72 hours.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Your going to consider me really picky - but what the hell - it is
> important.
> What we *need* is agreement by the PMC members on a charter and as
> things stand today - and that is basically a majority opinion of the
> elected PMC members until such time that we declare charter modification
> as something special under a set of PMC by-laws. And, yes - it would
> *nice* to have PMC member concensus, even community concensus - but
> these attributes are not obligations on the PMC members and do not
> impact the decision procedure.
Stephen, what is the biggest problem with the Avalon community?
Just that, the community. The thing is that we the community have
to come up with the bylaws that run our community. If the community is
not happy with the bylaws that the PMC sets up by blind majority, they
will go elsewhere.
I think it is more important at this juncture to get the community
on board and forget about your pet agenda.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I added the text to the draft charter to Avalon CVS in the following
> location: ${jakarta-avalon}/src/proposal/CHARTER.txt
>
> We can take this charter and pick it apart piece by piece. I suggest
> that we start section by section coming up with the best wording. What
> is currently there should be considered only a starting point based on
> the charter from an existing Apache TLP.
>
> We can incorporate comments from other folks doing the same in other
> newly formed TLPs.
>
> Stephen has already made clear his dislike of the word "unanimous",
> but before we blindly remove that word, we need to come to community
> consensus.
Your going to consider me really picky - but what the hell - it is
important.
What we *need* is agreement by the PMC members on a charter and as
things stand today - and that is basically a majority opinion of the
elected PMC members until such time that we declare charter modification
as something special under a set of PMC by-laws. And, yes - it would
*nice* to have PMC member concensus, even community concensus - but
these attributes are not obligations on the PMC members and do not
impact the decision procedure.
Cheers, Steve.
>
>
> ---------------------------------------------
> Introducing NetZero Long Distance
> 1st month Free!
> Sign up today at: www.netzerolongdistance.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I added the text to the draft charter to Avalon CVS in the following
> location: ${jakarta-avalon}/src/proposal/CHARTER.txt
>
> We can take this charter and pick it apart piece by piece. I suggest
> that we start section by section coming up with the best wording. What
> is currently there should be considered only a starting point based on
> the charter from an existing Apache TLP.
>
> We can incorporate comments from other folks doing the same in other
> newly formed TLPs.
>
> Stephen has already made clear his dislike of the word "unanimous",
> but before we blindly remove that word, we need to come to community
> consensus.
Your going to consider me really picky - but what the hell - it is
important.
What we *need* is agreement by the PMC members on a charter and as
things stand today - and that is basically a majority opinion of the
elected PMC members until such time that we declare charter modification
as something special under a set of PMC by-laws. And, yes - it would
*nice* to have PMC member concensus, even community concensus - but
these attributes are not obligations on the PMC members and do not
impact the decision procedure.
Cheers, Steve.
>
>
> ---------------------------------------------
> Introducing NetZero Long Distance
> 1st month Free!
> Sign up today at: www.netzerolongdistance.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I added the text to the draft charter to Avalon CVS in the following
> location: ${jakarta-avalon}/src/proposal/CHARTER.txt
>
> We can take this charter and pick it apart piece by piece. I suggest
> that we start section by section coming up with the best wording. What
> is currently there should be considered only a starting point based on
> the charter from an existing Apache TLP.
>
> We can incorporate comments from other folks doing the same in other
> newly formed TLPs.
>
> Stephen has already made clear his dislike of the word "unanimous",
> but before we blindly remove that word, we need to come to community
> consensus.
Your going to consider me really picky - but what the hell - it is
important.
What we *need* is agreement by the PMC members on a charter and as
things stand today - and that is basically a majority opinion of the
elected PMC members until such time that we declare charter modification
as something special under a set of PMC by-laws. And, yes - it would
*nice* to have PMC member concensus, even community concensus - but
these attributes are not obligations on the PMC members and do not
impact the decision procedure.
Cheers, Steve.
>
>
> ---------------------------------------------
> Introducing NetZero Long Distance
> 1st month Free!
> Sign up today at: www.netzerolongdistance.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
> The PMC must have at least one officer from the Apache
> Board, who will be the Chairperson and report to the
> Apache Board. See http://www.apache.org/foundation/bylaws.html
> for reference.
>
>
> Doesn't this exclude Nicola from being chair?
No. Apart from the fact that I'm an Apache member, all PMC chairs are
officers of the Apache Software Foundation, by definition.
> Or does it
> mean that he will be appointed an officer upon becoming
> chair?
Chairs are Apache officers.
> How does this impact the "rotating chair" proposal?
I don't think it really does, and surely it can be discussed and
resolved by the board somehow.
<leaving-discussion-to-others/>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
> The PMC must have at least one officer from the Apache
> Board, who will be the Chairperson and report to the
> Apache Board. See http://www.apache.org/foundation/bylaws.html
> for reference.
>
>
> Doesn't this exclude Nicola from being chair?
No. Apart from the fact that I'm an Apache member, all PMC chairs are
officers of the Apache Software Foundation, by definition.
> Or does it
> mean that he will be appointed an officer upon becoming
> chair?
Chairs are Apache officers.
> How does this impact the "rotating chair" proposal?
I don't think it really does, and surely it can be discussed and
resolved by the board somehow.
<leaving-discussion-to-others/>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Charter.txt
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
> The PMC must have at least one officer from the Apache
> Board, who will be the Chairperson and report to the
> Apache Board. See http://www.apache.org/foundation/bylaws.html
> for reference.
>
>
> Doesn't this exclude Nicola from being chair?
No. Apart from the fact that I'm an Apache member, all PMC chairs are
officers of the Apache Software Foundation, by definition.
> Or does it
> mean that he will be appointed an officer upon becoming
> chair?
Chairs are Apache officers.
> How does this impact the "rotating chair" proposal?
I don't think it really does, and surely it can be discussed and
resolved by the board somehow.
<leaving-discussion-to-others/>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> The PMC must have at least one officer from the Apache
> Board, who will be the Chairperson and report to the
> Apache Board. See http://www.apache.org/foundation/bylaws.html
> for reference.
Doesn't this exclude Nicola from being chair? Or does it
mean that he will be appointed an officer upon becoming
chair? How does this impact the "rotating chair" proposal?
> In the unlikely event that a member of the PMC becomes
> disruptive to the process or ceases to contribute for
> an extended period, said member may be removed by unanimous
> vote of remaining PMC members.
If we require unanimous vote, wouldn't it be more sensible
to have "for any reason" here? I mean, if everyone agrees
that I should be kicked out, shouldn't that then be possible
despite my once-a-year committs, and without having to
get into the nuances of what "disruptive" is?
> SUBPROJECTS
> ===========
> avalon.apache.org is comprised of subprojects; a
> subproject is a component whose scope is well defined.
> Each subproject has its own set of developers.
>
> A new subproject proposal is submitted to the PMC,
> accepted by majority committer vote, and then subject
> to final approval by the PMC.
Is the final approval unanimous?
Is there any point in explicitely stating that even though
a subproject has its own set of developers, those
developers are not a separate part of Avalon - that is,
they can not exclude any other Avalon committer from
voting, etc.
Also, is there any point in specifying that sub-sub-projects
are disallowed? I don't want us to become another
Jakarta with subprojects 1000 levels deep.
> New committers are added when a developer is nominated by
> a committer and approved by at least 50 percent of the
> committers for that subproject with no opposing votes.
Should be "approved by concensus", or 50% of *active*
committers.
> Specific changes to a product proposed for discussion or
> voting on the appropriate development mailing list should
> be presented in the form of input to the patch command.
> When sent to the mailing list, the message should contain
> a subject beginning with [PATCH] and including a distinctive
> one-line summary that corresponds to the action item for that
> patch.
How about we get patches into bugzilla instead? Cocoon has a very
nice patch queue that guarantees that patches aren't forgotten.
The above becomes:
"
The proposed changes, and the associated patch file should be
filed as a bug in Bugzilla, with a short description beginning
with [PATCH]. The patch file should then be attached to the bug
via the bugzilla attachment mechanism.
"
> For efficiency, some code changes from some contributors
> (e.g. feature additions, bug fixes) may be approved in
> advance, in which case they may be committed first and changed
> as needed, with conflicts resolved by majority vote of the
> committers.
Change to "may be approved via concensus in advance"
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> The PMC must have at least one officer from the Apache
> Board, who will be the Chairperson and report to the
> Apache Board. See http://www.apache.org/foundation/bylaws.html
> for reference.
Doesn't this exclude Nicola from being chair? Or does it
mean that he will be appointed an officer upon becoming
chair? How does this impact the "rotating chair" proposal?
> In the unlikely event that a member of the PMC becomes
> disruptive to the process or ceases to contribute for
> an extended period, said member may be removed by unanimous
> vote of remaining PMC members.
If we require unanimous vote, wouldn't it be more sensible
to have "for any reason" here? I mean, if everyone agrees
that I should be kicked out, shouldn't that then be possible
despite my once-a-year committs, and without having to
get into the nuances of what "disruptive" is?
> SUBPROJECTS
> ===========
> avalon.apache.org is comprised of subprojects; a
> subproject is a component whose scope is well defined.
> Each subproject has its own set of developers.
>
> A new subproject proposal is submitted to the PMC,
> accepted by majority committer vote, and then subject
> to final approval by the PMC.
Is the final approval unanimous?
Is there any point in explicitely stating that even though
a subproject has its own set of developers, those
developers are not a separate part of Avalon - that is,
they can not exclude any other Avalon committer from
voting, etc.
Also, is there any point in specifying that sub-sub-projects
are disallowed? I don't want us to become another
Jakarta with subprojects 1000 levels deep.
> New committers are added when a developer is nominated by
> a committer and approved by at least 50 percent of the
> committers for that subproject with no opposing votes.
Should be "approved by concensus", or 50% of *active*
committers.
> Specific changes to a product proposed for discussion or
> voting on the appropriate development mailing list should
> be presented in the form of input to the patch command.
> When sent to the mailing list, the message should contain
> a subject beginning with [PATCH] and including a distinctive
> one-line summary that corresponds to the action item for that
> patch.
How about we get patches into bugzilla instead? Cocoon has a very
nice patch queue that guarantees that patches aren't forgotten.
The above becomes:
"
The proposed changes, and the associated patch file should be
filed as a bug in Bugzilla, with a short description beginning
with [PATCH]. The patch file should then be attached to the bug
via the bugzilla attachment mechanism.
"
> For efficiency, some code changes from some contributors
> (e.g. feature additions, bug fixes) may be approved in
> advance, in which case they may be committed first and changed
> as needed, with conflicts resolved by majority vote of the
> committers.
Change to "may be approved via concensus in advance"
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Charter.txt
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> The PMC must have at least one officer from the Apache
> Board, who will be the Chairperson and report to the
> Apache Board. See http://www.apache.org/foundation/bylaws.html
> for reference.
Doesn't this exclude Nicola from being chair? Or does it
mean that he will be appointed an officer upon becoming
chair? How does this impact the "rotating chair" proposal?
> In the unlikely event that a member of the PMC becomes
> disruptive to the process or ceases to contribute for
> an extended period, said member may be removed by unanimous
> vote of remaining PMC members.
If we require unanimous vote, wouldn't it be more sensible
to have "for any reason" here? I mean, if everyone agrees
that I should be kicked out, shouldn't that then be possible
despite my once-a-year committs, and without having to
get into the nuances of what "disruptive" is?
> SUBPROJECTS
> ===========
> avalon.apache.org is comprised of subprojects; a
> subproject is a component whose scope is well defined.
> Each subproject has its own set of developers.
>
> A new subproject proposal is submitted to the PMC,
> accepted by majority committer vote, and then subject
> to final approval by the PMC.
Is the final approval unanimous?
Is there any point in explicitely stating that even though
a subproject has its own set of developers, those
developers are not a separate part of Avalon - that is,
they can not exclude any other Avalon committer from
voting, etc.
Also, is there any point in specifying that sub-sub-projects
are disallowed? I don't want us to become another
Jakarta with subprojects 1000 levels deep.
> New committers are added when a developer is nominated by
> a committer and approved by at least 50 percent of the
> committers for that subproject with no opposing votes.
Should be "approved by concensus", or 50% of *active*
committers.
> Specific changes to a product proposed for discussion or
> voting on the appropriate development mailing list should
> be presented in the form of input to the patch command.
> When sent to the mailing list, the message should contain
> a subject beginning with [PATCH] and including a distinctive
> one-line summary that corresponds to the action item for that
> patch.
How about we get patches into bugzilla instead? Cocoon has a very
nice patch queue that guarantees that patches aren't forgotten.
The above becomes:
"
The proposed changes, and the associated patch file should be
filed as a bug in Bugzilla, with a short description beginning
with [PATCH]. The patch file should then be attached to the bug
via the bugzilla attachment mechanism.
"
> For efficiency, some code changes from some contributors
> (e.g. feature additions, bug fixes) may be approved in
> advance, in which case they may be committed first and changed
> as needed, with conflicts resolved by majority vote of the
> committers.
Change to "may be approved via concensus in advance"
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>