+1 On Thu, Feb 19, 2015 at 8:15 AM, Andy Feng <[email protected]> wrote:
> +1 > > Andy Feng > > Sent from my iPhone > > > On Feb 18, 2015, at 1:43 PM, P. Taylor Goetz <[email protected]> wrote: > > > > As a follow-up to the previous discussion regarding adopting project > bylaws, I’d like to start an official VOTE to formally adopt the bylaws as > listed below. > > > > Please vote on adopting the proposed bylaws. > > > > [+1] Adopt the bylaws as listed > > [+0] No opinion > > [-1] Do not adopt the bylaws because… > > > > This vote will be 2/3 Majority as described below, and open for 6 days. > > > > -Taylor > > > > ----------------------------- > > > > # Apache Storm Project Bylaws > > > > > > ## Roles and Responsibilities > > > > Apache projects define a set of roles with associated rights and > responsibilities. These roles govern what tasks an individual may perform > within the project. The roles are defined in the following sections: > > > > ### 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: > > > > Contributors are all of the volunteers who are contributing time, code, > documentation, or resources to the Storm Project. A contributor that makes > sustained, welcome contributions to the project may be invited to become a > Committer, though the exact timing of such invitations depends on many > factors. > > > > ### Committers: > > > > The project's Committers are responsible for the project's technical > management. Committers have access to all project source repositories. > Committers may cast binding votes on any technical discussion regarding > storm. > > > > Committer access is by invitation only and must be approved by lazy > consensus of the active PMC members. A Committer is considered emeritus by > their own declaration or by not contributing in any form to the project for > over six months. An emeritus Committer may request reinstatement of commit > access from the PMC. Such reinstatement is subject to lazy consensus > approval of active PMC members. > > > > All Apache Committers are required to have a signed Contributor License > Agreement (CLA) on file with the Apache Software Foundation. There is a > [Committers' FAQ](https://www.apache.org/dev/committers.html) which > provides more details on the requirements for Committers. > > > > A Committer who makes a sustained contribution to the project may be > invited to become a member of the PMC. The form of contribution is not > limited to code. It can also include code review, helping out users on the > mailing lists, documentation, testing, etc. > > > > ### Project Management Committee(PMC): > > > > The PMC is responsible to the board and the ASF for the management and > oversight of the Apache Storm codebase. The responsibilities of the PMC > include: > > > > * Deciding what is distributed as products of the Apache Storm project. > In particular all releases must be approved by the PMC. > > * Maintaining the project's shared resources, including the codebase > repository, mailing lists, websites. > > * Speaking on behalf of the project. > > * Resolving license disputes regarding products of the project. > > * Nominating new PMC members and Committers. > > * Maintaining these bylaws and other guidelines of the project. > > > > Membership of the PMC is by invitation only and must be approved by a > consensus approval of active PMC members. A PMC member is considered > "emeritus" by their own declaration or by not contributing in any form to > the project for over six months. An emeritus member may request > reinstatement to the PMC. Such reinstatement is subject to consensus > approval of the active PMC members. > > > > 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 > Storm) and has primary responsibility to the board for the management of > the projects within the scope of the Storm PMC. The chair reports to the > board quarterly on developments within the Storm project. > > > > The chair of the PMC is rotated annually. When the chair is rotated or > if the current chair of the PMC resigns, the PMC votes to recommend a new > chair using Single Transferable Vote (STV) voting. See > http://wiki.apache.org/general/BoardVoting for specifics. The decision > must be ratified by the Apache board. > > > > ## Voting > > > > Decisions regarding the project are made by votes on the primary project > development mailing list ([email protected]). Where necessary, PMC > voting may take place on the private Storm PMC mailing list. Votes are > clearly indicated by subject line starting with [VOTE]. Votes may contain > multiple items for approval and these should be clearly separated. Voting > is carried out by replying to the vote mail. Voting may take four flavors: > > > > | Vote | Meaning | > > |------|---------| > > | +1 | 'Yes,' 'Agree,' or 'the action should be performed.' | > > | +0 | Neutral about the proposed action. | > > | -0 | Mildly negative, but not enough so to want to block it. | > > | -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. | > > > > All participants in the Storm project are encouraged to show their > agreement with or against a particular action by voting. For technical > decisions, only the votes of active Committers are binding. Non-binding > votes are still useful for those with binding votes to understand the > perception of an action in the wider Storm community. For PMC decisions, > only the votes of active PMC members are binding. > > > > Voting can also be applied to changes already made to the Storm > codebase. These typically take the form of a veto (-1) in reply to the > commit message sent when the commit is made. Note that this should be a > rare occurrence. All efforts should be made to discuss issues when they are > still patches before the code is committed. > > > > Only active (i.e. non-emeritus) Committers and PMC members have binding > votes. > > > > ## Approvals > > > > These are the types of approvals that can be sought. Different actions > require different types of approvals > > > > | Approval Type | Criteria | > > |---------------|----------| > > | Consensus Approval | Consensus approval requires 3 binding +1 votes > and no binding vetoes. | > > | Majority Approval | Majority approval requires at least 3 binding +1 > votes and more +1 votes than -1 votes. | > > | Lazy Consensus | Lazy consensus requires no -1 votes ('silence gives > assent'). | > > | 2/3 Majority | 2/3 majority votes requires at least 3 votes and twice > as many +1 votes as -1 votes. | > > > > ### Vetoes > > > > A valid, binding veto cannot be overruled. If a veto is cast, it must be > accompanied by a valid reason explaining the reasons for the veto. 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. > > > > ## Actions > > > > This section describes the various actions which are undertaken within > the project, the corresponding approval required for that action and those > who have binding votes over the action. > > > > | Actions | Description | Approval | Binding Votes | Minimum Length | > Mailing List | > > > |---------|-------------|----------|---------------|----------------|--------------| > > | Code Change | A change made to a source code of the project and > committed by a Committer. | A minimum of one +1 from a Committer other than > the one who authored the patch, and no -1s. The code can be committed after > the first +1. If a -1 is received to the patch within 7 days after the > patch was posted, it may be reverted immediately if it was already merged. > | Active Committers | 1 day from initial patch (**Note:** Committers should > consider allowing more time for review based on the complexity and/or > impact of the patch in question.)|JIRA or Github pull ( with notification > sent to [email protected]) | > > | Non-Code Change | A change made to a repository of the project and > committed by a Committer. This includes documentation, website content, > etc., but not source code, unless only comments are being modified. | Lazy > Consensus | Active Committers | At the discression of the Committer |JIRA > or Github pull (with notification sent to [email protected]) | > > | Product Release | A vote is required to accept a proposed release as > an official release of the project. Any Committer may call for a release > vote at any point in time. | Majority Approval | Active PMC members | 3 > days | [email protected] | > > | Adoption of New Codebase | When the codebase for an existing, released > product is to be replaced with an alternative codebase. If such a vote > fails to gain approval, the existing code base will continue. This also > covers the creation of new sub-projects and submodules within the project > as well as merging of feature branches. | 2/3 Majority | Active PMC members > | 6 days | [email protected] | > > | New Committer | When a new Committer is proposed for the project. | > Consensus Approval | Active PMC members | 3 days | > [email protected] | > > | New PMC Member | When a member is proposed for the PMC. | Consensus > Approval | Active PMC members | 3 days | [email protected] | > > | Emeritus PMC Member re-instatement | When an emeritus PMC member > requests to be re-instated as an active PMC member. | Consensus Approval | > Active PMC members | 6 days | [email protected] | > > | Emeritus Committer re-instatement | When an emeritus Committer > requests to be re-instated as an active Committer. | Consensus Approval | > Active PMC members | 6 days | [email protected] | > > | 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/3 > Majority | Active PMC members (excluding the Committer in question if a > member of the PMC). | 6 Days | [email protected] | > > | 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/3 > Majority | Active PMC members (excluding the member in question). | 6 Days > | [email protected] | > > | Modifying Bylaws | Modifying this document. | 2/3 Majority | Active > PMC members | 6 Days | [email protected] | > > > -- Twitter: @nathanmarz http://nathanmarz.com
