cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <sudha.ponnaga...@citrix.com>
Subject RE: [VOTE] Project Bylaws
Date Thu, 03 Jan 2013 18:53:58 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