You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@citi-us.com> on 2002/12/04 18:10:12 UTC
Avalon voting process
I propose that we follow the voting process outlined
by Incubator. It is standard across all the projects
I have seen. It addresses voting process of the community
at large, but does not address the voting process of
the PMC.
I still have yet to see other charters besides the XML
one, and voting guidelines do not constitute a charter.
I suggest that changes to the charter and voting guidelines
be treated as code changes, with the stipulation that only
PMC votes are binding. That allows a PMC member to veto
a change with proper justification. Proper justification
should also have a counter-proposal so that the rest of
the PMC knows *how* to rectify the situation.
Regarding Avalon membership, we should follow the Apache
bylaws Article IV (4). Membership meaning committers, and
PMC.
In regards to the definition of Quorum, we should follow
the Apache bylaws Article III (3) Section 3.9.
Are we on board with this?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon voting process
Posted by Paul Hammant <Pa...@yahoo.com>.
> You may sense a certain aggression/frustration here. That is brought
> about by the inability of this community to deal with the problems
> back in July/August - it was complicated by the inability of the
> Jakarta PMC to address the issue. Even the board didn't address the
> issue on the table at the time. Nobody took a position - not structure
> in the entire Apache organization was willing to step in with a
> closure. Yes - Pete got kicked - but that wasn't the subject of the
> Jakarta/Board discussion before - that was probably more of a surprise
> to me than to any of you. What I do know is that those types issues
> MUST be address by the Avalon PMC. If you continue along the lines
> your describing - your just creating the comfortable environment where
> you simply isolate yourself away from the potential of having to take
> a difficult decision.
>
> As a PMC member - I REFUSE to let a similar situation arise for other
> members of the community. I will do everything I can to ensure that
> the PMC is an instrument that has balls and ability. And I'm confident
> that providing those attributes are held up with respect - that we
> will never need to use them. Today the PMC has balls - please don't
> try to take that away. Its abilities will evolve through attention and
> consideration to the charter and procedures, and progressively,
> through respect from a united community.
The aggression is not helpful, our wider community shrinks by a
percentage again.
For the record, I was like it or not, mediating on the 'dispute' on
August. Significant gains were made. I did not publish my results to the
board. I'm sure if I had done, the board would not have felt the need to
act on advise since then, in the way they did.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >I propose that we follow the voting process outlined
> >by Incubator.
> >
>
> It looks good in terms of committer procedures.
> A lot of the loose ends are getting cleaned up.
>
> >It is standard across all the projects
> >I have seen. It addresses voting process of the community
> >at large, but does not address the voting process of
> >the PMC.
> >
>
> Correct.
>
> >
> >I still have yet to see other charters besides the XML
> >one, and voting guidelines do not constitute a charter.
> >I suggest that changes to the charter and voting guidelines
> >be treated as code changes, with the stipulation that only
> >PMC votes are binding.
> >
>
> -1
>
> NO, NO, NO, NO.
>
<snip/>
> I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN.
>
> NOT EVER - NEVER.
Calm down. Keep in mind what a valid veto is (in another version
of this mail).
> >That allows a PMC member to veto
> >a change with proper justification.
> >
>
> Incorrect - any justification - feeble, profound, fantasy, etc. and
> nothing to fallback on. We have today a majority voting
> process. We can
> change that thought a majority vote. That's it - there are no other
> rules applicable here. Please - just use the structure we
> have and don't
> imply anything different with a PMC vote.
I also don't want to be railroaded again--or did you miss that
when you steamrolled the Avalon PMC through? I want the ability
to say "Hold on, you need to slow down. There are more things
to think through".
With mere majority voting, my call to slow down will likely get
overrun and then I am left holding the bag and trying to clean
up your mess.
Again, I assert that a proper veto as I outlined in another
mail must be supported. A proper veto is not "I don't like it",
that is invalid. A proper veto is accompanied by a reasonable
explanation AND a counter-proposal.
> >Proper justification
> >should also have a counter-proposal so that the rest of
> >the PMC knows *how* to rectify the situation.
>
> Just image for a moment that I really object to something (like your
> ideas about voting on the PMC). And lets assume that your model is in
> place. And lets assume that you and I disagree on something
> similar. And
> lets assume that my arguments and your arguments are both
> well prepared
> and rationale. Your solution creates a deadlock - you have
> destroyed the
> intrinsic value of the PMC - and that it be able to do things
> when such
> need arrives. You don't need to look very far back into
> Avalon history
> to see evidence of this. I'm not ready to bet the form on that not
> happening again.
>
> Today - we have a majority rules on the PMC.
Today, we have not voted on any PMC bylaws, and until I started
bringing up the subject everyone was quiet.
-1 on majority rules. It opens the door to steamrolling through
concepts, ideas, etc. that are in favor of certain individuals but
not the whole of Avalon. I repeat, I will not be left holding the
bag from yours or anyone else's pushing through something before it
is completely thought out. Period. I am just as unyielding on this
point as you are on unanimous votes. I AM open to two-thirds majority
of the PMC with voting open for an entire week. However simple
majority doesn't work either. It's too easy to pull the wool over
someones eyes for the length of time for a quick vote--and then
the community regrets the outcome of the decision. The consequences
of PMC resolutions are far greater than code changes, so I want
something that will *force* us to work together on a solution we
can all live with.
I hope I am very clear on the matter. I am in favor of an Avalon
PMC, but I am against the manner in which it came into being. I
do not want to go through that again.
> In the meantime - please not more assertions of what rules
> apply - there
> are rules already in place. Lets focus on charter - not
> procedure - and
> drop any discussion about policy to apply with result to charter or
> policy evolution. It simple - a majority of the PMC voter to
> change the
> charter - the change gets escalated to the Board, the board does it
> stuff. If that's no ok - then raise a vote on the PMC list.
-1 for the reasons stated above. 2/3 majority is acceptable.
Again, I am against the way things were steamrolled through
to create the Avalon PMC, and I don't want to be subject to that
again.
> ----------ooo0ooo-----------
>
> You may sense a certain aggression/frustration here. That is brought
> about by the inability of this community to deal with the
> problems back
> in July/August - it was complicated by the inability of the
> Jakarta PMC
> to address the issue. Even the board didn't address the issue on the
> table at the time. Nobody took a position - not structure in
> the entire
> Apache organization was willing to step in with a closure. Yes - Pete
> got kicked - but that wasn't the subject of the Jakarta/Board
> discussion
> before - that was probably more of a surprise to me than to
> any of you.
> What I do know is that those types issues MUST be address by
> the Avalon
> PMC. If you continue along the lines your describing - your just
> creating the comfortable environment where you simply isolate
> yourself
> away from the potential of having to take a difficult decision.
Look, I am able and willing to make very difficult decisions.
I have made many more before Avalon was a part of my involvement.
Those decisions impacted myself, my family, and other people. I
am not afraid of standing for what I believe in. I find it a
strength.
The important thing is this: I don't want to be held responsible
for the rash decisions of others. Simple majority opens the door
for that. Mob rule did not work for Greece, and I don't think it
will work here.
> As a PMC member - I REFUSE to let a similar situation arise for other
> members of the community. I will do everything I can to
> ensure that the
> PMC is an instrument that has balls and ability. And I'm
> confident that
> providing those attributes are held up with respect - that we
> will never
> need to use them. Today the PMC has balls - please don't try to take
> that away. Its abilities will evolve through attention and
> consideration
> to the charter and procedures, and progressively, through
> respect from a
> united community.
Also keep in mind that the veto Peter issued you back in August
would not have been valid under my proposed definition of veto.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >I propose that we follow the voting process outlined
> >by Incubator.
> >
>
> It looks good in terms of committer procedures.
> A lot of the loose ends are getting cleaned up.
>
> >It is standard across all the projects
> >I have seen. It addresses voting process of the community
> >at large, but does not address the voting process of
> >the PMC.
> >
>
> Correct.
>
> >
> >I still have yet to see other charters besides the XML
> >one, and voting guidelines do not constitute a charter.
> >I suggest that changes to the charter and voting guidelines
> >be treated as code changes, with the stipulation that only
> >PMC votes are binding.
> >
>
> -1
>
> NO, NO, NO, NO.
>
<snip/>
> I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN.
>
> NOT EVER - NEVER.
Calm down. Keep in mind what a valid veto is (in another version
of this mail).
> >That allows a PMC member to veto
> >a change with proper justification.
> >
>
> Incorrect - any justification - feeble, profound, fantasy, etc. and
> nothing to fallback on. We have today a majority voting
> process. We can
> change that thought a majority vote. That's it - there are no other
> rules applicable here. Please - just use the structure we
> have and don't
> imply anything different with a PMC vote.
I also don't want to be railroaded again--or did you miss that
when you steamrolled the Avalon PMC through? I want the ability
to say "Hold on, you need to slow down. There are more things
to think through".
With mere majority voting, my call to slow down will likely get
overrun and then I am left holding the bag and trying to clean
up your mess.
Again, I assert that a proper veto as I outlined in another
mail must be supported. A proper veto is not "I don't like it",
that is invalid. A proper veto is accompanied by a reasonable
explanation AND a counter-proposal.
> >Proper justification
> >should also have a counter-proposal so that the rest of
> >the PMC knows *how* to rectify the situation.
>
> Just image for a moment that I really object to something (like your
> ideas about voting on the PMC). And lets assume that your model is in
> place. And lets assume that you and I disagree on something
> similar. And
> lets assume that my arguments and your arguments are both
> well prepared
> and rationale. Your solution creates a deadlock - you have
> destroyed the
> intrinsic value of the PMC - and that it be able to do things
> when such
> need arrives. You don't need to look very far back into
> Avalon history
> to see evidence of this. I'm not ready to bet the form on that not
> happening again.
>
> Today - we have a majority rules on the PMC.
Today, we have not voted on any PMC bylaws, and until I started
bringing up the subject everyone was quiet.
-1 on majority rules. It opens the door to steamrolling through
concepts, ideas, etc. that are in favor of certain individuals but
not the whole of Avalon. I repeat, I will not be left holding the
bag from yours or anyone else's pushing through something before it
is completely thought out. Period. I am just as unyielding on this
point as you are on unanimous votes. I AM open to two-thirds majority
of the PMC with voting open for an entire week. However simple
majority doesn't work either. It's too easy to pull the wool over
someones eyes for the length of time for a quick vote--and then
the community regrets the outcome of the decision. The consequences
of PMC resolutions are far greater than code changes, so I want
something that will *force* us to work together on a solution we
can all live with.
I hope I am very clear on the matter. I am in favor of an Avalon
PMC, but I am against the manner in which it came into being. I
do not want to go through that again.
> In the meantime - please not more assertions of what rules
> apply - there
> are rules already in place. Lets focus on charter - not
> procedure - and
> drop any discussion about policy to apply with result to charter or
> policy evolution. It simple - a majority of the PMC voter to
> change the
> charter - the change gets escalated to the Board, the board does it
> stuff. If that's no ok - then raise a vote on the PMC list.
-1 for the reasons stated above. 2/3 majority is acceptable.
Again, I am against the way things were steamrolled through
to create the Avalon PMC, and I don't want to be subject to that
again.
> ----------ooo0ooo-----------
>
> You may sense a certain aggression/frustration here. That is brought
> about by the inability of this community to deal with the
> problems back
> in July/August - it was complicated by the inability of the
> Jakarta PMC
> to address the issue. Even the board didn't address the issue on the
> table at the time. Nobody took a position - not structure in
> the entire
> Apache organization was willing to step in with a closure. Yes - Pete
> got kicked - but that wasn't the subject of the Jakarta/Board
> discussion
> before - that was probably more of a surprise to me than to
> any of you.
> What I do know is that those types issues MUST be address by
> the Avalon
> PMC. If you continue along the lines your describing - your just
> creating the comfortable environment where you simply isolate
> yourself
> away from the potential of having to take a difficult decision.
Look, I am able and willing to make very difficult decisions.
I have made many more before Avalon was a part of my involvement.
Those decisions impacted myself, my family, and other people. I
am not afraid of standing for what I believe in. I find it a
strength.
The important thing is this: I don't want to be held responsible
for the rash decisions of others. Simple majority opens the door
for that. Mob rule did not work for Greece, and I don't think it
will work here.
> As a PMC member - I REFUSE to let a similar situation arise for other
> members of the community. I will do everything I can to
> ensure that the
> PMC is an instrument that has balls and ability. And I'm
> confident that
> providing those attributes are held up with respect - that we
> will never
> need to use them. Today the PMC has balls - please don't try to take
> that away. Its abilities will evolve through attention and
> consideration
> to the charter and procedures, and progressively, through
> respect from a
> united community.
Also keep in mind that the veto Peter issued you back in August
would not have been valid under my proposed definition of veto.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >I propose that we follow the voting process outlined
> >by Incubator.
> >
>
> It looks good in terms of committer procedures.
> A lot of the loose ends are getting cleaned up.
>
> >It is standard across all the projects
> >I have seen. It addresses voting process of the community
> >at large, but does not address the voting process of
> >the PMC.
> >
>
> Correct.
>
> >
> >I still have yet to see other charters besides the XML
> >one, and voting guidelines do not constitute a charter.
> >I suggest that changes to the charter and voting guidelines
> >be treated as code changes, with the stipulation that only
> >PMC votes are binding.
> >
>
> -1
>
> NO, NO, NO, NO.
>
<snip/>
> I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN.
>
> NOT EVER - NEVER.
Calm down. Keep in mind what a valid veto is (in another version
of this mail).
> >That allows a PMC member to veto
> >a change with proper justification.
> >
>
> Incorrect - any justification - feeble, profound, fantasy, etc. and
> nothing to fallback on. We have today a majority voting
> process. We can
> change that thought a majority vote. That's it - there are no other
> rules applicable here. Please - just use the structure we
> have and don't
> imply anything different with a PMC vote.
I also don't want to be railroaded again--or did you miss that
when you steamrolled the Avalon PMC through? I want the ability
to say "Hold on, you need to slow down. There are more things
to think through".
With mere majority voting, my call to slow down will likely get
overrun and then I am left holding the bag and trying to clean
up your mess.
Again, I assert that a proper veto as I outlined in another
mail must be supported. A proper veto is not "I don't like it",
that is invalid. A proper veto is accompanied by a reasonable
explanation AND a counter-proposal.
> >Proper justification
> >should also have a counter-proposal so that the rest of
> >the PMC knows *how* to rectify the situation.
>
> Just image for a moment that I really object to something (like your
> ideas about voting on the PMC). And lets assume that your model is in
> place. And lets assume that you and I disagree on something
> similar. And
> lets assume that my arguments and your arguments are both
> well prepared
> and rationale. Your solution creates a deadlock - you have
> destroyed the
> intrinsic value of the PMC - and that it be able to do things
> when such
> need arrives. You don't need to look very far back into
> Avalon history
> to see evidence of this. I'm not ready to bet the form on that not
> happening again.
>
> Today - we have a majority rules on the PMC.
Today, we have not voted on any PMC bylaws, and until I started
bringing up the subject everyone was quiet.
-1 on majority rules. It opens the door to steamrolling through
concepts, ideas, etc. that are in favor of certain individuals but
not the whole of Avalon. I repeat, I will not be left holding the
bag from yours or anyone else's pushing through something before it
is completely thought out. Period. I am just as unyielding on this
point as you are on unanimous votes. I AM open to two-thirds majority
of the PMC with voting open for an entire week. However simple
majority doesn't work either. It's too easy to pull the wool over
someones eyes for the length of time for a quick vote--and then
the community regrets the outcome of the decision. The consequences
of PMC resolutions are far greater than code changes, so I want
something that will *force* us to work together on a solution we
can all live with.
I hope I am very clear on the matter. I am in favor of an Avalon
PMC, but I am against the manner in which it came into being. I
do not want to go through that again.
> In the meantime - please not more assertions of what rules
> apply - there
> are rules already in place. Lets focus on charter - not
> procedure - and
> drop any discussion about policy to apply with result to charter or
> policy evolution. It simple - a majority of the PMC voter to
> change the
> charter - the change gets escalated to the Board, the board does it
> stuff. If that's no ok - then raise a vote on the PMC list.
-1 for the reasons stated above. 2/3 majority is acceptable.
Again, I am against the way things were steamrolled through
to create the Avalon PMC, and I don't want to be subject to that
again.
> ----------ooo0ooo-----------
>
> You may sense a certain aggression/frustration here. That is brought
> about by the inability of this community to deal with the
> problems back
> in July/August - it was complicated by the inability of the
> Jakarta PMC
> to address the issue. Even the board didn't address the issue on the
> table at the time. Nobody took a position - not structure in
> the entire
> Apache organization was willing to step in with a closure. Yes - Pete
> got kicked - but that wasn't the subject of the Jakarta/Board
> discussion
> before - that was probably more of a surprise to me than to
> any of you.
> What I do know is that those types issues MUST be address by
> the Avalon
> PMC. If you continue along the lines your describing - your just
> creating the comfortable environment where you simply isolate
> yourself
> away from the potential of having to take a difficult decision.
Look, I am able and willing to make very difficult decisions.
I have made many more before Avalon was a part of my involvement.
Those decisions impacted myself, my family, and other people. I
am not afraid of standing for what I believe in. I find it a
strength.
The important thing is this: I don't want to be held responsible
for the rash decisions of others. Simple majority opens the door
for that. Mob rule did not work for Greece, and I don't think it
will work here.
> As a PMC member - I REFUSE to let a similar situation arise for other
> members of the community. I will do everything I can to
> ensure that the
> PMC is an instrument that has balls and ability. And I'm
> confident that
> providing those attributes are held up with respect - that we
> will never
> need to use them. Today the PMC has balls - please don't try to take
> that away. Its abilities will evolve through attention and
> consideration
> to the charter and procedures, and progressively, through
> respect from a
> united community.
Also keep in mind that the veto Peter issued you back in August
would not have been valid under my proposed definition of veto.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon voting process
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>I propose that we follow the voting process outlined
>by Incubator.
>
It looks good in terms of committer procedures.
A lot of the loose ends are getting cleaned up.
>It is standard across all the projects
>I have seen. It addresses voting process of the community
>at large, but does not address the voting process of
>the PMC.
>
Correct.
>
>I still have yet to see other charters besides the XML
>one, and voting guidelines do not constitute a charter.
>I suggest that changes to the charter and voting guidelines
>be treated as code changes, with the stipulation that only
>PMC votes are binding.
>
-1
NO, NO, NO, NO.
Berin:
Please throw out this idea of introducing the potential for deadlock -
just get it out of your mind. While I am confident that we will reach a
good solution just working on the standing majority rules procedures
under the PMC - please don't keep poluting this with notions that set
precedence of no-majority opinion. Your comment about treating these
subjects as code implicitly introduces the potential for veto - and drag
us back to a potential environment of unresolved issues. Maybe you have
not had to put up with this - but let me be real clear - if the Avalon
PMC procedures introduce anything that have the potential to block a
qualified majority (i.e. two-thirds) on what and who we are - and simple
majority on the rest of the things we have to deal with - then you, I,
and the rest of us have learnt NOTHING from the recent past.
I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN.
NOT EVER - NEVER.
>That allows a PMC member to veto
>a change with proper justification.
>
Incorrect - any justification - feeble, profound, fantasy, etc. and
nothing to fallback on. We have today a majority voting process. We can
change that thought a majority vote. That's it - there are no other
rules applicable here. Please - just use the structure we have and don't
imply anything different with a PMC vote.
>Proper justification
>should also have a counter-proposal so that the rest of
>the PMC knows *how* to rectify the situation.
>
Just image for a moment that I really object to something (like your
ideas about voting on the PMC). And lets assume that your model is in
place. And lets assume that you and I disagree on something similar. And
lets assume that my arguments and your arguments are both well prepared
and rationale. Your solution creates a deadlock - you have destroyed the
intrinsic value of the PMC - and that it be able to do things when such
need arrives. You don't need to look very far back into Avalon history
to see evidence of this. I'm not ready to bet the form on that not
happening again.
Today - we have a majority rules on the PMC.
In the meantime - please not more assertions of what rules apply - there
are rules already in place. Lets focus on charter - not procedure - and
drop any discussion about policy to apply with result to charter or
policy evolution. It simple - a majority of the PMC voter to change the
charter - the change gets escalated to the Board, the board does it
stuff. If that's no ok - then raise a vote on the PMC list.
----------ooo0ooo-----------
You may sense a certain aggression/frustration here. That is brought
about by the inability of this community to deal with the problems back
in July/August - it was complicated by the inability of the Jakarta PMC
to address the issue. Even the board didn't address the issue on the
table at the time. Nobody took a position - not structure in the entire
Apache organization was willing to step in with a closure. Yes - Pete
got kicked - but that wasn't the subject of the Jakarta/Board discussion
before - that was probably more of a surprise to me than to any of you.
What I do know is that those types issues MUST be address by the Avalon
PMC. If you continue along the lines your describing - your just
creating the comfortable environment where you simply isolate yourself
away from the potential of having to take a difficult decision.
As a PMC member - I REFUSE to let a similar situation arise for other
members of the community. I will do everything I can to ensure that the
PMC is an instrument that has balls and ability. And I'm confident that
providing those attributes are held up with respect - that we will never
need to use them. Today the PMC has balls - please don't try to take
that away. Its abilities will evolve through attention and consideration
to the charter and procedures, and progressively, through respect from a
united community.
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: Avalon voting process
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>I propose that we follow the voting process outlined
>by Incubator.
>
It looks good in terms of committer procedures.
A lot of the loose ends are getting cleaned up.
>It is standard across all the projects
>I have seen. It addresses voting process of the community
>at large, but does not address the voting process of
>the PMC.
>
Correct.
>
>I still have yet to see other charters besides the XML
>one, and voting guidelines do not constitute a charter.
>I suggest that changes to the charter and voting guidelines
>be treated as code changes, with the stipulation that only
>PMC votes are binding.
>
-1
NO, NO, NO, NO.
Berin:
Please throw out this idea of introducing the potential for deadlock -
just get it out of your mind. While I am confident that we will reach a
good solution just working on the standing majority rules procedures
under the PMC - please don't keep poluting this with notions that set
precedence of no-majority opinion. Your comment about treating these
subjects as code implicitly introduces the potential for veto - and drag
us back to a potential environment of unresolved issues. Maybe you have
not had to put up with this - but let me be real clear - if the Avalon
PMC procedures introduce anything that have the potential to block a
qualified majority (i.e. two-thirds) on what and who we are - and simple
majority on the rest of the things we have to deal with - then you, I,
and the rest of us have learnt NOTHING from the recent past.
I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN.
NOT EVER - NEVER.
>That allows a PMC member to veto
>a change with proper justification.
>
Incorrect - any justification - feeble, profound, fantasy, etc. and
nothing to fallback on. We have today a majority voting process. We can
change that thought a majority vote. That's it - there are no other
rules applicable here. Please - just use the structure we have and don't
imply anything different with a PMC vote.
>Proper justification
>should also have a counter-proposal so that the rest of
>the PMC knows *how* to rectify the situation.
>
Just image for a moment that I really object to something (like your
ideas about voting on the PMC). And lets assume that your model is in
place. And lets assume that you and I disagree on something similar. And
lets assume that my arguments and your arguments are both well prepared
and rationale. Your solution creates a deadlock - you have destroyed the
intrinsic value of the PMC - and that it be able to do things when such
need arrives. You don't need to look very far back into Avalon history
to see evidence of this. I'm not ready to bet the form on that not
happening again.
Today - we have a majority rules on the PMC.
In the meantime - please not more assertions of what rules apply - there
are rules already in place. Lets focus on charter - not procedure - and
drop any discussion about policy to apply with result to charter or
policy evolution. It simple - a majority of the PMC voter to change the
charter - the change gets escalated to the Board, the board does it
stuff. If that's no ok - then raise a vote on the PMC list.
----------ooo0ooo-----------
You may sense a certain aggression/frustration here. That is brought
about by the inability of this community to deal with the problems back
in July/August - it was complicated by the inability of the Jakarta PMC
to address the issue. Even the board didn't address the issue on the
table at the time. Nobody took a position - not structure in the entire
Apache organization was willing to step in with a closure. Yes - Pete
got kicked - but that wasn't the subject of the Jakarta/Board discussion
before - that was probably more of a surprise to me than to any of you.
What I do know is that those types issues MUST be address by the Avalon
PMC. If you continue along the lines your describing - your just
creating the comfortable environment where you simply isolate yourself
away from the potential of having to take a difficult decision.
As a PMC member - I REFUSE to let a similar situation arise for other
members of the community. I will do everything I can to ensure that the
PMC is an instrument that has balls and ability. And I'm confident that
providing those attributes are held up with respect - that we will never
need to use them. Today the PMC has balls - please don't try to take
that away. Its abilities will evolve through attention and consideration
to the charter and procedures, and progressively, through respect from a
united community.
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: Avalon voting process
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>I propose that we follow the voting process outlined
>by Incubator.
>
It looks good in terms of committer procedures.
A lot of the loose ends are getting cleaned up.
>It is standard across all the projects
>I have seen. It addresses voting process of the community
>at large, but does not address the voting process of
>the PMC.
>
Correct.
>
>I still have yet to see other charters besides the XML
>one, and voting guidelines do not constitute a charter.
>I suggest that changes to the charter and voting guidelines
>be treated as code changes, with the stipulation that only
>PMC votes are binding.
>
-1
NO, NO, NO, NO.
Berin:
Please throw out this idea of introducing the potential for deadlock -
just get it out of your mind. While I am confident that we will reach a
good solution just working on the standing majority rules procedures
under the PMC - please don't keep poluting this with notions that set
precedence of no-majority opinion. Your comment about treating these
subjects as code implicitly introduces the potential for veto - and drag
us back to a potential environment of unresolved issues. Maybe you have
not had to put up with this - but let me be real clear - if the Avalon
PMC procedures introduce anything that have the potential to block a
qualified majority (i.e. two-thirds) on what and who we are - and simple
majority on the rest of the things we have to deal with - then you, I,
and the rest of us have learnt NOTHING from the recent past.
I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN.
NOT EVER - NEVER.
>That allows a PMC member to veto
>a change with proper justification.
>
Incorrect - any justification - feeble, profound, fantasy, etc. and
nothing to fallback on. We have today a majority voting process. We can
change that thought a majority vote. That's it - there are no other
rules applicable here. Please - just use the structure we have and don't
imply anything different with a PMC vote.
>Proper justification
>should also have a counter-proposal so that the rest of
>the PMC knows *how* to rectify the situation.
>
Just image for a moment that I really object to something (like your
ideas about voting on the PMC). And lets assume that your model is in
place. And lets assume that you and I disagree on something similar. And
lets assume that my arguments and your arguments are both well prepared
and rationale. Your solution creates a deadlock - you have destroyed the
intrinsic value of the PMC - and that it be able to do things when such
need arrives. You don't need to look very far back into Avalon history
to see evidence of this. I'm not ready to bet the form on that not
happening again.
Today - we have a majority rules on the PMC.
In the meantime - please not more assertions of what rules apply - there
are rules already in place. Lets focus on charter - not procedure - and
drop any discussion about policy to apply with result to charter or
policy evolution. It simple - a majority of the PMC voter to change the
charter - the change gets escalated to the Board, the board does it
stuff. If that's no ok - then raise a vote on the PMC list.
----------ooo0ooo-----------
You may sense a certain aggression/frustration here. That is brought
about by the inability of this community to deal with the problems back
in July/August - it was complicated by the inability of the Jakarta PMC
to address the issue. Even the board didn't address the issue on the
table at the time. Nobody took a position - not structure in the entire
Apache organization was willing to step in with a closure. Yes - Pete
got kicked - but that wasn't the subject of the Jakarta/Board discussion
before - that was probably more of a surprise to me than to any of you.
What I do know is that those types issues MUST be address by the Avalon
PMC. If you continue along the lines your describing - your just
creating the comfortable environment where you simply isolate yourself
away from the potential of having to take a difficult decision.
As a PMC member - I REFUSE to let a similar situation arise for other
members of the community. I will do everything I can to ensure that the
PMC is an instrument that has balls and ability. And I'm confident that
providing those attributes are held up with respect - that we will never
need to use them. Today the PMC has balls - please don't try to take
that away. Its abilities will evolve through attention and consideration
to the charter and procedures, and progressively, through respect from a
united community.
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: Avalon voting process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > > [The Incubator voting process] addresses voting
> > > process of the community at large, but does not
> > > address the voting process of the PMC.
> > Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
> Sounds good.
"Section 5.8. Quorum and Voting. A majority of the number of directors fixed
in accordance with these Bylaws shall constitute a quorum for the
transaction of business. The vote of a majority of the directors present at
a meeting at which a quorum is present shall be the act of the Board of
Directors."
Am I correct in rewriting this as:
"Quorum and Voting. A majority of the number of PMC members shall constitute
a quorum for the transaction of business. The vote [on procedural issues] of
a majority of the members [during some period within] which a quorum [votes]
shall be the act of the PMC."
This incorporates the ASF Board voting bylaw, exchanges the meeting for a
period (TBD), and clarifies that it addresses procedural issues (as
discussed by http://incubator.apache.org/drafts/voting.html).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > > [The Incubator voting process] addresses voting
> > > process of the community at large, but does not
> > > address the voting process of the PMC.
> > Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
> Sounds good.
"Section 5.8. Quorum and Voting. A majority of the number of directors fixed
in accordance with these Bylaws shall constitute a quorum for the
transaction of business. The vote of a majority of the directors present at
a meeting at which a quorum is present shall be the act of the Board of
Directors."
Am I correct in rewriting this as:
"Quorum and Voting. A majority of the number of PMC members shall constitute
a quorum for the transaction of business. The vote [on procedural issues] of
a majority of the members [during some period within] which a quorum [votes]
shall be the act of the PMC."
This incorporates the ASF Board voting bylaw, exchanges the meeting for a
period (TBD), and clarifies that it addresses procedural issues (as
discussed by http://incubator.apache.org/drafts/voting.html).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > > [The Incubator voting process] addresses voting
> > > process of the community at large, but does not
> > > address the voting process of the PMC.
> > Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
> Sounds good.
"Section 5.8. Quorum and Voting. A majority of the number of directors fixed
in accordance with these Bylaws shall constitute a quorum for the
transaction of business. The vote of a majority of the directors present at
a meeting at which a quorum is present shall be the act of the Board of
Directors."
Am I correct in rewriting this as:
"Quorum and Voting. A majority of the number of PMC members shall constitute
a quorum for the transaction of business. The vote [on procedural issues] of
a majority of the members [during some period within] which a quorum [votes]
shall be the act of the PMC."
This incorporates the ASF Board voting bylaw, exchanges the meeting for a
period (TBD), and clarifies that it addresses procedural issues (as
discussed by http://incubator.apache.org/drafts/voting.html).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > [The Incubator voting process] addresses voting
> > process of the community at large, but does not
> > address the voting process of the PMC.
>
> Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
Sounds good.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > [The Incubator voting process] addresses voting
> > process of the community at large, but does not
> > address the voting process of the PMC.
>
> Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
Sounds good.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > [The Incubator voting process] addresses voting
> > process of the community at large, but does not
> > address the voting process of the PMC.
>
> Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
Sounds good.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> [The Incubator voting process] addresses voting
> process of the community at large, but does not
> address the voting process of the PMC.
Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
> Sent: den 4 december 2002 18:10
> To: 'Avalon Developers List'
> Subject: Avalon voting process
>
>
> I propose that we follow the voting process outlined
> by Incubator. It is standard across all the projects
> I have seen. It addresses voting process of the community
> at large, but does not address the voting process of
> the PMC.
+1
> I still have yet to see other charters besides the XML
> one, and voting guidelines do not constitute a charter.
> I suggest that changes to the charter and voting guidelines
> be treated as code changes, with the stipulation that only
> PMC votes are binding. That allows a PMC member to veto
> a change with proper justification. Proper justification
> should also have a counter-proposal so that the rest of the
> PMC knows *how* to rectify the situation.
+1
I sent in a couple of questions and suggestions in:
http://marc.theaimsgroup.com/?l=avalon-apps-dev&m=103900145220413&w=2
> Regarding Avalon membership, we should follow the Apache
> bylaws Article IV (4). Membership meaning committers, and
> PMC.
+1, though this in some points conflict with the proposed
charter (for example, in the bylaws 2/3 majority is enough
to kick someone out, in the charter it is unanimous).
> In regards to the definition of Quorum, we should follow
> the Apache bylaws Article III (3) Section 3.9.
+1
> Are we on board with this?
Almost.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> [The Incubator voting process] addresses voting
> process of the community at large, but does not
> address the voting process of the PMC.
Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
> Sent: den 4 december 2002 18:10
> To: 'Avalon Developers List'
> Subject: Avalon voting process
>
>
> I propose that we follow the voting process outlined
> by Incubator. It is standard across all the projects
> I have seen. It addresses voting process of the community
> at large, but does not address the voting process of
> the PMC.
+1
> I still have yet to see other charters besides the XML
> one, and voting guidelines do not constitute a charter.
> I suggest that changes to the charter and voting guidelines
> be treated as code changes, with the stipulation that only
> PMC votes are binding. That allows a PMC member to veto
> a change with proper justification. Proper justification
> should also have a counter-proposal so that the rest of the
> PMC knows *how* to rectify the situation.
+1
I sent in a couple of questions and suggestions in:
http://marc.theaimsgroup.com/?l=avalon-apps-dev&m=103900145220413&w=2
> Regarding Avalon membership, we should follow the Apache
> bylaws Article IV (4). Membership meaning committers, and
> PMC.
+1, though this in some points conflict with the proposed
charter (for example, in the bylaws 2/3 majority is enough
to kick someone out, in the charter it is unanimous).
> In regards to the definition of Quorum, we should follow
> the Apache bylaws Article III (3) Section 3.9.
+1
> Are we on board with this?
Almost.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> [The Incubator voting process] addresses voting
> process of the community at large, but does not
> address the voting process of the PMC.
Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon voting process
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
> Sent: den 4 december 2002 18:10
> To: 'Avalon Developers List'
> Subject: Avalon voting process
>
>
> I propose that we follow the voting process outlined
> by Incubator. It is standard across all the projects
> I have seen. It addresses voting process of the community
> at large, but does not address the voting process of
> the PMC.
+1
> I still have yet to see other charters besides the XML
> one, and voting guidelines do not constitute a charter.
> I suggest that changes to the charter and voting guidelines
> be treated as code changes, with the stipulation that only
> PMC votes are binding. That allows a PMC member to veto
> a change with proper justification. Proper justification
> should also have a counter-proposal so that the rest of the
> PMC knows *how* to rectify the situation.
+1
I sent in a couple of questions and suggestions in:
http://marc.theaimsgroup.com/?l=avalon-apps-dev&m=103900145220413&w=2
> Regarding Avalon membership, we should follow the Apache
> bylaws Article IV (4). Membership meaning committers, and
> PMC.
+1, though this in some points conflict with the proposed
charter (for example, in the bylaws 2/3 majority is enough
to kick someone out, in the charter it is unanimous).
> In regards to the definition of Quorum, we should follow
> the Apache bylaws Article III (3) Section 3.9.
+1
> Are we on board with this?
Almost.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>