cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject [RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes)
Date Mon, 12 Aug 2013 17:55:57 GMT
3 +1 votes, and the vote passes. I will update the by-laws now.

Thanks!


On 6 August 2013 20:06, Musayev, Ilya <imusayev@webmd.net> wrote:

> +1
>
> > -----Original Message-----
> > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@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" <nslater@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 &nbsp; 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&nbsp;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&nbsp;consensus&nbsp;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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message