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] | > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
