IMO none of the new glossary entries are worth doing. Procedural votes are votes about bylaws and other rules which you will apply to self-govern, so they deserve an appropriate treatment. "Discouraged from voting" is perhaps too harsh a sentiment, what we want those people to know is their opinion carries no *formal* weight. Procedural votes are really reserved for PMC members, and it really doesn't make sense to comment that other voters sometimes hold binding votes here- that's something bylaws need to address if that sort of thing is desired. Code vetoes, or in fact vetoes of any kind, by default are reserved for PMC members, but again bylaws can change that.
HTH On Oct 4, 2013, at 12:55 PM, Alex Harui <aha...@adobe.com> wrote: > OK, here is my next offering. The patch form is at [1] > > Some notes: > > -This offering has 3 new entries to glossary.html as well. > -I was very tempted to move the Veto sections from Voting.html to Glossary > and merge the Consensus Gauging through Silence section from Voting into > Glossary. > -I am also tempted to remove the empty section about "Procedural Votes or > Opinion Polls" but I know you folks are looking for the minimum set of > changes. > -There are some sentences in Voting I'm not sure are accurate such as: > 1) "and all others are either discouraged from voting" > 2) "procedural votes from developers and committers are sometimes > considered binding..." > 3) "Only votes by PMC members are considered binding on > code-modification issues" > For #3, Can committers who are not PMC members have veto a code change? > > Thanks, > -Alex > [1] https://paste.apache.org/9uhY > > ------------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. > > 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. > > There are essentially five types of vote: > > 1. Code modifications (including voting to accept new code donations) > > 1. Package releases > > 1. Approving people (as Committer, PMC Member, PMC Chair) > > 1. Removing people (as Committer or PMC Member) > > 1. Procedural (including approval of project bylaws) > > Votes on procedural issues follow the common format of [majority > approval](glossary.html#MajorityApproval) 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.) > > 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. > > 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). > > Votes on approving people require [consensus > approval](glossary.html#ConsensusApproval) approval. > > Votes on removing people require > [consensus-but-one](glossary.html#ConsensusButOne). > > The voting process for adding people, removing people and procedural > voting may be modified and further refined by project bylaws. If a > project's bylaws do not specify an alternative voting process then the > above process is assumed to apply. > > # 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. > > Unless otherwise specified by a project's bylaws, only [active > members)(glossary.html#ActiveMembers) who have been active in the last 6 > months may cast binding votes. A different definition of active member > may also be set in a project's bylaws. > > 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. > > # 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 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 > [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. > > # Vetos # {#Veto} > > Any vote requiring consensus or lazy consensus 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 made. 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. > > # Change History # > > October 2013: Added paragraph on Active Members, Voting Types for adding > and removing people, and what bylaws can override. > > > ------ Excerpts from glossary.mdtext ---------- > > **Active Member** {#ActiveMember} > : A person who has posted an email on any Apache mailing list, made > a change to any asset under Apache version control, or voted on a > vote thread in the past 6 months. This low bar is intended to > cover 'mature' projects that don't do much more than file quarterly > reports. > > > > **Consensus But One** {#ConsensusButOne} > : 'Consensus but one' refers to a [vote](#Vote) (sense 1) typically > used to remove a member as a Committer or PMC Member which has > completed with **at least three binding +1 votes** and **no** > [vetos](#Veto) other than the possible veto of the person > being removed. > > > **Guidelines** {#Guidelines} > : A commonly used term for [Bylaws](#ByLaws). > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
