cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: [DISCUSS] Apache CloudStack Project Bylaws
Date Fri, 14 Dec 2012 18:21:16 GMT


On 12/12/12 6:30 PM, "Chip Childers" <chip.childers@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.
>
>*****************************************************


Mime
View raw message