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:[EMAIL PROTECTED]]
>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
