+1 -Harsha
On Thu, Feb 19, 2015, at 07:48 AM, Melan Nimesh wrote: > +1 > > On Thu, Feb 19, 2015 at 9:08 PM, Nathan Marz <[email protected]> > wrote: > > > +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 > > > > > > -- > Melan Nimesh Jayasinghage > PGP : 4DEBD8F0 > home: http://people.apache.org/~melan/ > twitter:@melanster <http://twitter.com/melanster>
