Hi, I'd like to make several changes to our by-laws, but before I continue, I've prepared a changset that tidies up whitespace and hard wraps. This will make it easier to edit.
The only non-whitespace change my patch makes is to correct two spelling errors: Transparancy -> Transparency desicion -> decision I am hoping this is a non-contentious change and can get the requisite 3 +1 votes. :) Per the by-laws, this is a lazy majority vote, and will be open for 72 hours. We need 3 +1 votes to pass, and more +1 votes than -1 votes. See the end of this email for the full patch. (Our ML does not allow attachments. And I want the change to be concretely tied to the votes.) Thanks, -- NS Index: bylaws.mdtext =================================================================== --- bylaws.mdtext (revision 1508205) +++ bylaws.mdtext (working copy) @@ -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 @@ 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 @@ 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 @@ 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.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.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 @@ 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 @@ 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.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.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 @@ 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 @@ 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 @@ 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 @@ 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)
