+1 On 8/5/13 2:43 PM, "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
