cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject [VOTE] Whitespace changes to bylaws.mdtext
Date Mon, 29 Jul 2013 21:55:23 GMT
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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message