+1 Cheers,
Hugo Sent from my iPhone On 12 aug. 2013, at 20:01, Noah Slater <nsla...@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 <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 > > > -- > Noah Slater > https://twitter.com/nslater
