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 <daan.hoogl...@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 > <htrippa...@schubergphilis.com> wrote: > > +1 > > > > Cheers, > > > > Hugo > > > > Sent from my iPhone > > > > On 16 aug. 2013, at 01:06, Noah Slater <nsla...@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
