+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
>
