Page History

Voting

Decisions regarding the project are made by votes on the primary project development mailing list (dev@flex.apache.org).

Where necessary, PMC voting may take place on the private Apache Flex PMC mailing list.

Votes are clearly indicated by subject line starting with [VOTE].

The vote email should indicate the voting approval type (Consensus, Lazy Consensus, Majority Approval or 2/3rds Majority Approval) and that should follow what is in these guidelines. If the voting approval type is not specified and is not covered by these guidelines it defaults to Majority Approval.

Voting is carried out by replying to the vote mail. Voting may take four flavors:

• +1 "Yes," "Agree," or "the action should be performed." In general, this vote also indicates a willingness on the behalf of the voter in "making it happen".
• +0 This vote indicates a willingness for the action under consideration to go ahead. The voter, however will not be able to help.
• -0 This vote indicates that the voter does not, in general, agree with the proposed action but is not concerned enough to prevent the action going ahead.
• -1 This is a negative vote. On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action.

You can also vote in fractions to indicate the strength of the vote, for example by voting +0.5, -0.5, +0, -0 etc etc. Only a full -1 is considered a veto and releases and consensus require 3 full +1 votes.

All participants, not just committers and PMC members, in the Flex project are encouraged to show their agreement with or against a particular action by voting.

Binding votes

For technical decisions (but not releases), the votes of committers are binding.

For PMC decisions, only the votes of PMC members are binding.

Non binding votes are still useful for those with binding votes to understand the perception of an action in the wider community.

If your vote is binding you should append "(binding)" to your vote. This helps the person running the vote to tally things correctly.

Changes made to the Apache Flex codebase are made on a Commit-then-review basis. Any change may be reverted by a veto (-1) in reply to the commit message sent when the commit is made.

Voting timeframes

Voting is open for 72 hours unless otherwise specified. When voting on release candidates the release manager at their discretion can carry over votes from the previous release candidate if there are minimal changes between release candidates. This should be indicated in the new release candidate vote.

If 72 hours pass and there's not enough votes for a resolution voting continues until cancelled or until there are enough votes for a resolution.

Cancelling Votes

A vote may be cancelled by the person who started the vote by sending an email with the subject line [VOTE][CANCEL] to the mailing list.

Vote Results

Once a vote has been taken and the required timeframe has elapsed an email should be sent to the list with results of the vote and whether the vote passed or failed with a subject line of [VOTE][RESULT].

Changing Your Vote

Anyone can change their vote until the required voting timeframe has passed and the results have been announced. Only a person's last vote counts in any total.

Approvals

These are the types of approvals that can be sought. Different actions require different types of approvals

• Consensus Approval - Consensus approval requires 3 binding +1 votes and no binding vetoes.
• Lazy Consensus - Lazy consensus requires no -1 binding votes ('silence gives assent').
• Majority Approval - A majority approval vote requires 3 binding +1 votes and more binding +1 votes than -1 votes.
• 2/3rds Majority Approval - A 2/3rds majority approval vote requires at least 3 +1 binding votes and twice as many +1 binding votes as -1 votes.

Majority Approval and 2/3 Majority Approval is based on the number of votes cast, not on the number of eligible voters.

Vetoes

A valid, binding veto cannot be overruled. A veto is only valid if it is accompanied by an explanation. The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto - merely that the veto is valid.

If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, any action that has been vetoed must be reversed in a timely manner.

Majority votes can not be vetoed.

Code Change

A change made to a codebase of the project and committed by a committer. This includes source code, documentation, website content, etc.

• Lazy Consensus of committers.

• There is no need for a formal vote. All code changes are commit then review so there's no waiting period of approval. A code change can be vetoed with a -1 vote by any other committer by replying to the commit email.

Product Release

When a release candidate of one of the project's products is ready, a vote is required to accept the release candidate as an official release of the project.

• Majority Approval of PMC members.

• The release manager can carry over of votes from previous release candidates to the new release candidate if there are minimal changes between release candidates contain no code changes or changes to legally significant documents. This can be clarified at any time in the voting process.
• If a PMC member voted on a release candidate, and the release manager creates a new one, there is no need to recheck what has been previously checked when voting on the new potential release.

New Committer

When a new committer is proposed for the project.

• Consensus of PMC members.

New PMC Member

When a committer is proposed for the PMC.

• Consensus of PMC members.

New PMC Chair

When the Chair resigns or term has come up.

• Consensus of PMC members.

Committer Removal

When removal of commit privileges is sought. Note: Such actions will also be referred to the ASF board by the PMC chair.

• 2/3rds Majority Approval of PMC members (excluding the committer in question if a member of the PMC).

PMC Member Removal

When removal of a PMC member is sought. Note: Such actions will also be referred to the ASF board by the PMC chair.

• 2/3rds Majority Approval of PMC members (excluding the person in question if a member of the PMC).

PMC Chair Removal

The chair can be removed by the ASF board.

Modifying Bylaws

Modifying this document.

• 2/3rds Majority Approval of PMC members.