svn commit: r874820 - in /websites/staging/cloudstack/trunk/content: ./ bylaws.html

[bu...@apache.org]

Author: buildbot
Date: Thu Aug 15 22:56:33 2013
New Revision: 874820

Log:
Staging update by buildbot for cloudstack

Modified:
    websites/staging/cloudstack/trunk/content/   (props changed)
    websites/staging/cloudstack/trunk/content/bylaws.html

Propchange: websites/staging/cloudstack/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Aug 15 22:56:33 2013
@@ -1 +1 @@
-1511430
+1514527

Modified: websites/staging/cloudstack/trunk/content/bylaws.html
==============================================================================
--- websites/staging/cloudstack/trunk/content/bylaws.html (original)
+++ websites/staging/cloudstack/trunk/content/bylaws.html Thu Aug 15 22:56:33 2013
@@ -272,62 +272,77 @@ project, the roles that have the right t
 corresponding approval required for that action and those who have binding
 votes over the action.</p>
 <p>3.4.1. Technical Decisions</p>
+<p>A technical decision is any decision that involves changes to the source code
+that we distribute in our official releases.</p>
 <p>Technical decisions should normally be made by the entire community using
-consensus&nbsp;gathering, and not through formal voting.</p>
-<p>Technical decisions must be made on a project development mailing list.</p>
+discussion-lead consensus gathering, and not through formal voting.</p>
+<p>Technical decisions must be made on the project development mailing list.</p>
 <p>During the consensus gathering process, technical decisions may be vetoed by
 any Committer with a valid reason.</p>
 <p>If a formal vote is started for a technical decision, the vote will be held as
-a lazy&nbsp;consensus&nbsp;of active committers.</p>
-<p>Any user, contributor, committer or PMC member can initiate a technical
+a lazy consensus of active committers.</p>
+<p>Any user, contributor, committer, or PMC member can initiate a technical
 decision making process.</p>
-<p>3.4.2. Release Plan</p>
+<p>3.4.2. Non-Technical Decisions</p>
+<p>A non-technical decisions is any decision that does not involve changes to the
+source code that we distribute in our official releases.</p>
+<p>Non-technical decisions should normally be made by the entire community using
+discussion-lead consensus-building, and not through formal voting.</p>
+<p>Non-technical decisions can be made on whichever project mailing list is most
+appropriate.</p>
+<p>Non-technical decisions cannot be vetoed, but if there is strong opposition
+a formal vote can be used to resolve the dispute.</p>
+<p>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.</p>
+<p>Any user, contributor, committer, or PMC member can initiate a non-technical
+decision making process.</p>
+<p>3.4.3. Release Plan</p>
 <p>Defines the timetable and work items for a release. The plan also nominates a
 Release Manager.</p>
 <p>A lazy majority of active committers is required for approval.</p>
-<p>Any active committer or PMC member may call a vote. The vote must occur on a
+<p>Any active committer or PMC member may call a vote. The vote must occur on the
 project development mailing list.</p>
-<p>3.4.3. Product Release</p>
+<p>3.4.4. Product Release</p>
 <p>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.</p>
 <p>Lazy Majority of active PMC members is required for approval.</p>
-<p>Any active committer or PMC member may call a vote. The vote must occur on a
+<p>Any active committer or PMC member may call a vote. The vote must occur on the
 project development mailing list.</p>
-<p>3.4.4. Adoption of New Codebase</p>
+<p>3.4.5. Adoption of New Codebase</p>
 <p>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
 base will continue.</p>
 <p>This also covers the creation of new sub-projects within the project.</p>
 <p>Lazy 2/3 majority of active PMC members.</p>
-<p>Any active committer or PMC member may call a vote. The vote must occur on a
+<p>Any active committer or PMC member may call a vote. The vote must occur on the
 project development mailing list.</p>
-<p>3.4.5. New Committer</p>
+<p>3.4.6. New Committer</p>
 <p>When a new committer is proposed for the project.</p>
 <p>Lazy consensus of active PMC members.</p>
 <p>Any active PMC member may call a vote. The vote must occur on the PMC private
 mailing list.</p>
-<p>3.4.6. New PMC Member</p>
+<p>3.4.7. New PMC Member</p>
 <p>When a committer is proposed for the PMC.</p>
 <p>Lazy consensus of active PMC members.</p>
 <p>Any active PMC member may call a vote. The vote must occur on the PMC private
 mailing list.</p>
-<p>3.4.7. Committer Removal</p>
+<p>3.4.8. Committer Removal</p>
 <p>When removal of commit privileges is sought. Note: Such actions will also be
 referred to the ASF board by the PMC chair</p>
 <p>Lazy 2/3 majority of active PMC members (excluding the committer in question if
 a member of the PMC).</p>
 <p>Any active PMC member may call a vote. The vote must occur on the PMC private
 mailing list.</p>
-<p>3.4.8. PMC Member Removal</p>
+<p>3.4.9. PMC Member Removal</p>
 <p>When removal of a PMC member is sought. Note: Such actions will also be
 referred to the ASF board by the PMC chair.</p>
 <p>Lazy 2/3 majority of active PMC members (excluding the member in question)</p>
 <p>Any active PMC member may call a vote. The vote must occur on the PMC private
 mailing list.</p>
-<p>3.4.9. Modifying Bylaws</p>
+<p>3.4.10. Modifying Bylaws</p>
 <p>Modifying this document.</p>
 <p>Lazy majority of active PMC members</p>
-<p>Any active committer or PMC member may call a vote. The vote must occur on a
+<p>Any active committer or PMC member may call a vote. The vote must occur on the
 project development mailing list.</p>
 <p>3.5. Voting Timeframes</p>
 <p>Formal votes are open for a period of at least 72 hours to allow all active