[RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes)
Okay, thanks folks. 4 +1 votes, 3 of which are binding. The vote is a success. I will apply the patch. 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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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 @@
Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
Thanks Hugo. Will wrap this up now! On 13 August 2013 06:30, Hugo Trippaers htrippa...@schubergphilis.comwrote: +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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
[RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes)
3 +1 votes, and the vote passes. I will update the by-laws now. Thanks! On 6 August 2013 20:06, Musayev, Ilya imusa...@webmd.net wrote: +1 -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 2013 1:58 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes +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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
Re: [RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes)
Ignore this. Unfortunately, we only have 2 +1 votes from the PMC. I am going to try to get a third. Sorry for the confusion. On 12 August 2013 18:55, Noah Slater nsla...@apache.org wrote: 3 +1 votes, and the vote passes. I will update the by-laws now. Thanks! On 6 August 2013 20:06, Musayev, Ilya imusa...@webmd.net wrote: +1 -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 2013 1:58 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes +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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
+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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
+1 On Mon, Aug 05, 2013 at 10:43:22PM +0100, Noah Slater 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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
RE: [VOTE] Update by-laws: non-technical decisions and other minor changes
+1 -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 2013 1:58 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes +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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
+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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
[VOTE] Update by-laws: non-technical decisions and other minor changes
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 nbsp; 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 -consensusnbsp;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 lazynbsp;consensusnbsp;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
