+1 -sebastien
On Jan 2, 2013, at 4:29 PM, 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.
