| The Free and Open Productivity Suite

@@ -78,11 +78,10 @@

Project Management PPMC

Project Management PMC

The Apache Software Foundation

Modified: websites/staging/openofficeorg/trunk/content/openofficeorg/docs/governance/lazyConsensus.html ============================================================================== --- websites/staging/openofficeorg/trunk/content/openofficeorg/docs/governance/lazyConsensus.html (original) +++ websites/staging/openofficeorg/trunk/content/openofficeorg/docs/governance/lazyConsensus.html Thu Oct 25 00:06:07 2012 @@ -41,7 +41,7 @@

| The Free and Open Productivity Suite

@@ -78,11 +78,10 @@

Security Reports

Developer FAQs

Project Management PPMC

Project Management PMC

The Apache Software Foundation

Modified: websites/staging/openofficeorg/trunk/content/openofficeorg/docs/governance/voting.html ============================================================================== --- websites/staging/openofficeorg/trunk/content/openofficeorg/docs/governance/voting.html (original) +++ websites/staging/openofficeorg/trunk/content/openofficeorg/docs/governance/voting.html Thu Oct 25 00:06:07 2012 @@ -41,7 +41,7 @@

| The Free and Open Productivity Suite

@@ -78,11 +78,10 @@

Security Reports

Developer FAQs

Project Management PPMC

Project Management PMC

The Apache Software Foundation

@@ -103,7 +102,7 @@ release.

Before calling a vote it is important to ensure that the community is given time to discuss the upcoming vote. This will be done by posting an email to the list indicating the intention to call a vote and the options available. By the time a -vote is called there should already be consensus in the community. The vote +vote is called there should already be consensus in the community. The vote itself is, normally, a formality.

Calling a Vote

Once it is time to call the vote a mail is posted with a subject starting with Added: websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/decision-making.html ============================================================================== --- websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/decision-making.html (added) +++ websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/decision-making.html Thu Oct 25 00:06:07 2012 @@ -0,0 +1,193 @@ + + + + + + + +Level 2: 1. [Decision Making](level-2.html) + + + + + + +

+ +

General

Community

Development

Project Management PMC

Project Blog
PMC FAQs
+

The Apache Software Foundation

+ +

Level 2: 1. [Decision Making](level-2.html)

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.

Steps to Complete Level 2

+
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!
+
+
Finally, once you have done the above, Edit the volunteers wiki page to indicate that you have completed Level 2. Congratulations! PAlso, please send a note to +ooo-dev@incubator.apache.org so we all know you have completed this level. This is a good opportunity +to send along any feedback or questions you might have on this Orientation Module.
+

+ +

+ Apache and the Apache feather logos are trademarks of The Apache Software Foundation. + OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. + Other names appearing on the site may be trademarks of their respective owners. +

+ +

+ + + 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 Thu Oct 25 00:06:07 2012 @@ -104,7 +104,7 @@ community-led open source projects the w provide key information and help you develop key skills needed to contribute effectively to the project.

Four Levels

We've designed the Orientation Modules in four levels:

The first two are focused on general project-wide community, process and tooling information. These modules provide the information that every contributor should aim to understand, +

The first two are focused on general project-wide community participation skills. These modules provide the information that every contributor should aim to understand, whether they are writing C++ code or user documentation. An experienced open source developer, especially one with prior experience at Apache, should be able to skim through these modules, since much will be familiar.

Once you have completed these first two Levels, you will have been exposed to the basic skills that enable you to volunteer as a general contributor, or to dive deeper into a @@ -112,32 +112,35 @@ specialized are of the project, like Qua

Levels 3 and 4 are specialized Levels, that focus on basic and intermediate knowledge, processes, tools and skills related to that specific area.

Available Orientation Modules

The Orientation Modules for the various Levels are under active development. An outline of the anticipated modules is as follows, with links to the ones currently available:

-
Introduction to Contributing to Apache OpenOffice
+
Level 1: Introduction to Contributing to Apache OpenOffice
-
Intermediate Social and Technical Tools
+
Level 2: Decision Making and Do-ocracy
-
Introductory Specialized Areas
-
1. Introduction to Apache OpenOffice Development
2. Introduction to Apache Openoffice QA
3. Introduction to Apache Openoffice Localization
4. Introduction to Apache Openoffice Marketing
+
Level 2: The Subversive Wikijirazilla? Making sense of Project's Technical Infrastructure
-
Intermediate Specialized Areas
-
1. Intermediate Apache OpenOffice Development
2. Intermediate Apache Openoffice QA
3. Intermediate to Apache Openoffice Localization
4. Intermediate to Apache Openoffice Marketing
+
Level 3: Introductory Specialized Areas
+
- Introduction to Programming
- Introduction to QA
- Introduction to Localization
- Introduction to Marketing

Level 4: Intermediate Specialized Areas

Intermediate Programming
Intermediate QA
Intermediate Localization
Intermediate Marketing

Added: websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/intro-contributing.html ============================================================================== --- websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/intro-contributing.html (added) +++ websites/staging/openofficeorg/trunk/content/openofficeorg/orientation/intro-contributing.html Thu Oct 25 00:06:07 2012 @@ -0,0 +1,202 @@ + + + + + + + +Level 1: Introduction to Contributing to Apache OpenOffice + + + + + + + +

+ +

General

Community

Development

Project Management PMC

Project Blog
PMC FAQs
+

The Apache Software Foundation

+ +

Level 1: Introduction to Contributing to Apache OpenOffice

In this Orientation Module you will gain basic familiarity with the Apache Software Foundation and how it works, +get signed up for various important online project services, and introduce yourself to the other volunteers on +the project's mailing mailing list.
+

Level 1 is focused on connecting you to the project.

If you have prior experience with an open source software project, especially one at +Apache, then much of this will already be familiar to you.

Steps to Complete Level 1

+
Introduce yourself to the other project Volunteers by sending an email to our main public +mailing list ooo-dev@incubator.apache.org. Who are you, where +are you from, what are you interested in? These are all good things to cover. Also, as you work through the +items on this page, if you have questions or problems, please feel free to ask for help by sending a note to +this list.
+
+
It is important that you understand a little about the Apache Software Foundation and OpenOffice, +what it is, how it is organized and how the Apache OpenOffice Project fits into the overall Foundation. This is partially +organizational knowledge and a little history. But it is important for understanding how things work here, +and understanding the culture of this open source community. Suggested readings are:
+
1. How It Works (to learn about how the ASF is organized and how its meritocracy works)
2. ASF FAQ's (browse to see if it answers any questions you might have)
3. OpenOffice Wikipedia article (for basic historical background)
4. 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star
+
+
As a globally-distributed all-volunteer open source project, there is never a time or place where we can +all meet together in the same room or even on a telephone call. Because of this, and out of respect for +everyone's busy and varying schedule, we use mailing lists to coordinate our work, make proposals, gather +consensus and resolve community issues. There are three mailing lists that every Volunteer should be on:
+
1. ooo-dev This is the +main mailing list for the project, and gets a lot of traffic. But this is where project-wide discussions occur.
2. ooo-announce This +is the official announcement list for the project. It is used for announcing things like new releases, +security patches, conferences, etc.
3. ooo-users This is our users +list and is one way in which we provide support to end users. Although you may not be interested specifically +in user support, it is still recommended that you follow this list, even if just to get a feel for +user concerns, problems, feature ideas, etc.
+
+
You can also review other mailing lists we host and which may be of interest, including ones focused on +specific project functions and +native languages.
+
+
One of the first practical tests each Volunteer faces is dealing with the volume of emails that comes from +participation in an open source project like this. A good email client for this kind of work will support +folders, rule-based folder assignments, and most importantly quote collapsing. A common practice is to make +a separate folder for each Apache mailing list and define a rule to move incoming emails directly into that folder. +If you have a question on how to configure your email client to do these things, try your help files, +or a web search first, and if that fails post a question to the ooo-dev list.
+
+
Because our mailing lists can be busy, and we're not all native English speakers, and because email text is +a crude medium which makes it hard to express nuanced emotions, we need to be careful and tolerant in how we +use it. Please read over our Participation Guidelines +and List Conduct Guidelines for more information.
+
+
From Karl Fogel's book "Producing Open Source Software" read through +"You Are What You Write" and "Avoiding Common Pitfalls".
+
+
Aside from the mailing lists there are several online services that every volunteer should be signed up for:
+
1. Our MediaWiki (sometimes called MWiki) used for user documentation and many other things.
2. Our ConfluenceWiki (sometimes called CWiki) where we do project planning.
3. Our Bugzilla database (sometimes called BZ) where we report and track status on bugs.
4. Our Community Forums These are available in several languages. This is the primary way in which we engage with the user community.
5. Join our Social Networks
+
+
Finally, once you have done the above, Edit this wiki page TBD containing project volunteers. Add your name +and indicate that you have completed Level 1. Congratulations! Please send a note to ooo-dev@incubator.apache.org +so we know you are ready for Level 2.
+

+ +

+ + +