Author: buildbot
Date: Sun Sep 22 20:24:29 2013
New Revision: 879480
Log:
Staging update by buildbot for openoffice
Modified:
websites/staging/openoffice/trunk/content/ (props changed)
websites/staging/openoffice/trunk/content/orientation/decision-making.html
Propchange: websites/staging/openoffice/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun Sep 22 20:24:29 2013
@@ -1 +1 @@
-1525211
+1525436
Modified:
websites/staging/openoffice/trunk/content/orientation/decision-making.html
==============================================================================
--- websites/staging/openoffice/trunk/content/orientation/decision-making.html
(original)
+++ websites/staging/openoffice/trunk/content/orientation/decision-making.html
Sun Sep 22 20:24:29 2013
@@ -100,49 +100,72 @@
<h1 class="title">Decision Making</h1>
<p>In this Orientation Module you will learn about Decision Making within
the project. As with the previous Level 1 Module, if you have prior experience
with an
open source software project, especially one at Apache, then much of this
material will already be familiar to you.</p>
-<ol>
-<li>
<p>In the previous Module we read about collaboration on the mailings lists,
how to do it efficiently and how to avoid the most common pitfalls. We use the
mailing lists for many things,
for asking questions, for sharing information or the like. But one of the
most important uses of the mailing list is for decision making. It is
important to understand
how decisions are made in an Apache community. Here are a few general
principles that you should keep in mind:</p>
<ol>
<li>
-<p>There are two primary ways of managing product changes, which go by the
names Commit-Then-Review (CTR) and Review-Then-Commit (RTC). For most cases we
operate in a CTR mode,
+<p>Commit-Then-Review (CTR) and Review-Then-Commit (RTC). </p>
+<p>The two primary ways of managing product changes go by the names
Commit-Then-Review (CTR) and Review-Then-Commit (RTC). For most cases we
operate in a CTR mode,
meaning that our <a
href="http://www.apache.org/foundation/how-it-works.html#committers";>Committers</a>
are able to check in changes as they desire, with no advance approval or
review.</p>
-</li>
-<li>
<p>We trust our Committers to do the right thing. By default Committers don't
ask permission before acting. They avoid unnecessary discussion and email
traffic. This is not
because they are anti-social. This is because they realize that in a project
of this size it is impossible to discuss every small change in advance.
Discussing too much is both
unnecessary and unproductive. We have a "time machine" called Subversion that
allows us to undo any changes to the product or website. So if a Committer
believes that a
change would be uncontroversial, and the change is reversible, then the
default approach is to go ahead make the change.</p>
+<p>Terms that you might need to know related to the above are: <a
href="http://www.urbandictionary.com/define.php?term=JFDI";>JFDI</a> and <a
href=".http://www.apache.org/foundation/glossary.html#LazyConsensus";>"assuming
lazy consensus"</a>.</p>
</li>
<li>
-<p>Terms that you might need to know related to the above are: <a
href="http://www.urbandictionary.com/define.php?term=JFDI";>JFDI</a> and
"assuming lazy consensus".</p>
+<p>When is RTC, Review-Then-Commit Used?</p>
+<p>There are times where CTR is not appropriate and RTC is used. This
happens, for example, at the end of a release cycle, when we want to carefully
review changes made to the product, in order to control the final quality
before the release. When we're in RTC mode, no changes are made to the code
unless first discussed and approved
+on the mailing list.</p>
+<p>Other situations when RTC is used instead of CTR might include:</p>
+<ol>
+<li>
+<p>A Committer is unsure of the technical merits of what they want to do.
+They want an extra pair of eyes to review the proposal point out
+weaknesses, alternatives, etc.</p>
</li>
<li>
-<p>However, there are times where CTR is not appropriate and RTC is used.
This happens, for example, at the end of a release cycle, when we want to
carefully review
-changes made to the product, in order to control the final quality before the
release. When we're in RTC mode, no changes are made to the code unless first
discussed and approved
-on the mailing list.</p>
+<p>A change is a job for more than one person or requires coordination
+across several subgroups within the project. </p>
+</li>
+<li>
+<p>A change to one of our websites that impacts terms and conditions,
+license, copyright, branding, etc. So not a technical change, but a
+substantive change to content in these areas. These require PMC
+review.</p>
+</li>
+<li>
+<p>A technical change that breaks backwards compatibility of the product.</p>
</li>
<li>
-<p>A Committer can also voluntarily invocate a RTC on their own changes. For
example the Committer might be considering a change that is of greater
significance. Maybe he would
-value additional input, or technical review. Maybe the change is
controversial or require coordination. If CTR is not appropriate then one can
make a proposal and send it to
-the dev mailing list. </p>
+<p>Changes that break things. Sometimes this is unavoidable. But it
+should be proposed and coordinated like #2 above.</p>
</li>
<li>
-<p>The convention is to send all proposals in their own new thread. (Don't
hide a proposal 10 posts deep in an existing thread). Put "[PROPOSAL]" in the
subject line or
-make it obvious that you are making a proposal.</p>
+<p>Changes that cannot easily be reversed. Code changes and most
+website changes are in SVN and can be reverted. But some changes,
+like administrative bulk actions in BZ, cannot be easily undone.</p>
</li>
<li>
-<p>Because the Volunteers are spread out all across the globe, in various time
zones, and many have day jobs or other committments, the convention is to wait
<em>at least</em> 72 hours
-for feedback on a proposal.</p>
+<p>Public statements in behalf of the project, e.g., some blog posts
+and announcements, press releases, etc.</p>
+</li>
+</ol>
+<p>In all of the above cases, a Proposal detailing the change is sent to the
development list.</p>
</li>
<li>
+<p>Proposals</p>
+<p>The convention is to send all proposals in their own new thread. (Don't
hide a proposal 10 posts deep in an existing thread). Put "[PROPOSAL]" in the
subject line or make it obvious that you are making a proposal.</p>
+<p>Because the Volunteers are spread out all across the globe, in various time
zones, and many have day jobs or other committments, the convention is to wait
<em>at least</em> 72 hours for feedback on a proposal.</p>
<p>In cases where the proposer wants to act on their proposal, if there are no
objections, they should state this in the proposal. For example, "If there are
no objections voiced
-within 72 hours, I'll go ahead and make these changes". This is called
"stating lazy consensus". You can read more about lazy consensus
-<a
href="http://openoffice.apache.org/docs/governance/lazyConsensus.html";>here</a>.</p>
+ within 72 hours, I'll go ahead and make these changes". This is called
"stating lazy consensus". You can read more about lazy consensus
+ <a
href="http://openoffice.apache.org/docs/governance/lazyConsensus.html";>here</a>.</p>
</li>
<li>
+<p>Voting, Consensus, and Vetoes</p>
+<ol>
+<li>
<p>In Apache projects it is common to use a shorthand way of responding to
proposals, where +1 indicates approval, 0 indicates indifference and -1
indicates disapproval.</p>
</li>
<li>
@@ -162,14 +185,14 @@ about this topic.</p>
</li>
<li>
<p>To apply the above skills, be sure you are subscribed to the project's <a
href="http://openoffice.apache.org/mailing-lists.html#development-mailing-list";>main
mailing list</a>.
-Keep your eye out for terms like "proposal", "lazy consensus", "vote" or
"veto" and see how they are used in practice. Compare actual practice to the
above descriptions. No, we're
-not perfect. But we work best and have the most fun when we follow the above
guidelines. And so will you when you apply then in your own list
communications!</p>
-</li>
-<li>
-<p>Congratulations, you have completed this Module! If you have any questions
or feedback on this module,
-please send a note to <a
href="mailto:[email protected]?subject=Comments%20on%20Decision%20Making%20Module";>[email protected]</a>.</p>
+Keep your eye out for terms like "proposal", "lazy consensus", "vote" or
"veto" and see how they are
+used in practice. Compare actual practice to the above descriptions. No,
we're
+not perfect. But we work best and have the most fun when we follow the above
guidelines. And so will
+you when you apply then in your own list communications!</p>
</li>
</ol>
+<p>Congratulations, you have completed this Module! </p>
+<p>If you have any questions or feedback on this module, please send a note to
<a
href="mailto:[email protected]?subject=Comments%20on%20Decision%20Making%20Module";>[email protected]</a>.</p>
</div>
<div id="footera">
