+1
> -----Original Message----- > From: Noah Slater [mailto:nsla...@apache.org] > Sent: Monday, July 29, 2013 2:55 PM > To: CloudStack, Dev > Subject: [VOTE] Whitespace changes to bylaws.mdtext > > 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)
