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
