avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Avalon voting process
Date Wed, 04 Dec 2002 19:39:53 GMT

Berin Loritsch wrote:
> 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.

I was writing the same thing when I got this mail.

+1 (actually +infinite for the counterproposal part)

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


Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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