cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nsla...@apache.org
Subject svn commit: r1510739 - /cloudstack/site/trunk/content/bylaws.mdtext
Date Mon, 05 Aug 2013 21:21:23 GMT
Author: nslater
Date: Mon Aug  5 21:21:22 2013
New Revision: 1510739

URL: http://svn.apache.org/r1510739
Log:
Fix whitespace, spellings (following successful vote)

Modified:
    cloudstack/site/trunk/content/bylaws.mdtext

Modified: cloudstack/site/trunk/content/bylaws.mdtext
URL: http://svn.apache.org/viewvc/cloudstack/site/trunk/content/bylaws.mdtext?rev=1510739&r1=1510738&r2=1510739&view=diff
==============================================================================
--- cloudstack/site/trunk/content/bylaws.mdtext (original)
+++ cloudstack/site/trunk/content/bylaws.mdtext Mon Aug  5 21:21:22 2013
@@ -1,6 +1,6 @@
 Title: Apache CloudStack Project Bylaws
 
-#1. Introduction
+# 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
@@ -13,26 +13,23 @@ including the code in the CloudStack cod
 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,
+"Apache Way". Those principles are: Transparency, consensus, non-affiliation,
 respect for fellow developers, and meritocracy, in no specific order.
 
-#2. Roles and Responsibilities
+# 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:
+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.
+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
 
@@ -49,10 +46,10 @@ 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).
+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.
@@ -105,22 +102,21 @@ the projects within the scope of the Clo
 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, or the term of the
-current chair expires, the PMC will attempt to reach consensus on a new
-chair through discussion, confirming that consensus via a vote to
-recommend a new chair using a lazy 2/3 majority voting method.
-In the case that consensus is not achieved, the PMC
-will vote for a chair using Single Transferable Vote (STV) voting.
-Due to the fact that the discussions are about specific individuals,
-this vote would be held on the cloudstack-private mailing list.
-The decision must be ratified by the Apache board.
-
-2.4.6. The role of PMC chair will have a one year term.  The intention
-of this term is to allow for a rotation of the role amongst the PMC
-members.  This intention does not prohibit the PMC from selecting the
-same chair to serve consecutive terms.
+2.4.5. If the current chair of the PMC resigns, or the term of the current
+chair expires, the PMC will attempt to reach consensus on a new chair through
+discussion, confirming that consensus via a vote to recommend a new chair using
+a lazy 2/3 majority voting method. In the case that consensus is not achieved,
+the PMC will vote for a chair using Single Transferable Vote (STV) voting. Due
+to the fact that the discussions are about specific individuals, this vote
+would be held on the cloudstack-private mailing list. The decision must be
+ratified by the Apache board.
+
+2.4.6. The role of PMC chair will have a one year term.  The intention of this
+term is to allow for a rotation of the role amongst the PMC members.  This
+intention does not prohibit the PMC from selecting the same chair to serve
+consecutive terms.
 
-#3. Decision Making
+# 3. Decision Making
 
 This section defines how voting is performed, the types of approvals, and which
 types of decision require which type of approval.
@@ -128,8 +124,8 @@ types of decision require which type of 
 3.1. Voting
 
 3.1.1. Decisions regarding the project are made by votes on the primary project
-development mailing list (dev@cloudstack.apache.org). Where necessary,
-PMC voting may take place on the private CloudStack PMC mailing list. Votes are
+development mailing list (dev@cloudstack.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.
@@ -140,28 +136,28 @@ carried out by replying to the vote mail
 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.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.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.
+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.
+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.
 
@@ -173,8 +169,8 @@ actions and types of approvals needed fo
 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.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.
@@ -186,8 +182,8 @@ votes and twice as many binding \+1 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.
+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
@@ -202,19 +198,19 @@ 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 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.
+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 consensus of active committers.
+If a formal vote is started for a technical decision, the vote will be held as
+a lazy consensus of active committers.
 
-Any user, contributor, committer or PMC member can initiate a technical desicion
-making process.
+Any user, contributor, committer or PMC member can initiate a technical
+decision making process.
 
 3.4.2. Release Plan
 
@@ -280,8 +276,8 @@ 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.
+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)
 



Mime
View raw message