avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: Avalon voting process
Date Wed, 04 Dec 2002 18:36:51 GMT
One addendum I want to make clear.

In addition to the text on Incubator's voting page,
I highly recommend the following stipulation:

*****  ALL vetoes MUST be accompanied with a reasonable
explanation of the grievance AND a counter proposal that
would remedy the situation.  Any veto that fails to
comply with BOTH of those requirements is invalid.

Vetoes referring to code must have a _technical_ reason.
Vetoes referring to PMC modification of the charter and
bylaws must have a reasonable political/legal reason.


If the counter proposal is to leave the original code/
charter alone, then it needs to be explicitly stated.


GOOD EXAMPLES
-------------

-1  The allowing vetoes of any sort block progress.  I
    suggest we remove the ability to veto anything.

-1  The proposed "fix" introduces some serious architectural
    defects (please include a list).  I suggest we leave
    the code alone until we find a cure that is not
    worse than the problem.


BAD EXAMPLES
------------

-1

-1  Vetoes block progress.

-1  Your fix sucks.

The differences between the two should be readily apparent.
I don't want vetoes to be abused as they have been in the
past.  I also want the responsibility placed on the vetoer
to provide the suitable explanation as to #1 what the problem
is, and #2 how it can be resolved in a way that would make
you happy.

It is the PMC's responsibility to ensure that this is happening,
but we must be on board with a proposal like this.  A binding
veto must comply with the guidelines set forth above.

I do support the ability to veto, esp. on important things.
If they are used wisely and judiciously, we can learn more
than simply railroading something through with majority or
even 2/3 consensus.

> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
> 
> 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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message