OMC-Voting

Consensus Gauging through Voting

Introduction

Because one of the fundamental aspects of accomplishing things within the OMC Project 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 three types of vote:

1. Procedural
2. Code modifications,
3. Package releases

Procedural

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 for a modifying factor.

Code Modifications

Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a veto, which cannot be overridden. Again, this model may be modified by a lazy consensus 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 the modification fails to garner the requisite amount of support, it doesn't pass, and typically is either withdrawn, modified, or simply allowed to languish as an open issue until someone gets around to removing it.

Package Release

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?

Who Can Vote

The basic rule is that only PMC members have binding votes.

Non-PMC Committers, and contributors, are encouraged to vote. However, their votes are considered of an indicative or advisory nature only.

Implications of Voting

The OMC Project PMC determines the implications of voting.

The exercise of a vote may carry some responsibilities that may not be immediately obvious. For example, should a favourable vote carry the implied message "I approve and I'm willing to help", or just, "I approve, but I am not necessarily willing to help." Also, an unfavourable vote may imply that "I disapprove, but I have an alternative and will help with that alternative."

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 RTC policy (see Commit Policies, below) 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 unacceptable, although the veto (for such it is in this case) may be based on other technical grounds.

Expressing Votes:

+1, 0, -1, and +/- 0 (implies 'leaning toward ...')

The voting process 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 voting examples and ways in which they might be intended and interpreted:

   * +1: 'I am in favor of this and wish to see it move forward'
   * +0: 'I don't feel strongly about it, but I'm okay with this.' or 'I'm leaning towards yes'
   * -0: 'I won't get in the way, but I'd rather we didn't do this.' or 'I'm leaning toward no'
   * -1: 'I am against this and do not want to see it move forward' (This vote must be followed by and explanation or alternative idea.)

Occationally a vote or expression such as the following may be seen. This type of vote is equivalant to a +1 but allows the voter to communicate a greater acceptance of the idea.

   * ++1: 'Wow! I like this! Let's do it!'

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 and kill the proposal dead until all vetoers withdraw their -1 votes.

Unless a vote has been declared as using lazy consensus, 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

Votes on Package Releases

Votes on whether a package is ready to be released follow a format similar to majority approval, except that the decision is officially determined solely by whether at least three +1 votes were registered. Releases may not be vetoed. Generally the community will table the vote to release if anyone identifies serious problems. However, in most cases the ultimate decision, after three or more positive votes have been garnered, lies with the individual serving as release manager.

Vetos

A code-modification proposal 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, breaks DMTF Standard <spec, profile, etc> etc.). A veto without a justification is invalid and has no weight.

Consensus Gauging through Silence

An alternative to voting that is sometimes used to measure the acceptability of something is the concept of lazy consensus.

Lazy consensus is simply an announcement of "silence gives assent." When someone wants to determine the sense of the community this way, they 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 policy is in effect.

Reasons for Votes

People tend to avoid conflict and thrash around looking for something to substitute, for example, somebody in charge, a rule, a process, or stagnation. None of these tend to be very good substitutes for doing the hard work of resolving the conflict.

Commit Policies

• RTC: Review-Then-Commit
  • Commit policy that requires that all changes receive consensus approval in order to be committed.
• CTR: Commit-Then-Review
  • A policy governing code changes which permits developers to make changes at will, with the possibility of being retroactively vetoed. CTR is an application of decision making through lazy consensus. The CTR model is useful in rapid-prototyping environments, but because of the lack of mandatory review it may permit more bugs through than the RTC alternative.