cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Kluge <Kevin.Kl...@citrix.com>
Subject RE: [VOTE] Project Bylaws
Date Mon, 07 Jan 2013 19:13:52 GMT
+1 (binding)

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Wednesday, January 02, 2013 7:30 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: [VOTE] Project Bylaws
> 
> 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.

Mime
View raw message