You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Noah Slater <ns...@apache.org> on 2013/07/29 23:55:23 UTC
[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)
Re: [VOTE] Whitespace changes to bylaws.mdtext
Posted by David Nalley <da...@gnsa.us>.
On Mon, Jul 29, 2013 at 5:55 PM, 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
+1
--David
RE: [VOTE] Whitespace changes to bylaws.mdtext
Posted by Alex Huang <Al...@citrix.com>.
+1
> -----Original Message-----
> From: Noah Slater [mailto:nslater@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)
Re: [VOTE] Whitespace changes to bylaws.mdtext
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Jul 29, 2013 at 10:55:23PM +0100, Noah Slater 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
+1
Re: [VOTE] Whitespace changes to bylaws.mdtext
Posted by Wido den Hollander <wi...@widodh.nl>.
+1
On 07/29/2013 11:55 PM, Noah Slater 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,
>