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
