You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Noah Slater <ns...@apache.org> on 2013/08/12 19:55:57 UTC
[RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions
and other minor changes)
3 +1 votes, and the vote passes. I will update the by-laws now.
Thanks!
On 6 August 2013 20:06, Musayev, Ilya <im...@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" <ns...@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
Re: [RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical
decisions and other minor changes)
Posted by Noah Slater <ns...@apache.org>.
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 <ns...@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 <im...@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" <ns...@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