We got 4 +1 votes, so the vote was successful. I'll make the changes now. Thanks peeps!
On 29 July 2013 22:55, Noah Slater <nsla...@apache.org> wrote: > 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) > > > > -- Noah Slater https://twitter.com/nslater