cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [DISCUSS] Apache CloudStack Project Bylaws
Date Tue, 18 Dec 2012 22:30:27 GMT
Chip,

Good doc!  

Are we expecting to outline what technical decision constitutes?  

--Alex


> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Tuesday, December 18, 2012 12:38 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Apache CloudStack Project Bylaws
> 
> Latest Draft Below - Comments Please!
> 
> 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 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.
> 
> 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 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.
> 
> 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