Version 34 of these guidelines were voted in as the official guidelines for the Apache Flex Project on the 14th November 2013. The amendment to the voting rules was added in version 48. Since then this note was changed but there have been no rule changes.
| Apache Flex Guidelines |
Apache Flex is a project of the Apache Software Foundation. The foundation holds the copyright on Apache code including the code in the Apache Flex codebase. The code is licensed under the Apache License, Version 2.0, a commercial friendly open source software license. Apache Flex also uses several 3rd party libraries.
Apache Flex is typical of Apache projects in that it operates under a set of principles, known collectively as the "Apache Way". If you are new to Apache development, please refer to how the ASF works and how to participate.
| Roles and Responsibilities |
Users
The most important participants in the project are people who use our software. The majority of our developers start out as users and guide their development efforts from the user's perspective.
Users contribute to the Apache projects by providing feedback to developers in the form of bug reports and feature suggestions. As well, users participate in the Apache community by helping other users on mailing lists and user support forums.
Contributors
All of the volunteers who are contributing time, code, documentation, or resources to the Apache Flex Project. A contributor that makes sustained, useful contributions to the project may be invited to become a Committer.
Committers
The project's Committers are responsible for the project's technical management. Committers have write access to the projects source code repositories.
The responsibilities of an committer include:
- Upholding and promoting the Apache Way
- Helping out users
- Reviewing code check ins
- Testing releases
- Maintaining the project's shared resources, including the repository, mailing lists and website
It is up to each individual committer exactly where they focus their attention and how how much time they spend on the project.
Committer access is by invitation only and must be approved by Consensus of the PMC members.
All Apache committers are required to have a signed Contributor License Agreement (CLA) on file with the Apache Software Foundation.
Any committer can make a release candidate and call for a vote on making it an official release.
The forms of contribution are not limited to only code. It can also include code reviews, helping out users on the mailing lists, documentation, testing, etc.
A committer is considered inactive by their own declaration and can rejoin at any time.
Committers can veto code check ins but committers votes are not binding on releases.
A committer who makes a sustained contribution to the project may be invited to become a member of the PMC.
Release Manager
A Release Manager (RM) is a committer who volunteers to produce a Release Candidate.
The RM is responsible for building consensus around the content of the Release Candidate, in order to achieve a successful Product Release vote.
Project Management Committee
The Project Management Committee (PMC) for Apache Flex was created by the Apache Board. In December 2012 Apache Flex became a top level project at Apache.
The PMC is responsible to the board and the ASF for the management and oversight of the Apache Flex project.
The responsibilities of the PMC include:
- Upholding and promoting the Apache Way
- Deciding what is in a release
- Voting on releases
- Maintaining the project's shared resources, including the repository, mailing lists and website
- Speaking on behalf of the project
- Resolving any disputes (licensing or otherwise)
- Nominating new PMC members and committers
- Maintaining these guidelines of the project
Membership of the PMC is by invitation only and must be approved by Consensus of PMC members.
A PMC member is considered inactive by their own declaration and they can rejoin at any time.
Chair
The chair of the PMC is appointed by the ASF board. The chair is an office holder of the Apache Software Foundation (Vice President, Apache Flex) and has primary responsibility to the board for the management of the projects within the scope of the Apache Flex PMC. The chair reports to the board quarterly on developments within the project.
The term of chair is for one one year or until they retire. After one year the chair can elect to stand for another year or a vote by the PMC be taken for a new chair.
| Decision Making |
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.
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.
| Actions |
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.
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.