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
