Voting Considerations

Apache voting practice from http://httpd.apache.org/dev/guidelines.html:

Any of the Apache Developers may vote on any issue or action item. However, the only binding votes are those cast by active members of the Apache Group; if the vote is about a change to source code or documentation, the primary author of what is being changed may also cast a binding vote on that issue. All other votes are non-binding. All developers are encouraged to participate in decisions, but the decision itself is made by those who have been long-time contributors to the project. In other words, the Apache Project is a minimum-threshold meritocracy.

The act of voting carries certain obligations -- voting members are not only stating their opinion, they are agreeing to help do the work of the Apache Project. Since we are all volunteers, members often become inactive for periods of time in order to take care of their "real jobs" or devote more time to other projects. It is therefore unlikely that the entire group membership will vote on every issue. To account for this, all voting decisions are based on a minimum quorum.

Each vote can be made in one of three flavors:+1Yes, agree, or the action should be performed. On some issues, this vote is only binding if the voter has tested the action on their own system(s).±0Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental effects if too many people abstain.-1No. On issues where consensus is required, this vote counts as aveto. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void. No veto can be overruled. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto an action item should make their opinions known to the group immediately, so that the problem can be remedied as early as possible.An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos. An action item requiring majority approval must receive at least 3 binding +1 votes and more +1votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes). All other action items are considered to have lazy approval until someone votes -1, after which point they are decided by either consensus or a majority vote, depending upon the type of action item.

Votes are tallied within the STATUS file, adjacent to the action item under vote. All votes must be either sent to the mailing list or added directly to the STATUS file entry for that action item.

Active members of the Apache Group:

Membership in the Apache PMC is by invitation only and must be approved by consensus of the active Apache PMC members. A PMC member is considered inactive by their own declaration or by not contributing in any form to the project for over six months  

Apache Action Item Types

Long Term Plans
Long term plans are simply announcements that group members are working on particular issues related to the Apache software. These are not voted on, but group members who do not agree with a particular plan, or think an alternate plan would be better, are obligated to inform the group of their feelings. In general, it is always better to hear about alternate plans prior to spending time on less adequate solutions.
Short Term Plans
Short term plans are announcements that a developer is working on a particular set of documentation or code files, with the implication that other developers should avoid them or try to coordinate their changes. This is a good way to proactively avoid conflict and possible duplication of work.
Release Plan
A release plan is used to keep all the developers aware of when a release is desired, who will be the release manager, when the repository will be frozen in order to create the release, and assorted other trivia to keep us from tripping over ourselves during the final moments. Lazy majority decides each issue in the release plan.
Release Testing
After a new release is built, colloquially termed a tarball, it must be tested before being released to the public. Majority approval is required before the tarball can be publically released.
Showstoppers
Showstoppers are issues that require a fix be in place before the next public release. They are listed in the STATUS file in order to focus special attention on the problem. An issue becomes a showstopper when it is listed as such in STATUS and remains so by lazy consensus.
Product Changes
Changes to the Apache products, including code and documentation, will appear as action items under several categories corresponding to the change status:
concept/plan
An idea or plan for a change. These are usually only listed in STATUS when the change is substantial, significantly impacts the API, or is likely to be controversial. Votes are being requested early so as to uncover conflicts before too much work is done.
proposed patch
A specific set of changes to the current product in the form of input to the patch command (a diff output).
committed change
A one-line summary of a change that has been committed to the repository since the last public release.
All product changes to the currently active repository are subject to lazy consensus. All product changes to a prior-branch (old version) repository require consensus before the change is committed.
Backport
A backport is the application of a change on the Subversion repository trunk to the a maintenance branch of the project. This is necessary in cases where an issue exists in multiple versions of the Apache HTTP Server. A fix for such an issue will typically be developed for the trunk, which is under active development.

Apache Status

The Apache Status file is integral to planning and voting:Each of the Apache Project's active source code repositories contain a file called "STATUS" which is used to keep track of the agenda and plans for work within that repository. The STATUS file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual developers are working on or want discussion about, and anything else that might be useful to help the group track progress. The active STATUS files are automatically posted to the mailing list each week.

Many issues will be encountered by the project, each resulting in zero or more proposed action items. Issues should be raised on the mailing list as soon as they are identified. Action items must be raised on the mailing list and added to the relevant STATUS file. All action items may be voted on, but not all of them will require a formal vote.