On 10/2/13 12:58 PM, "Marvin Humphrey" <mar...@rectangular.com> wrote:
>On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui <aha...@adobe.com> wrote:
>> I would like to propose a rewrite of [1] by borrowing heavily from [2]
>>but
>> making sure to emphasize that projects are allowed to have different
>>rules
>> for all of them (or is the code-commit veto required for all projects).
>> Any objections to me trying to do that?
>
>Rather than a "rewrite", I suggest proposing small, incremental,
>reversible
>changes. Governance is easy to mess up.
Well, "small, incremental" was hard to do given the significantly
different information this document must now convey. I tried to keep as
much as possible yet incorporate feedback from Doug and Roy. Below is my
proposed version, and below it is the svn diff in case that makes it
easier to see what changed. Most of the changes were made at the
beginning.
I'm sure I haven't nailed it so feel free to comment. And I'm not quite
sure how to do a table in mdtext. I'm off to sleep so I'll respond
several hours from now. Thanks for reading...
-Alex
------- Updated voting.mdtext ----------
Title: Apache Voting Process
Notice: Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
.
http://www.apache.org/licenses/LICENSE-2.0
.
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
At the Apache Software Foundation, two decisions must be made by a vote
held on a
project's mailing list. The two decisions are:
1. Code modifications,
1. Package releases
Other decisions are commonly made via votes as well, but a project may
draft by-laws
or guidelines that describe variations to the voting processes described
below.
If a project does not draft by-laws or guidelines, it is assumed that any
votes
held to make any of the decisions listed below follow the processes
described below.
Many projects make the following decisions via voting:
1. Approving a new committer
1. Approving a new PMC member
1. Approving a new PMC Chair
1. Removing a committer
1. Removing a PMC member
1. Approving by-laws or guidelines or changes to by-laws or guidelines
Many project by-laws and guidelines describe other decisions made via
voting.
Use of [lazy consensus](#LazyConsensus) is recommended for as many other
decisions as possible.
Here is a table of the default voting processes:
<table>
<tr><th>Action</th><th>Approval</th><th>Duration</th></tr>
<tr><td>Code Modification</td><td>[lazy
consensus](#LazyConsensus)</td><td>72 hours</td></tr>
<tr><td>Approve Release</td><td>[majority](#Majority)</td><td>72
hours</td></tr>
<tr><td>Approve New Committer</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
<tr><td>Approve New PMC Member</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
<tr><td>Approve New PMC Chair</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
<tr><td>Remove
Committer</td><td>[consensus-but-one](#ConsensusButOne)</td><td>72
hours</td></tr>
<tr><td>Remove PMC
Member</td><td>[consensus-but-one](#ConsensusButOne)</td><td>72
hours</td></tr>
<tr><td>Approve/Change
By-laws/Guidelines</td><td>[majority](#Majority)</td><td>72 hours</td></tr>
<tr><td>Approve Donation</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
# Binding Votes #
Who is permitted to vote is, to some extent, a project-specific thing.
However, the default rule is that for Code Modification, any committer's
veto counts,
but for all other decisions only PMC members have binding votes, and
all others have their votes considered of an indicative or advisory nature
only.
By default, only "active" PMC members may cast votes. Project's can
define their
own definition of active, but the default definition is whether that
member has
sent an email on any Apache mailing list, made a change to any asset under
Apache
version control, or voted on any vote thread. This low bar is intended to
cover
"mature" projects that don't do much other than file quarterly reports.
# Implications of Voting #
In some cases and communities, the exercise of a vote carries some
responsibilities that may not be immediately obvious. For example, in some
cases a favourable vote carries the implied message 'I approve **and** I'm
willing to help.' Also, an unfavourable vote may imply that 'I disapprove,
but I have an alternative and will help with that alternative.'
The tacit implications of voting should be spelt out in the community's
guidelines. However, **in no case** may someone's vote be considered
invalid if the implied commitment doesn't appear to be met; a vote is a
formal expression of opinion, *not* of commitment.
If the [R-T-C](#ReviewThenCommit) policy is in effect, a positive vote
carries the very strong implied message, 'I have tested this patch myself,
and found it good.' Similarly, a negative vote usually means that the patch
was tested and found to be *not* -good, although the veto (for such it is
in this case) may be based on other technical grounds.
# Expressing Votes: +1, 0, -1, and Fractions #
The voting process in Apache may seem more than a little weird if you've
never encountered it before. Votes are represented as numbers between -1
and +1, with '-1' meaning 'no' and '+1' meaning 'yes.'
The in-between values are indicative of how strongly the voting individual
feels. Here are some examples of fractional votes and ways in which they
*might* be intended and interpreted:
- +0: 'I don't feel strongly about it, but I'm okay with this.'
- -0: 'I won't get in the way, but I'd rather we didn't do this.'
- -0.5: 'I don't like this idea, but I can't find any rational
justification for my feelings.'
- ++1: 'Wow! I like this! Let's *do* it!'
- -0.9: 'I *really* don't like this, but I'm not going to stand in the way
if everyone else wants to go ahead with it.'
- +0.9: 'This is a cool idea and i like it, but I don't have time/the
skills necessary to help out.'
## Votes on Package Releases ## {#ReleaseVotes}
Votes on whether a package is ready to be released use
[majority approval](glossary.html#MajorityApproval) --
i.e. at least three PMC members must vote affirmatively
for release, and there must be more positive than negative votes.
**Releases may not be vetoed.**
Generally the community
will cancel the release vote if anyone identifies serious problems, but
in most cases the ultimate decision,
lies with the individual serving as release manager. The
specifics of the process may vary from project to project, but the 'minimum
quorum of three +1 votes' rule is universal.
# Consensus # {#Consensus}
Any approval requiring consensus requires a minimum of 3 +1 votes and
may be stopped dead in its tracks by a -1 vote
by a qualified voter. This constitutes a veto, and it cannot be overruled
nor overridden by anyone. Vetos stand until and unless withdrawn by their
casters.
To prevent vetos from being used capriciously, they must be accompanied by
a technical justification showing why the change is bad (opens a security
exposure, negatively affects performance, *etc.* ), or why the decision
should not be approved. A veto without a
justification is invalid and has no weight.
# Consensus Gauging through Silence # {#LazyConsensus}
An alternative to voting that is sometimes used to measure the
acceptability of something is the concept of
[lazy consensus](glossary.html#LazyConsensus).
Lazy consensus is simply an announcement of 'silence gives assent.' When
someone wants to determine the sense of the community this way, it might do
so with a mail message such as:
: "The patch below fixes bug #8271847; if no-one objects within three
days, I'll assume lazy consensus and commit it."
Lazy consensus cannot be applied to code changes when the
[review-then-commit](glossary.html#ReviewThenCommit) policy is in effect.
# Reasons for Votes #
People tend to avoid conflict and thrash around looking for something to
substitute - somebody in charge, a rule, a process, stagnation. None of
these tend to be very good substitutes for doing the hard work of resolving
the conflict.
------------- svn diff ---------------
Index: voting.mdtext
===================================================================
--- voting.mdtext (revision 1528717)
+++ voting.mdtext (working copy)
@@ -16,52 +16,61 @@
specific language governing permissions and limitations
under the License.
-Because one of the fundamental aspects of accomplishing things within the
-Apache framework is doing so by consensus, there obviously needs to be a
-way to tell whether it has been reached. This is done by voting.
+At the Apache Software Foundation, two decisions must be made by a vote
held on a
+project's mailing list. The two decisions are:
-There are essentially three types of vote:
-
1. Code modifications,
1. Package releases
-1. Procedural
+Other decisions are commonly made via votes as well, but a project may
draft by-laws
+ or guidelines that describe variations to the voting processes described
below.
+If a project does not draft by-laws or guidelines, it is assumed that any
votes
+held to make any of the decisions listed below follow the processes
described below.
-Votes on procedural issues follow the common format of majority rule
unless
-otherwise stated. That is, if there are more favourable votes than
-unfavourable ones, the issue is considered to have passed -- regardless of
-the number of votes in each category. (If the number of votes seems too
-small to be representative of a community consensus, the issue is
typically
-not pursued. However, see the description of [lazy
-consensus](#LazyConsensus) for a modifying factor.)
+Many projects make the following decisions via voting:
-Votes on code modifications follow a different model. In this scenario, a
-negative vote constitutes a [veto](#Veto) , which cannot be overridden.
-Again, this model may be modified by a [lazy consensus](#LazyConsensus)
-declaration when the request for a vote is raised, but the full-stop
nature
-of a negative vote is unchanged. Under normal (non-lazy consensus)
-conditions, the proposal requires three positive votes and no negative
ones
-in order to pass; if it fails to garner the requisite amount of support,
it
-doesn't -- and typically is either withdrawn, modified, or simply allowed
-to languish as an open issue until someone gets around to removing it.
+1. Approving a new committer
-Votes on whether a package is ready to be released or not use yet a
-different mechanism: are there are least three binding votes in favour of
-the release? See more about this [below](#ReleaseVotes).
+1. Approving a new PMC member
+1. Approving a new PMC Chair
+
+1. Removing a committer
+
+1. Removing a PMC member
+
+1. Approving by-laws or guidelines or changes to by-laws or guidelines
+
+Many project by-laws and guidelines describe other decisions made via
voting.
+Use of [lazy consensus](#LazyConsensus) is recommended for as many other
decisions as possible.
+
+Here is a table of the default voting processes:
+
+<table>
+<tr><th>Action</th><th>Approval</th><th>Duration</th></tr>
+<tr><td>Code Modification</td><td>[lazy
consensus](#LazyConsensus)</td><td>72 hours</td></tr>
+<tr><td>Approve Release</td><td>[majority](#Majority)</td><td>72
hours</td></tr>
+<tr><td>Approve New Committer</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
+<tr><td>Approve New PMC Member</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
+<tr><td>Approve New PMC Chair</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
+<tr><td>Remove
Committer</td><td>[consensus-but-one](#ConsensusButOne)</td><td>72
hours</td></tr>
+<tr><td>Remove PMC
Member</td><td>[consensus-but-one](#ConsensusButOne)</td><td>72
hours</td></tr>
+<tr><td>Approve/Change
By-laws/Guidelines</td><td>[majority](#Majority)</td><td>72 hours</td></tr>
+<tr><td>Approve Donation</td><td>[consensus](#Consensus)</td><td>72
hours</td></tr>
+
# Binding Votes #
-Who is permitted to vote is, to some extent, a community-specific thing.
-However, the basic rule is that only PMC members have binding votes, and
-all others are either discouraged from voting (to keep the noise down) or
-else have their votes considered of an indicative or advisory nature only.
+Who is permitted to vote is, to some extent, a project-specific thing.
+However, the default rule is that for Code Modification, any committer's
veto counts,
+but for all other decisions only PMC members have binding votes, and
+all others have their votes considered of an indicative or advisory
nature only.
-That's the general rule. In actual fact, things tend to be a little
looser,
-and procedural votes from developers and committers are sometimes
-considered binding if the voter has acquired enough merit and respect in
-the community. Only votes by PMC members are considered binding on
-code-modification issues, however.
+By default, only "active" PMC members may cast votes. Project's can
define their
+own definition of active, but the default definition is whether that
member has
+sent an email on any Apache mailing list, made a change to any asset
under Apache
+version control, or voted on any vote thread. This low bar is intended
to cover
+"mature" projects that don't do much other than file quarterly reports.
# Implications of Voting #
@@ -107,26 +116,6 @@
- +0.9: 'This is a cool idea and i like it, but I don't have time/the
skills necessary to help out.'
-Votes should generally be permitted to run for at least 72 hours to
provide
-an opportunity for all concerned persons to participate regardless of
their
-geographic locations.
-
-## Votes on Code Modification ##
-
-For code-modification votes, +1 votes are in favour of the proposal, but
-1
-votes are [vetos](#Veto) and kill the proposal dead until all vetoers
-withdraw their -1 votes.
-
-Unless a vote has been declared as using [lazy consensus](#LazyConsensus)
,
-three +1 votes are required for a code-modification proposal to pass.
-
-Whole numbers are recommended for this type of vote, as the opinion being
-expressed is Boolean: 'I approve/do not approve of this change.'
-
-## Procedural Votes or Opinion Polls ##
-
-*TBS*
-
## Votes on Package Releases ## {#ReleaseVotes}
Votes on whether a package is ready to be released use
@@ -141,16 +130,17 @@
specifics of the process may vary from project to project, but the
'minimum
quorum of three +1 votes' rule is universal.
-# Vetos # {#Veto}
+# Consensus # {#Consensus}
-A code-modification proposal may be stopped dead in its tracks by a -1
vote
+Any approval requiring consensus requires a minimum of 3 +1 votes and
+may be stopped dead in its tracks by a -1 vote
by a qualified voter. This constitutes a veto, and it cannot be overruled
nor overridden by anyone. Vetos stand until and unless withdrawn by their
casters.
To prevent vetos from being used capriciously, they must be accompanied by
a technical justification showing why the change is bad (opens a security
-exposure, negatively affects performance, *etc.* ). A veto without a
+exposure, negatively affects performance, *etc.* ), or why the decision
should not be approved. A veto without a
justification is invalid and has no weight.
# Consensus Gauging through Silence # {#LazyConsensus}
------------- end svn diff ------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
