Ignore this. Unfortunately, we only have 2 +1 votes from the PMC. I am going to try to get a third. Sorry for the confusion.
On 12 August 2013 18:55, Noah Slater <nsla...@apache.org> wrote: > 3 +1 votes, and the vote passes. I will update the by-laws now. > > Thanks! > > > On 6 August 2013 20:06, Musayev, Ilya <imusa...@webmd.net> wrote: > >> +1 >> >> > -----Original Message----- >> > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >> > Sent: Tuesday, August 06, 2013 1:58 PM >> > To: dev@cloudstack.apache.org >> > Subject: Re: [VOTE] Update by-laws: non-technical decisions and other >> minor >> > changes >> > >> > +1 >> > >> > On 8/5/13 2:43 PM, "Noah Slater" <nsla...@apache.org> wrote: >> > >> > >Hi dev, >> > > >> > >I have some more by-law changes to propose. This is essentially round 2 >> > >for these changes. I incorporated feedback from the last thread. >> > > >> > >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: >> > > >> > >* Removed some spurious entities >> > > >> > >* Added "A technical decision is any decision that involves changes to >> > >the source code that we distribute in our official releases." to § >> > >3.4.1 (Technical Decisions). >> > > >> > >* Added "discussion-lead" before "consensus gathering" in this section. >> > > >> > >* With the improved definition, I have tightened up the wording so that >> > >technical decisions must be made on @dev. >> > > >> > >* Added § 3.4.2, Non-Technical Decisions. Non-technical decisions are >> > >defined as in the inverse of technical decisions. They can be made on >> > >whatever list is appropriate. Formal voting will use a lazy 2/3 >> majority. >> > >Votes cannot be vetoed. >> > > >> > >* Changed § 3.4.3. (Release Plan) to limit decisions to @dev. >> > > >> > >* Changed § 3.4.4. (Product Release) to limit decisions to @dev. >> > > >> > >* Changed § 3.4.5. (Adoption of New Codebase) to limit decisions to >> @dev. >> > > >> > >* Changed § 3.4.10. (Modifying Bylaws) to limit decisions to @dev. >> > > >> > >* Added an Oxford comma to the final paras of § 3.4.1. and § 3.4.2. >> > > >> > >* Section renumbering to accommodate § 3.4.2. >> > > >> > >And here's the patch: >> > > >> > >Index: bylaws.mdtext >> > >========================================================= >> > ========== >> > >--- bylaws.mdtext (revision 1510739) >> > >+++ bylaws.mdtext (working copy) >> > >@@ -198,41 +198,64 @@ >> > > >> > > 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. >> > >+ >> > > Technical decisions should normally be made by the entire community >> > >using -consensus gathering, and not through formal voting. >> > >+discussion-lead consensus gathering, and not through formal voting. >> > > >> > >-Technical decisions must be made on a project development mailing >> list. >> > >+Technical decisions must be made on the project development mailing >> list. >> > > >> > > 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. >> > >+a lazy consensus of active committers. >> > > >> > >-Any user, contributor, committer or PMC member can initiate a >> > >technical >> > >+Any user, contributor, committer, or PMC member can initiate a >> > >+technical >> > > decision making process. >> > > >> > >-3.4.2. Release Plan >> > >+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. >> > >+ >> > >+Non-technical decisions should normally be made by the entire >> > >+community >> > >using >> > >+discussion-lead consensus-building, and not through formal voting. >> > >+ >> > >+Non-technical decisions can be made on whichever project mailing list >> > >+is >> > >most >> > >+appropriate. >> > >+ >> > >+Non-technical decisions cannot be vetoed, but if there is strong >> > >opposition >> > >+a formal vote can be used to resolve the dispute. >> > >+ >> > >+If a formal vote is started for a non-technical decision, the vote >> > >+will >> > >be >> > >held >> > >+as a lazy 2/3 majority of active committers. >> > >+ >> > >+Any user, contributor, committer, or PMC member can initiate a >> > >non-technical >> > >+decision making process. >> > >+ >> > >+3.4.3. Release Plan >> > >+ >> > > Defines the timetable and work items for a release. The plan also >> > >nominates a Release Manager. >> > > >> > > A lazy majority of active committers is required for approval. >> > > >> > >-Any active committer or PMC member may call a vote. The vote must >> > >occur on a >> > >+Any active committer or PMC member may call a vote. The vote must >> > >+occur >> > >on >> > >the >> > > project development mailing list. >> > > >> > >-3.4.3. 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. >> > > >> > > Lazy Majority of active PMC members is required for approval. >> > > >> > >-Any active committer or PMC member may call a vote. The vote must >> > >occur on a >> > >+Any active committer or PMC member may call a vote. The vote must >> > >+occur >> > >on >> > >the >> > > project development mailing list. >> > > >> > >-3.4.4. 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 @@ -242,10 +265,10 @@ >> > > >> > > Lazy 2/3 majority of active PMC members. >> > > >> > >-Any active committer or PMC member may call a vote. The vote must >> > >occur on a >> > >+Any active committer or PMC member may call a vote. The vote must >> > >+occur >> > >on >> > >the >> > > project development mailing list. >> > > >> > >-3.4.5. New Committer >> > >+3.4.6. New Committer >> > > >> > > When a new committer is proposed for the project. >> > > >> > >@@ -254,7 +277,7 @@ >> > > Any active PMC member may call a vote. The vote must occur on the PMC >> > >private mailing list. >> > > >> > >-3.4.6. New PMC Member >> > >+3.4.7. New PMC Member >> > > >> > > When a committer is proposed for the PMC. >> > > >> > >@@ -263,7 +286,7 @@ >> > > Any active PMC member may call a vote. The vote must occur on the PMC >> > >private mailing list. >> > > >> > >-3.4.7. 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 @@ -274,7 +297,7 @@ >> > >Any active PMC member may call a vote. The vote must occur on the PMC >> > >private mailing list. >> > > >> > >-3.4.8. 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. >> > >@@ -284,13 +307,13 @@ >> > > Any active PMC member may call a vote. The vote must occur on the PMC >> > >private mailing list. >> > > >> > >-3.4.9. Modifying Bylaws >> > >+3.4.10. Modifying Bylaws >> > > >> > > Modifying this document. >> > > >> > > Lazy majority of active PMC members >> > > >> > >-Any active committer or PMC member may call a vote. The vote must >> > >occur on a >> > >+Any active committer or PMC member may call a vote. The vote must >> > >+occur >> > >on >> > >the >> > > project development mailing list. >> > > >> > > 3.5. Voting Timeframes >> > > >> > >-- >> > >Noah Slater >> > >https://twitter.com/nslater >> > >> >> >> > > > -- > Noah Slater > https://twitter.com/nslater > > -- Noah Slater https://twitter.com/nslater
