+1 -kd
>-----Original Message----- >From: John Kinsella [mailto:j...@stratosec.co] >Sent: Wednesday, January 02, 2013 12:05 PM >To: cloudstack-dev@incubator.apache.org >Subject: Re: [VOTE] Project Bylaws > >+1 > >On Jan 2, 2013, at 7:29 AM, Chip Childers <chip.child...@sungard.com> >wrote: > >> Hi all, >> >> We've had some good discussions on the proposed bylaws over the last >> couple of weeks [1], so I'd like to move this forward to a VOTE now. >> Of course, if there are still concerns or discussion points that >> people want to see addressed, we can stop the vote to discuss and edit >> as necessary. >> >> I've made 2 changes from the last draft I sent out. They are as follows: >> >> * Removed from section 3.4.1 (Technical decisions): "The CloudStack >> community will assume that silence represents consensus on a >> proposal." >> * Added to section 2.3.3 (Committers): "...after approval of the PMC." >> >> I'd like us to assume that committer votes are binding for the initial >> establishment of the bylaws. If the proposed bylaws are adopted, the >> PMC will have the binding votes for bylaw changes going forward. >> Until that's established though, committer status seems like the right >> way to be inclusive about this process. Of course, any community >> member has the right to share their opinion via non-binding votes (and >> I'd encourage you to do so). >> >> And now, here's what we're voting on: >> >> I'd like to propose that the Apache CloudStack Project Bylaws >> (included at the bottom of this email message) be adopted by the >> community. >> >> Since this is a critical decision for the community, I'll leave this >> vote thread open for at least a week. >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >> >> For sanity in tallying the vote, can committers please be sure to >> indicate "(binding)" with their vote? >> >> >> -chip >> >> [1] http://markmail.org/thread/ma3g6hdgegu76g44 >> >> >> ******************************************** >> 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 and specifies the rules for specific project actions. >> >> 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 operates under a set of principles known collectively >> as the "Apache Way". Those principles are: Transparancy, consensus, >> non-affiliation, respect for fellow developers, and meritocracy, in no >specific order. >> >> 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 can contribute to the Apache projects by providing feedback to >> developers in the form of bug reports and feature suggestions. As >> well, users can participate in the Apache community by helping other >> users on mailing lists and user support forums. Users who participate >> in the project through any mechanism are considered to be >> Contributors. >> >> 2.2. Contributors >> >> Contributors are all of the volunteers who are contributing time, >> code, documentation, or resources to the CloudStack Project. >> Contributions are not just code, but can be any combination of >> documentation, testing, user support, code, code reviews, bug >> reporting, community organizing, project marketing, or numerous other >> activities that help promote and improve the Apache CloudStack project and >community. >> >> A Contributor that makes sustained, welcome contributions to the >> project may be invited to become a Committer by the PMC. The >> invitation will be at the discretion of a supporting PMC member. >> >> 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 lazy consensus of the 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 by the PMC to become a member of the PMC, after approval >of the PMC. >> >> 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. >> >> 2.4.1. The responsibilities of the PMC include: >> >> 2.4.1.1. Fostering, supporting and growing the project's community. >> >> 2.4.1.2. Deciding what is distributed as products of the Apache >> CloudStack project. In particular all releases must be approved by the PMC. >> >> 2.4.1.3. Maintaining the project's shared resources, including the >> codebase repository, mailing lists, websites. >> >> 2.4.1.4. Speaking on behalf of the project. >> >> 2.4.1.5. Resolving license disputes regarding products of the project. >> >> 2.4.1.6. Nominating new PMC members and committers. >> >> 2.4.1.7. Maintaining these bylaws and other guidelines of the project. >> >> 2.4.2. Membership of the PMC is by invitation only and must be >> approved by a lazy consensus of active PMC members. >> >> 2.4.3. A PMC member is considered "emeritus" by their own declaration. >> An emeritus member may request reinstatement to the PMC. Such >> reinstatement is subject to lazy consensus of the active PMC members. >> >> 2.4.4. "Active PMC members" are all non-emeritus PMC members. >> >> 2.4.4. 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. The chair must be an active PMC member. >> >> 2.4.5. 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 >> >> 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. >> >> 3.1.2. Voting may take four flavors: >> >> 3.1.2.1. +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" >> >> 3.1.2.2. +0 This vote indicates a willingness for the action under >> consideration to go ahead. The voter, however will not be able to help. >> >> 3.1.2.3. -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. >> >> 3.1.2.4. -1 This is a negative vote. On issues where consensus is >> required, this vote counts as a veto if binding. 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.3. 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.4. 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.1.5. Non-binding -1 votes are not considered to be vetos for any decision. >> >> 3.2. Approvals >> >> There are three types of approvals that can be sought. Section 3.4 >> describes actions and types of approvals needed for each action. >> >> 3.2.1. Lazy Consensus - Lazy consensus requires 3 binding +1 votes and >> no binding -1 votes. >> >> 3.2.2. Lazy Majority - A lazy majority vote requires 3 binding +1 >> votes and more binding +1 votes than binding -1 votes. >> >> 3.2.3. Lazy 2/3 Majority - Lazy 2/3 majority votes requires at least 3 >> binding votes and twice as many binding +1 votes as binding -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 roles that have the right to start a vote on the >> action, the corresponding approval required for that action and those >> who have binding votes over the action. >> >> 3.4.1. Technical Decisions >> >> Technical decisions should normally be made by the entire community >> using consensus gathering, and not through formal voting. >> >> Technical decisions must be made on a project development mailing list. >> >> During the consensus gathering process, technical decisions may be >> vetoed by any Committer with a valid reason. >> >> If a formal vote is started for a technical decision, the vote will be >> held as a lazy majority of active committers. >> >> Any user, contributor, committer or PMC member can initiate a >> technical desicion making process. >> >> 3.4.2. Release Plan >> >> Defines the timetable and work items for a release. The plan also >> nominates a Release Manager. >> >> A lazy majority of active committers is required for approval. >> >> Any active committer or PMC member may call a vote. The vote must >> occur on a project development mailing list. >> >> 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 is required for approval. >> >> Any active committer or PMC member may call a vote. The vote must >> occur on a project development mailing list. >> >> 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 active PMC members. >> >> Any active committer or PMC member may call a vote. The vote must >> occur on a project development mailing list. >> >> 3.4.5. New Committer >> >> When a new committer is proposed for the project. >> >> Lazy consensus of active PMC members. >> >> Any active PMC member may call a vote. The vote must occur on the PMC >> private mailing list. >> >> 3.4.6. New PMC Member >> >> When a committer is proposed for the PMC. >> >> Lazy consensus of active PMC members. >> >> Any active PMC member may call a vote. The vote must occur on the PMC >> private mailing list. >> >> 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). >> >> Any active PMC member may call a vote. The vote must occur on the PMC >> private mailing list. >> >> 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) >> >> Any active PMC member may call a vote. The vote must occur on the PMC >> private mailing list. >> >> 3.4.9. Modifying Bylaws >> >> Modifying this document. >> >> Lazy majority of active PMC members >> >> Any active committer or PMC member may call a vote. The vote must >> occur on a project development mailing list. >> >> 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. >> >
