cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <HTrippa...@schubergphilis.com>
Subject Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
Date Tue, 13 Aug 2013 05:30:54 GMT
+1

Cheers,

Hugo

Sent from my iPhone

On 12 aug. 2013, at 20:01, Noah Slater <nslater@apache.org> wrote:

> Bumping the thread for a 3rd +1 vote from the PMC. Our by-laws stipulate we
> need 3 +1 PMC votes.
> 
> Thanks.
> 
> 
> On 5 August 2013 22:43, 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
View raw message