Exactly. The rest of it is simply saying the PMC Chair is the chair until they resign, or until 1 year is up. Then the PMC will nominate someone else.
- Bobby On 6/16/14, 11:29 AM, "P. Taylor Goetz" <[email protected]> wrote: >My understanding is that the PMC votes to recommend a chair, and the >board either approves (appoints) or rejects the recommendation. > >-Taylor > >On Jun 16, 2014, at 12:08 PM, Andy Feng <[email protected]> wrote: > >> Bobby: >> >> I don¹t understand the following 2 statements: >> (1) The chair of the PMC is appointed by the ASF board. >> (2) 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 >> >> Does that mean ASF board is making an appointment per PMC votes? >> >> Your document also introduce a concept of ³emeritus². >> In Hadoop, I only see one emeritus committer. What¹s the typical >>practice? >> >> Andy >> >> >> On 6/16/14, 8:35 AM, "Bobby Evans" <[email protected]> wrote: >> >>> There has been discussion about storm graduating to a top level apache >>> project in the relatively near future. This is great, but I think it >>> would >>> be good to officially adopt a set of bylaws about how the project is >>> governed. I would prefer to not change anything initially with how the >>> project actually is governed, but mostly just formalize them in an >>> official >>> document. If others feel things need to be changed, I would prefer to >>> have >>> those be separate discussions/votes assuming that what I have written >>>up >>> is >>> not fatally flawed. As such I have written up the following based off >>>of >>> the bylaws of several other Apache projects. Which for the most part >>>were >>> very similar, please let me know to fix any references to Cloud Stack, >>> Kafka, Hadoop, and Hive in here, I copied and pasted a lot. >>> >>> A few important to note in the section on electing the PMC chair, most >>> bylaws use lazy consensus but I followed the Hadoop model because lazy >>> consensus really only works for yes/no questions. I also kept the >>>annual >>> rotation of the chair, but if others disagree I am fine with dropping >>>it >>> and putting it up for a separate discussion. Also please pay close >>> attention to the different voting methods for different actions. >>> Different >>> groups each had different requirements. I put in some that I thought >>> would >>> be good, but I am very open to changing them. The only one that had >>>been >>> discussed before was for a code change, so that one I would like to >>>stay >>> the same for now. >>> >>> # Storm By-laws (Draft) >>> >>> ## 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: >>> 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 >>> Committer FAQ 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 (or 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 >>> Consensus Approval - Consensus approval requires 3 binding +1 votes >>> and >>> no binding vetoes. >>> Lazy Consensus - Lazy consensus requires no -1 votes ('silence gives >>> assent'). >>> Lazy Majority - A lazy majority vote requires 3 binding +1 votes and >>> more binding +1 votes than -1 votes. >>> Lazy 2/3 Majority - Lazy 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 codebase of the project and >>> committed by a committer. This includes source code, documentation, >>> website >>> content, etc. | Two +1s from committers (at least one from someone who >>>has >>> not authored the patch). | Active committers | 2 days from initial >>>patch >>> |JIRA or Github pull ( with notification sent to >>> [email protected]) | >>> | Release Plan | Defines the timetable and actions for a release. The >>> plan also nominates a Release Manager. | Lazy majority | Active >>>committers >>> | 3 days | [email protected] | >>> | Product Release | When a release of one of the project's products >>>is >>> ready, a vote is required to accept the release as an official release >>>of >>> the project. | Lazy Majority | 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. | Lazy 2/3 majority | Active PMC members | 7 days | >>> [email protected] | >>> | New Committer | When a new committer is proposed for the project. | >>> Lazy consensus | Active PMC members | 7 days | >>> [email protected] | >>> | New PMC Member | When a committer is proposed for the PMC. | >>> Consensus Approval | Active PMC members | 7 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 | 7 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 | 7 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. >>> | Consensus Approval | Active PMC members (excluding the committer in >>> question if a member of the PMC). | 7 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. | >>> Consensus Approval | Active PMC members (excluding the member in >>> question). >>> | 7 Days | [email protected] | >>> | Modifying Bylaws | Modifying this document. | Lazy 2/3 majority | >>> Active PMC members | 7 Days | [email protected] | >> >> >
