avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepanossov, Kirill" <kstep...@lehman.com>
Subject RE: Avalon voting process
Date Wed, 04 Dec 2002 21:03:50 GMT
Sorry for noise here...

but it looks both Berin and Stephen are right - the existence of veto as
well as majority voting can be abused and both your justification are
correct. Well... one of you is optimistic the other one is pessimistic with
regards to "ability" of Avalon community and its developers... so why
wouldn't you just look at what/who you have now in board and then based on
that knowledge come to compromise conclusion... or just assign a
person("judge"?) who should decide if the veto is valid in arguments ?

-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@citi-us.com]
Sent: Wednesday, December 04, 2002 3:34 PM
To: 'Avalon Developers List'
Subject: RE: Avalon voting process

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


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

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

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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

This message is intended only for the personal and confidential use of the designated recipient(s)
named above.  If you are not the intended recipient of this message you are hereby notified
that any review, dissemination, distribution or copying of this message is strictly prohibited.
 This communication is for information purposes only and should not be regarded as an offer
to sell or as a solicitation of an offer to buy any financial product, an official confirmation
of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot
be guaranteed to be secure or error-free.  Therefore, we do not represent that this information
is complete or accurate and it should not be relied upon as such.  All information is subject
to change without notice.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message