On 12/12/12 6:30 PM, "Chip Childers" <chip.child...@sungard.com> wrote:
>Hi all, > >I'd like to start a conversation about our project bylaws. This is >something that an Apache project doesn't absolutely require, but I >believe that some of the larger TLP's have found it to be valuable. >More specifically, I would like to see us discuss and agree on the >contents of the bylaws prior to graduating (hence why I'm bringing it >up now). If others don't agree that this is the time or place, or >that they are not needed, then please say so! > >For the draft below, I started with the Hadoop project's version >(found here: http://hadoop.apache.org/bylaws.html ), and then took a >stab at editing the contents a bit to match some of the conventions >that we have been using as a community already. > >In the draft, I'm assuming that the CloudStack trademark will be >transfered at or before the time of graduation from the incubator, and >therefore retained the statements about ASF owning the trademark >(which is not yet true AFAIK). > >I've also retained the references to the PMC, instead of what is >currently the PPMC. For the purpose of this discussion, consider PMC >to be equal to the PPMC today (with the obvious qualification that we >are under the Incubator PMC today). > >Section 2.1.4 talks about the PMC being responsible to the board, but >that will only be the case after we graduate. > >Please take a look, and let's start the process of figuring out what's >good / bad / otherwise about the draft. All opinions are welcome! > >-chip > > >***************************************************** >Draft Apache CloudStack Project Bylaws >***************************************************** > >1. Introduction > >1.1. This document defines the bylaws under which the Apache >CloudStack project operates. It defines the roles and responsibilities >of the project, who may vote, how voting works, how conflicts are >resolved, etc. > >1.2. CloudStack is a project of the Apache Software Foundation. The >foundation holds the trademark on the name "CloudStack" and copyright >on Apache code including the code in the CloudStack codebase. The >foundation FAQ explains the operation and background of the >foundation. > >1.3. CloudStack 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 the Incubator >project for more information on how Apache projects operate. > >2. 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: > >2.1. Users > >The most important participants in the project are people who use our >software. 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. There are users of CloudStack-derived products (e.g., users of commercial distributions). Their feedback may arrive in the form of feature proposals from product managers of those commercial distributions. This is valuable to the project. I feel that this kind of contribution needs to be welcomed and acknowledged. > >2.2. Contributors > >Contributors are all of the volunteers who are contributing time, >code, documentation, or resources to the CloudStack 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. 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. I know Sebastien had a issue with the "etc" as well. Well documented feature proposals are also contributions. > >2.3. Committers > >The project's Committers are responsible for the project's technical >management. Committers have access to all project source control >repositories. Committers may cast binding votes on any technical >discussion regarding the project (or any sub-project). > >2.3.1. Committer access is by invitation only and must be approved by >a majority 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 of active PMC members. > >2.3.2. All Apache Committers are required to have a signed Individual >Contributor License Agreement (ICLA) on file with the Apache Software >Foundation. There is a Committer FAQ which provides more details on >the requirements for Committers at Apache. > >2.3.3. 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. > >2.4. Project Management Committee > >The Project Management Committee (PMC) for Apache CloudStack is >responsible to the board and the ASF for the management and oversight >of the Apache CloudStack codebase. The responsibilities of the PMC >include: > >- Deciding what is distributed as products of the Apache CloudStack >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 > >2.4.1. Membership of the PMC is by invitation only and must be >approved by a lazy consensus 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 >lazy consensus of the active PMC members. > >2.4.2. 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 CloudStack) and has primary responsibility to the board for the >management of the projects within the scope of the CloudStack PMC. The >chair reports to the board quarterly on developments within the >CloudStack project. > >2.4.3. 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. > >3. Decision Making > >Within the CloudStack project, different types of decisions require >different forms of approval. For example, the previous section >describes several decisions which require "lazy consensus" approval. >This section defines how voting is performed, the types of approvals, >and which types of decision require which type of approval. > >3.1. Voting > >3.1.1. Decisions regarding the project are made by votes on the >primary project development mailing list >(cloudstack-dev@incubator.apache.org). Where necessary, PMC voting may >take place on the private CloudStack 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 > >+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. > >3.1.2. All participants in the CloudStack 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 >CloudStack community. For PMC decisions, only the votes of PMC members >are binding. > >3.1.3. Voting can also be applied to changes made to the CloudStack >codebase. These typically take the form of a veto (-1) in reply to the >commit message sent when the commit is made. > >3.2. Approvals > >These are the types of approvals that can be sought. Different actions >require different types of approvals > >Lazy Consensus - Lazy consensus requires 3 binding +1 votes and no >binding vetoes. >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. > >3.3. Vetoes > >3.3.1. Vetoes are only possible in a lazy consensus vote. > >3.3.2. 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. > >3.3.3. 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. > >3.4. 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. > >3.4.1. Technical Decisions > >Technical decisions should be made by the entire community using >consensus gathering, and not through formal voting. The CloudStack >community will assume that silence represents consensus on a proposal. > >During the consensus gathering process, technical decisions may be >vetoed by any Committer with a valid reason. > >3.4.2. Release Plan > >Defines the timetable and actions for a release. The plan also >nominates a Release Manager. > >Lazy majority of active committers > >3.4.3. 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 of active PMC members > >3.4.4. 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 within the project > >Lazy 2/3 majority of PMC members Did you leave out "active" here? > >3.4.5. New Committer > >When a new committer is proposed for the project > >Lazy consensus of active PMC members > >3.4.6. New PMC Member > >When a committer is proposed for the PMC > >Lazy consensus of active PMC members > >3.4.7. Committer Removal > >When removal of commit privileges is sought. Note: Such actions will >also be referred to the ASF board by the PMC chair > >Lazy 2/3 majority of active PMC members (excluding the committer in >question if a member of the PMC). > >3.4.8. 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. > >Lazy 2/3 majority of active PMC members (excluding the member in question) > >3.4.9. Modifying Bylaws > >Modifying this document. > >Lazy majority of active PMC members > >3.5. Voting Timeframes > >Formal votes are open for a period of at least 72 hours to allow all >active voters time to consider the vote. > >*****************************************************
