Return-Path: X-Original-To: apmail-incubator-ooo-commits-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-commits-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 902D1DA62 for ; Tue, 23 Oct 2012 20:45:26 +0000 (UTC) Received: (qmail 33563 invoked by uid 500); 23 Oct 2012 20:45:26 -0000 Delivered-To: apmail-incubator-ooo-commits-archive@incubator.apache.org Received: (qmail 33522 invoked by uid 500); 23 Oct 2012 20:45:26 -0000 Mailing-List: contact ooo-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-commits@incubator.apache.org Received: (qmail 33515 invoked by uid 99); 23 Oct 2012 20:45:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Oct 2012 20:45:26 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Oct 2012 20:45:23 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 993A22388A3D for ; Tue, 23 Oct 2012 20:44:38 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r835934 - in /websites/staging/openofficeorg/trunk/content: ./ openofficeorg/orientation/index.html openofficeorg/orientation/level-1.html openofficeorg/orientation/level-2.html Date: Tue, 23 Oct 2012 20:44:37 -0000 To: ooo-commits@incubator.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20121023204438.993A22388A3D@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: buildbot Date: Tue Oct 23 20:44:37 2012 New Revision: 835934 Log: Staging update by buildbot for openofficeorg Modified: websites/staging/openofficeorg/trunk/content/ (props changed) websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/index.html websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-1.html websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-2.html Propchange: websites/staging/openofficeorg/trunk/content/ ------------------------------------------------------------------------------ --- cms:source-revision (original) +++ cms:source-revision Tue Oct 23 20:44:37 2012 @@ -1 +1 @@ -1401410 +1401456 Modified: websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/index.html ============================================================================== --- websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/index.html (original) +++ websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/index.html Tue Oct 23 20:44:37 2012 @@ -117,7 +117,7 @@ specialized are of the project, like Qua

Introduction to Contributing to Apache OpenOffice

Intermediate Social and Technical Tools

Introductory Specialized Areas

Modified: websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-1.html ============================================================================== --- websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-1.html (original) +++ websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-1.html Tue Oct 23 20:44:37 2012 @@ -176,7 +176,7 @@ and Level 2.

Modified: websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-2.html ============================================================================== --- websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-2.html (original) +++ websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/level-2.html Tue Oct 23 20:44:37 2012 @@ -97,11 +97,75 @@

Level 2: Intermediate Social and Technical Tools

In this 2nd Orientation Module you will learn about some additional tools, both social and technical, which are widely used in this project: Lazy Concensus, Apache-style voting, Subversion and the Apache CMS.

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.

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.

Steps to Complete Level 2

Step 1
+
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:
+
1. +
  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, +meaning that our Committers are able to check in changes as they desire, with no advance approval or review.
  +
2. +
  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.
  +
3. +
  Terms that you might related to the above are: JFDI and "assuming lazy consensus".
  +
4. +
  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.
  +
5. +
  A Committer can also voluntarily invocate a RTC on their own changes. For example the Committer might be considering a change that 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 ooo-dev mailing list.
  +
  +
6. +
  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.
  +
7. +
  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 at least 72 hours +for feedback on a proposal.
  +
8. +
  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 +here.
  +
9. +
  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.
  +
10. +
  In most cases proposals are decided by consensus, based on community discussions. Only in rare cases, and in a small number of pre-defined administrative questions, do we resort +to a formal counting of votes. The places where we require voting are: voting to release, voting in a new Committer or PMC Member, Voting in a new PMC Chair. That's it. Generally +speaking, voting on any other topic is avoided in favor of consensus building. With voting there are winners and losers. With consensus everyone wins.
  +
11. +
  Another aspect of decision making in an Apache project is the "veto". Every Committer has the ability to "veto" a change, for technical reasons, provided he explains +the technical reasons for the veto, describes an alternative approach, and offers to help implement the alternative approach. Vetos are quite rare.
  +
12. +
  There is one disorder of community decision making that is common enough to warrant a colorful name: bikeshedding. Follow the link and read more +about this topic.
  +
+
+
To apply the above skills, be sure you are subscribed to the project's main mailing list. +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!
+