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/08/16 01:06:15 UTC

[VOTE] Minor edits to the by-laws

Devs,

Got some more cosmetic edits to make. :) I noticed that our by-laws look
pretty crapy at the moment, as we're not actually marking up the headers
properly.

cf. http://cloudstack.apache.org/bylaws.html

Per the by-laws, we're using a lazy majority for this vote. Please cast
your vote now. I will tally the results in 72 hours.

Here's my changelog:

 * Use proper headings

Here's my patch:

Index: bylaws.mdtext
===================================================================
--- bylaws.mdtext (revision 1514527)
+++ bylaws.mdtext (working copy)
@@ -22,7 +22,7 @@
 responsibilities. These roles govern what tasks an individual may perform
 within the project. The roles are defined in the following sections:

-2.1. Users
+## 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
@@ -31,7 +31,7 @@
 user support forums. Users who participate in the project through any
mechanism
 are considered to be Contributors.

-2.2. Contributors
+## 2.2. Contributors

 Contributors are all of the volunteers who are contributing time, code,
 documentation, or resources to the CloudStack Project. Contributions are
not
@@ -44,7 +44,7 @@
 invited to become a Committer by the PMC. The invitation will be at the
 discretion of a supporting PMC member.

-2.3. Committers
+## 2.3. Committers

 The project's Committers are responsible for the project's technical
 management. Committers have access to all project source control
repositories.
@@ -62,7 +62,7 @@
 2.3.3. A Committer who makes a sustained contribution to the project may be
 invited by the PMC to become a member of the PMC, after approval of the
PMC.

-2.4. Project Management Committee
+## 2.4. Project Management Committee

 The Project Management Committee (PMC) for Apache CloudStack is
responsible to
 the board and the ASF for the management and oversight of the Apache
CloudStack
@@ -121,7 +121,7 @@
 This section defines how voting is performed, the types of approvals, and
which
 types of decision require which type of approval.

-3.1. Voting
+## 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
@@ -161,7 +161,7 @@

 3.1.5. Non-binding \-1 votes are not considered to be vetos for any
decision.

-3.2. Approvals
+## 3.2. Approvals

 There are three types of approvals that can be sought. Section 3.4
describes
 actions and types of approvals needed for each action.
@@ -175,7 +175,7 @@
 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.

-3.3. Vetoes
+## 3.3. Vetoes

 3.3.1. Vetoes are only possible in a lazy consensus vote.

@@ -189,14 +189,14 @@
 veto to withdraw their veto. If a veto is not withdrawn, any action that
has
 been vetoed must be reversed in a timely manner.

-3.4. Actions
+## 3.4. Actions

 This section describes the various actions which are undertaken within the
 project, the roles that have the right to start a vote on the action, the
 corresponding approval required for that action and those who have binding
 votes over the action.

-3.4.1. Technical Decisions
+## 3.4.1. Technical Decisions

 A technical decision is any decision that involves changes to the source
code
 that we distribute in our official releases.
@@ -215,7 +215,7 @@
 Any user, contributor, committer, or PMC member can initiate a technical
 decision making process.

-3.4.2. Non-Technical Decisions
+## 3.4.2. Non-Technical Decisions

 A non-technical decisions is any decision that does not involve changes to
the
 source code that we distribute in our official releases.
@@ -235,7 +235,7 @@
 Any user, contributor, committer, or PMC member can initiate a
non-technical
 decision making process.

-3.4.3. Release Plan
+## 3.4.3. Release Plan

 Defines the timetable and work items for a release. The plan also
nominates a
 Release Manager.
@@ -245,7 +245,7 @@
 Any active committer or PMC member may call a vote. The vote must occur on
the
 project development mailing list.

-3.4.4. Product Release
+## 3.4.4. Product Release

 When a release of one of the project's products is ready, a vote is
required to
 accept the release as an official release of the project.
@@ -255,7 +255,7 @@
 Any active committer or PMC member may call a vote. The vote must occur on
the
 project development mailing list.

-3.4.5. Adoption of New Codebase
+## 3.4.5. Adoption of New Codebase

 When the codebase for an existing, released product is to be replaced with
an
 alternative codebase. If such a vote fails to gain approval, the existing
code
@@ -268,7 +268,7 @@
 Any active committer or PMC member may call a vote. The vote must occur on
the
 project development mailing list.

-3.4.6. New Committer
+## 3.4.6. New Committer

 When a new committer is proposed for the project.

@@ -277,7 +277,7 @@
 Any active PMC member may call a vote. The vote must occur on the PMC
private
 mailing list.

-3.4.7. New PMC Member
+## 3.4.7. New PMC Member

 When a committer is proposed for the PMC.

@@ -286,7 +286,7 @@
 Any active PMC member may call a vote. The vote must occur on the PMC
private
 mailing list.

-3.4.8. Committer Removal
+## 3.4.8. Committer Removal

 When removal of commit privileges is sought. Note: Such actions will also
be
 referred to the ASF board by the PMC chair
@@ -297,7 +297,7 @@
 Any active PMC member may call a vote. The vote must occur on the PMC
private
 mailing list.

-3.4.9. PMC Member Removal
+## 3.4.9. 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.
@@ -307,7 +307,7 @@
 Any active PMC member may call a vote. The vote must occur on the PMC
private
 mailing list.

-3.4.10. Modifying Bylaws
+## 3.4.10. Modifying Bylaws

 Modifying this document.

@@ -316,7 +316,7 @@
 Any active committer or PMC member may call a vote. The vote must occur on
the
 project development mailing list.

-3.5. Voting Timeframes
+## 3.5. Voting Timeframes

 Formal votes are open for a period of at least 72 hours to allow all active
 voters time to consider the vote.

-- 
Noah Slater
https://twitter.com/nslater

Re: [VOTE] Minor edits to the by-laws

Posted by Noah Slater <ns...@apache.org>.
No. Thanks. I will abort this vote.

I actually have another substantive change to make, but I didn't want to
make it along with some stylistic changes. But I don't want to tire the
list out. So I may combine them, as I am sure headers are non-controversial.


On 16 August 2013 07:44, Daan Hoogland <da...@gmail.com> wrote:

> Noah,
>
> You use the same two-hash indent for two digit paragraph numbers as
> for three digit paragraph numbers.
>
> Is this intentional?
>
> regards,
> Daan
>
> On Fri, Aug 16, 2013 at 6:55 AM, Hugo Trippaers
> <HT...@schubergphilis.com> wrote:
> > +1
> >
> > Cheers,
> >
> > Hugo
> >
> > Sent from my iPhone
> >
> > On 16 aug. 2013, at 01:06, Noah Slater <ns...@apache.org> wrote:
> >
> >> Devs,
> >>
> >> Got some more cosmetic edits to make. :) I noticed that our by-laws look
> >> pretty crapy at the moment, as we're not actually marking up the headers
> >> properly.
> >>
> >> cf. http://cloudstack.apache.org/bylaws.html
> >>
> >> Per the by-laws, we're using a lazy majority for this vote. Please cast
> >> your vote now. I will tally the results in 72 hours.
> >>
> >> Here's my changelog:
> >>
> >> * Use proper headings
> >>
> >> Here's my patch:
> >>
> >> Index: bylaws.mdtext
> >> ===================================================================
> >> --- bylaws.mdtext (revision 1514527)
> >> +++ bylaws.mdtext (working copy)
> >> @@ -22,7 +22,7 @@
> >> responsibilities. These roles govern what tasks an individual may
> perform
> >> within the project. The roles are defined in the following sections:
> >>
> >> -2.1. Users
> >> +## 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
> >> @@ -31,7 +31,7 @@
> >> user support forums. Users who participate in the project through any
> >> mechanism
> >> are considered to be Contributors.
> >>
> >> -2.2. Contributors
> >> +## 2.2. Contributors
> >>
> >> Contributors are all of the volunteers who are contributing time, code,
> >> documentation, or resources to the CloudStack Project. Contributions are
> >> not
> >> @@ -44,7 +44,7 @@
> >> invited to become a Committer by the PMC. The invitation will be at the
> >> discretion of a supporting PMC member.
> >>
> >> -2.3. Committers
> >> +## 2.3. Committers
> >>
> >> The project's Committers are responsible for the project's technical
> >> management. Committers have access to all project source control
> >> repositories.
> >> @@ -62,7 +62,7 @@
> >> 2.3.3. A Committer who makes a sustained contribution to the project
> may be
> >> invited by the PMC to become a member of the PMC, after approval of the
> >> PMC.
> >>
> >> -2.4. Project Management Committee
> >> +## 2.4. Project Management Committee
> >>
> >> The Project Management Committee (PMC) for Apache CloudStack is
> >> responsible to
> >> the board and the ASF for the management and oversight of the Apache
> >> CloudStack
> >> @@ -121,7 +121,7 @@
> >> This section defines how voting is performed, the types of approvals,
> and
> >> which
> >> types of decision require which type of approval.
> >>
> >> -3.1. Voting
> >> +## 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
> >> @@ -161,7 +161,7 @@
> >>
> >> 3.1.5. Non-binding \-1 votes are not considered to be vetos for any
> >> decision.
> >>
> >> -3.2. Approvals
> >> +## 3.2. Approvals
> >>
> >> There are three types of approvals that can be sought. Section 3.4
> >> describes
> >> actions and types of approvals needed for each action.
> >> @@ -175,7 +175,7 @@
> >> 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.
> >>
> >> -3.3. Vetoes
> >> +## 3.3. Vetoes
> >>
> >> 3.3.1. Vetoes are only possible in a lazy consensus vote.
> >>
> >> @@ -189,14 +189,14 @@
> >> veto to withdraw their veto. If a veto is not withdrawn, any action that
> >> has
> >> been vetoed must be reversed in a timely manner.
> >>
> >> -3.4. Actions
> >> +## 3.4. Actions
> >>
> >> This section describes the various actions which are undertaken within
> the
> >> project, the roles that have the right to start a vote on the action,
> the
> >> corresponding approval required for that action and those who have
> binding
> >> votes over the action.
> >>
> >> -3.4.1. Technical Decisions
> >> +## 3.4.1. Technical Decisions
> >>
> >> A technical decision is any decision that involves changes to the source
> >> code
> >> that we distribute in our official releases.
> >> @@ -215,7 +215,7 @@
> >> Any user, contributor, committer, or PMC member can initiate a technical
> >> decision making process.
> >>
> >> -3.4.2. Non-Technical Decisions
> >> +## 3.4.2. Non-Technical Decisions
> >>
> >> A non-technical decisions is any decision that does not involve changes
> to
> >> the
> >> source code that we distribute in our official releases.
> >> @@ -235,7 +235,7 @@
> >> Any user, contributor, committer, or PMC member can initiate a
> >> non-technical
> >> decision making process.
> >>
> >> -3.4.3. Release Plan
> >> +## 3.4.3. Release Plan
> >>
> >> Defines the timetable and work items for a release. The plan also
> >> nominates a
> >> Release Manager.
> >> @@ -245,7 +245,7 @@
> >> Any active committer or PMC member may call a vote. The vote must occur
> on
> >> the
> >> project development mailing list.
> >>
> >> -3.4.4. Product Release
> >> +## 3.4.4. Product Release
> >>
> >> When a release of one of the project's products is ready, a vote is
> >> required to
> >> accept the release as an official release of the project.
> >> @@ -255,7 +255,7 @@
> >> Any active committer or PMC member may call a vote. The vote must occur
> on
> >> the
> >> project development mailing list.
> >>
> >> -3.4.5. Adoption of New Codebase
> >> +## 3.4.5. Adoption of New Codebase
> >>
> >> When the codebase for an existing, released product is to be replaced
> with
> >> an
> >> alternative codebase. If such a vote fails to gain approval, the
> existing
> >> code
> >> @@ -268,7 +268,7 @@
> >> Any active committer or PMC member may call a vote. The vote must occur
> on
> >> the
> >> project development mailing list.
> >>
> >> -3.4.6. New Committer
> >> +## 3.4.6. New Committer
> >>
> >> When a new committer is proposed for the project.
> >>
> >> @@ -277,7 +277,7 @@
> >> Any active PMC member may call a vote. The vote must occur on the PMC
> >> private
> >> mailing list.
> >>
> >> -3.4.7. New PMC Member
> >> +## 3.4.7. New PMC Member
> >>
> >> When a committer is proposed for the PMC.
> >>
> >> @@ -286,7 +286,7 @@
> >> Any active PMC member may call a vote. The vote must occur on the PMC
> >> private
> >> mailing list.
> >>
> >> -3.4.8. Committer Removal
> >> +## 3.4.8. Committer Removal
> >>
> >> When removal of commit privileges is sought. Note: Such actions will
> also
> >> be
> >> referred to the ASF board by the PMC chair
> >> @@ -297,7 +297,7 @@
> >> Any active PMC member may call a vote. The vote must occur on the PMC
> >> private
> >> mailing list.
> >>
> >> -3.4.9. PMC Member Removal
> >> +## 3.4.9. 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.
> >> @@ -307,7 +307,7 @@
> >> Any active PMC member may call a vote. The vote must occur on the PMC
> >> private
> >> mailing list.
> >>
> >> -3.4.10. Modifying Bylaws
> >> +## 3.4.10. Modifying Bylaws
> >>
> >> Modifying this document.
> >>
> >> @@ -316,7 +316,7 @@
> >> Any active committer or PMC member may call a vote. The vote must occur
> on
> >> the
> >> project development mailing list.
> >>
> >> -3.5. Voting Timeframes
> >> +## 3.5. Voting Timeframes
> >>
> >> Formal votes are open for a period of at least 72 hours to allow all
> active
> >> voters time to consider the vote.
> >>
> >> --
> >> Noah Slater
> >> https://twitter.com/nslater
>



-- 
Noah Slater
https://twitter.com/nslater

Re: [VOTE] Minor edits to the by-laws

Posted by Daan Hoogland <da...@gmail.com>.
Noah,

You use the same two-hash indent for two digit paragraph numbers as
for three digit paragraph numbers.

Is this intentional?

regards,
Daan

On Fri, Aug 16, 2013 at 6:55 AM, Hugo Trippaers
<HT...@schubergphilis.com> wrote:
> +1
>
> Cheers,
>
> Hugo
>
> Sent from my iPhone
>
> On 16 aug. 2013, at 01:06, Noah Slater <ns...@apache.org> wrote:
>
>> Devs,
>>
>> Got some more cosmetic edits to make. :) I noticed that our by-laws look
>> pretty crapy at the moment, as we're not actually marking up the headers
>> properly.
>>
>> cf. http://cloudstack.apache.org/bylaws.html
>>
>> Per the by-laws, we're using a lazy majority for this vote. Please cast
>> your vote now. I will tally the results in 72 hours.
>>
>> Here's my changelog:
>>
>> * Use proper headings
>>
>> Here's my patch:
>>
>> Index: bylaws.mdtext
>> ===================================================================
>> --- bylaws.mdtext (revision 1514527)
>> +++ bylaws.mdtext (working copy)
>> @@ -22,7 +22,7 @@
>> responsibilities. These roles govern what tasks an individual may perform
>> within the project. The roles are defined in the following sections:
>>
>> -2.1. Users
>> +## 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
>> @@ -31,7 +31,7 @@
>> user support forums. Users who participate in the project through any
>> mechanism
>> are considered to be Contributors.
>>
>> -2.2. Contributors
>> +## 2.2. Contributors
>>
>> Contributors are all of the volunteers who are contributing time, code,
>> documentation, or resources to the CloudStack Project. Contributions are
>> not
>> @@ -44,7 +44,7 @@
>> invited to become a Committer by the PMC. The invitation will be at the
>> discretion of a supporting PMC member.
>>
>> -2.3. Committers
>> +## 2.3. Committers
>>
>> The project's Committers are responsible for the project's technical
>> management. Committers have access to all project source control
>> repositories.
>> @@ -62,7 +62,7 @@
>> 2.3.3. A Committer who makes a sustained contribution to the project may be
>> invited by the PMC to become a member of the PMC, after approval of the
>> PMC.
>>
>> -2.4. Project Management Committee
>> +## 2.4. Project Management Committee
>>
>> The Project Management Committee (PMC) for Apache CloudStack is
>> responsible to
>> the board and the ASF for the management and oversight of the Apache
>> CloudStack
>> @@ -121,7 +121,7 @@
>> This section defines how voting is performed, the types of approvals, and
>> which
>> types of decision require which type of approval.
>>
>> -3.1. Voting
>> +## 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
>> @@ -161,7 +161,7 @@
>>
>> 3.1.5. Non-binding \-1 votes are not considered to be vetos for any
>> decision.
>>
>> -3.2. Approvals
>> +## 3.2. Approvals
>>
>> There are three types of approvals that can be sought. Section 3.4
>> describes
>> actions and types of approvals needed for each action.
>> @@ -175,7 +175,7 @@
>> 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.
>>
>> -3.3. Vetoes
>> +## 3.3. Vetoes
>>
>> 3.3.1. Vetoes are only possible in a lazy consensus vote.
>>
>> @@ -189,14 +189,14 @@
>> veto to withdraw their veto. If a veto is not withdrawn, any action that
>> has
>> been vetoed must be reversed in a timely manner.
>>
>> -3.4. Actions
>> +## 3.4. Actions
>>
>> This section describes the various actions which are undertaken within the
>> project, the roles that have the right to start a vote on the action, the
>> corresponding approval required for that action and those who have binding
>> votes over the action.
>>
>> -3.4.1. Technical Decisions
>> +## 3.4.1. Technical Decisions
>>
>> A technical decision is any decision that involves changes to the source
>> code
>> that we distribute in our official releases.
>> @@ -215,7 +215,7 @@
>> Any user, contributor, committer, or PMC member can initiate a technical
>> decision making process.
>>
>> -3.4.2. Non-Technical Decisions
>> +## 3.4.2. Non-Technical Decisions
>>
>> A non-technical decisions is any decision that does not involve changes to
>> the
>> source code that we distribute in our official releases.
>> @@ -235,7 +235,7 @@
>> Any user, contributor, committer, or PMC member can initiate a
>> non-technical
>> decision making process.
>>
>> -3.4.3. Release Plan
>> +## 3.4.3. Release Plan
>>
>> Defines the timetable and work items for a release. The plan also
>> nominates a
>> Release Manager.
>> @@ -245,7 +245,7 @@
>> Any active committer or PMC member may call a vote. The vote must occur on
>> the
>> project development mailing list.
>>
>> -3.4.4. Product Release
>> +## 3.4.4. Product Release
>>
>> When a release of one of the project's products is ready, a vote is
>> required to
>> accept the release as an official release of the project.
>> @@ -255,7 +255,7 @@
>> Any active committer or PMC member may call a vote. The vote must occur on
>> the
>> project development mailing list.
>>
>> -3.4.5. Adoption of New Codebase
>> +## 3.4.5. Adoption of New Codebase
>>
>> When the codebase for an existing, released product is to be replaced with
>> an
>> alternative codebase. If such a vote fails to gain approval, the existing
>> code
>> @@ -268,7 +268,7 @@
>> Any active committer or PMC member may call a vote. The vote must occur on
>> the
>> project development mailing list.
>>
>> -3.4.6. New Committer
>> +## 3.4.6. New Committer
>>
>> When a new committer is proposed for the project.
>>
>> @@ -277,7 +277,7 @@
>> Any active PMC member may call a vote. The vote must occur on the PMC
>> private
>> mailing list.
>>
>> -3.4.7. New PMC Member
>> +## 3.4.7. New PMC Member
>>
>> When a committer is proposed for the PMC.
>>
>> @@ -286,7 +286,7 @@
>> Any active PMC member may call a vote. The vote must occur on the PMC
>> private
>> mailing list.
>>
>> -3.4.8. Committer Removal
>> +## 3.4.8. Committer Removal
>>
>> When removal of commit privileges is sought. Note: Such actions will also
>> be
>> referred to the ASF board by the PMC chair
>> @@ -297,7 +297,7 @@
>> Any active PMC member may call a vote. The vote must occur on the PMC
>> private
>> mailing list.
>>
>> -3.4.9. PMC Member Removal
>> +## 3.4.9. 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.
>> @@ -307,7 +307,7 @@
>> Any active PMC member may call a vote. The vote must occur on the PMC
>> private
>> mailing list.
>>
>> -3.4.10. Modifying Bylaws
>> +## 3.4.10. Modifying Bylaws
>>
>> Modifying this document.
>>
>> @@ -316,7 +316,7 @@
>> Any active committer or PMC member may call a vote. The vote must occur on
>> the
>> project development mailing list.
>>
>> -3.5. Voting Timeframes
>> +## 3.5. Voting Timeframes
>>
>> Formal votes are open for a period of at least 72 hours to allow all active
>> voters time to consider the vote.
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater

Re: [VOTE] Minor edits to the by-laws

Posted by Hugo Trippaers <HT...@schubergphilis.com>.
+1

Cheers,

Hugo

Sent from my iPhone

On 16 aug. 2013, at 01:06, Noah Slater <ns...@apache.org> wrote:

> Devs,
> 
> Got some more cosmetic edits to make. :) I noticed that our by-laws look
> pretty crapy at the moment, as we're not actually marking up the headers
> properly.
> 
> cf. http://cloudstack.apache.org/bylaws.html
> 
> Per the by-laws, we're using a lazy majority for this vote. Please cast
> your vote now. I will tally the results in 72 hours.
> 
> Here's my changelog:
> 
> * Use proper headings
> 
> Here's my patch:
> 
> Index: bylaws.mdtext
> ===================================================================
> --- bylaws.mdtext (revision 1514527)
> +++ bylaws.mdtext (working copy)
> @@ -22,7 +22,7 @@
> responsibilities. These roles govern what tasks an individual may perform
> within the project. The roles are defined in the following sections:
> 
> -2.1. Users
> +## 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
> @@ -31,7 +31,7 @@
> user support forums. Users who participate in the project through any
> mechanism
> are considered to be Contributors.
> 
> -2.2. Contributors
> +## 2.2. Contributors
> 
> Contributors are all of the volunteers who are contributing time, code,
> documentation, or resources to the CloudStack Project. Contributions are
> not
> @@ -44,7 +44,7 @@
> invited to become a Committer by the PMC. The invitation will be at the
> discretion of a supporting PMC member.
> 
> -2.3. Committers
> +## 2.3. Committers
> 
> The project's Committers are responsible for the project's technical
> management. Committers have access to all project source control
> repositories.
> @@ -62,7 +62,7 @@
> 2.3.3. A Committer who makes a sustained contribution to the project may be
> invited by the PMC to become a member of the PMC, after approval of the
> PMC.
> 
> -2.4. Project Management Committee
> +## 2.4. Project Management Committee
> 
> The Project Management Committee (PMC) for Apache CloudStack is
> responsible to
> the board and the ASF for the management and oversight of the Apache
> CloudStack
> @@ -121,7 +121,7 @@
> This section defines how voting is performed, the types of approvals, and
> which
> types of decision require which type of approval.
> 
> -3.1. Voting
> +## 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
> @@ -161,7 +161,7 @@
> 
> 3.1.5. Non-binding \-1 votes are not considered to be vetos for any
> decision.
> 
> -3.2. Approvals
> +## 3.2. Approvals
> 
> There are three types of approvals that can be sought. Section 3.4
> describes
> actions and types of approvals needed for each action.
> @@ -175,7 +175,7 @@
> 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.
> 
> -3.3. Vetoes
> +## 3.3. Vetoes
> 
> 3.3.1. Vetoes are only possible in a lazy consensus vote.
> 
> @@ -189,14 +189,14 @@
> veto to withdraw their veto. If a veto is not withdrawn, any action that
> has
> been vetoed must be reversed in a timely manner.
> 
> -3.4. Actions
> +## 3.4. Actions
> 
> This section describes the various actions which are undertaken within the
> project, the roles that have the right to start a vote on the action, the
> corresponding approval required for that action and those who have binding
> votes over the action.
> 
> -3.4.1. Technical Decisions
> +## 3.4.1. Technical Decisions
> 
> A technical decision is any decision that involves changes to the source
> code
> that we distribute in our official releases.
> @@ -215,7 +215,7 @@
> Any user, contributor, committer, or PMC member can initiate a technical
> decision making process.
> 
> -3.4.2. Non-Technical Decisions
> +## 3.4.2. Non-Technical Decisions
> 
> A non-technical decisions is any decision that does not involve changes to
> the
> source code that we distribute in our official releases.
> @@ -235,7 +235,7 @@
> Any user, contributor, committer, or PMC member can initiate a
> non-technical
> decision making process.
> 
> -3.4.3. Release Plan
> +## 3.4.3. Release Plan
> 
> Defines the timetable and work items for a release. The plan also
> nominates a
> Release Manager.
> @@ -245,7 +245,7 @@
> Any active committer or PMC member may call a vote. The vote must occur on
> the
> project development mailing list.
> 
> -3.4.4. Product Release
> +## 3.4.4. Product Release
> 
> When a release of one of the project's products is ready, a vote is
> required to
> accept the release as an official release of the project.
> @@ -255,7 +255,7 @@
> Any active committer or PMC member may call a vote. The vote must occur on
> the
> project development mailing list.
> 
> -3.4.5. Adoption of New Codebase
> +## 3.4.5. Adoption of New Codebase
> 
> When the codebase for an existing, released product is to be replaced with
> an
> alternative codebase. If such a vote fails to gain approval, the existing
> code
> @@ -268,7 +268,7 @@
> Any active committer or PMC member may call a vote. The vote must occur on
> the
> project development mailing list.
> 
> -3.4.6. New Committer
> +## 3.4.6. New Committer
> 
> When a new committer is proposed for the project.
> 
> @@ -277,7 +277,7 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
> 
> -3.4.7. New PMC Member
> +## 3.4.7. New PMC Member
> 
> When a committer is proposed for the PMC.
> 
> @@ -286,7 +286,7 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
> 
> -3.4.8. Committer Removal
> +## 3.4.8. Committer Removal
> 
> When removal of commit privileges is sought. Note: Such actions will also
> be
> referred to the ASF board by the PMC chair
> @@ -297,7 +297,7 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
> 
> -3.4.9. PMC Member Removal
> +## 3.4.9. 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.
> @@ -307,7 +307,7 @@
> Any active PMC member may call a vote. The vote must occur on the PMC
> private
> mailing list.
> 
> -3.4.10. Modifying Bylaws
> +## 3.4.10. Modifying Bylaws
> 
> Modifying this document.
> 
> @@ -316,7 +316,7 @@
> Any active committer or PMC member may call a vote. The vote must occur on
> the
> project development mailing list.
> 
> -3.5. Voting Timeframes
> +## 3.5. Voting Timeframes
> 
> Formal votes are open for a period of at least 72 hours to allow all active
> voters time to consider the vote.
> 
> -- 
> Noah Slater
> https://twitter.com/nslater