cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
Date Thu, 15 Aug 2013 22:52:28 GMT
Thanks Hugo. Will wrap this up now!


On 13 August 2013 06:30, Hugo Trippaers <HTrippaers@schubergphilis.com>wrote:

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



-- 
Noah Slater
https://twitter.com/nslater

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