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 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 consensus 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
