incubator-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: [VOTE] Project Bylaws
Date Thu, 03 Jan 2013 22:25:16 GMT
+1 (binding)

On 1/3/13 10:53 AM, "Sudha Ponnaganti" <sudha.ponnaganti@citrix.com> wrote:

>+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