[RESULTS] (Was: Re: [VOTE] Whitespace changes to bylaws.mdtext)

[Noah Slater <ns...@apache.org>]

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 <ns...@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&nbsp;gathering, and not through formal voting.
> +Technical decisions should normally be made by the entire community using
> +consensus&nbsp;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&nbsp;consensus&nbsp;of active committers.
> +If a formal vote is started for a technical decision, the vote will be
> held as
> +a lazy&nbsp;consensus&nbsp;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