Thanks Hugo. Will wrap this up now!
On 13 August 2013 06:30, Hugo Trippaers <htrippa...@schubergphilis.com>wrote: > +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 > -- Noah Slater https://twitter.com/nslater
