You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@openoffice.apache.org by ma...@apache.org on 2016/10/21 15:39:58 UTC
svn commit: r1766050 [1/2] - /openoffice/site/trunk/content/orientation/
Author: marcus
Date: Fri Oct 21 15:39:57 2016
New Revision: 1766050
URL: http://svn.apache.org/viewvc?rev=1766050&view=rev
Log:
Fixed white-spaces
Modified:
openoffice/site/trunk/content/orientation/decision-making.mdtext
openoffice/site/trunk/content/orientation/how-aoo-project-works.mdtext
openoffice/site/trunk/content/orientation/index.mdtext
openoffice/site/trunk/content/orientation/infrastructure.mdtext
openoffice/site/trunk/content/orientation/intro-contributing.mdtext
openoffice/site/trunk/content/orientation/intro-development.mdtext
openoffice/site/trunk/content/orientation/intro-doc.mdtext
openoffice/site/trunk/content/orientation/intro-l10n.mdtext
openoffice/site/trunk/content/orientation/intro-marketing.mdtext
openoffice/site/trunk/content/orientation/intro-qa.mdtext
Modified: openoffice/site/trunk/content/orientation/decision-making.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/decision-making.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/decision-making.mdtext (original)
+++ openoffice/site/trunk/content/orientation/decision-making.mdtext Fri Oct 21 15:39:57 2016
@@ -16,89 +16,72 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-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.
+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.
-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. Commit-Then-Review (CTR) and Review-Then-Commit (RTC).
-
- 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 [Committers](http://www.apache.org/foundation/how-it-works.html#committers) are able to check in changes as they desire, with no advance approval or review.
-
- 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.
+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. Commit-Then-Review (CTR) and Review-Then-Commit (RTC).
+
+ 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 [Committers](http://www.apache.org/foundation/how-it-works.html#committers) are able to check in changes as they desire, with no advance approval or review.
+
+ 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.
Terms that you might need to know related to the above are: [JFDI](http://www.urbandictionary.com/define.php?term=JFDI) and ["assuming lazy consensus"](.http://www.apache.org/foundation/glossary.html#LazyConsensus).
2. When is RTC, Review-Then-Commit Used?
-
- 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.
-
+
+ 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.
+
Other situations when RTC is used instead of CTR might include:
- 1. 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.
-
- 2. A change is a job for more than one person or requires coordination
- across several subgroups within the project.
-
- 3. 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.
+ 1. 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.
+
+ 2. A change is a job for more than one person or requires coordination across several
+ subgroups within the project.
+
+ 3. 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.
4. A technical change that breaks backwards compatibility of the product.
- 5. Changes that break things. Sometimes this is unavoidable. But it
- should be proposed and coordinated like #2 above.
+ 5. Changes that break things. Sometimes this is unavoidable. But it should be
+ proposed and coordinated like #2 above.
- 6. 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.
+ 6. 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.
- 7. Public statements in behalf of the project, e.g., some blog posts
- and announcements, press releases, etc.
+ 7. Public statements in behalf of the project, e.g., some blog posts and
+ announcements, press releases, etc.
- In all of the above cases, a Proposal detailing the change is sent to the development list.
+ In all of the above cases, a Proposal detailing the change is sent to the development
+ list.
3. Proposals
-
- 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.
+
+ 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.
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.
-
- 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](http://openoffice.apache.org/docs/governance/lazyConsensus.html).
-
+
+ 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](http://openoffice.apache.org/docs/governance/lazyConsensus.html).
+
4. Voting, Consensus, and Vetoes
-
+
1. 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.
-
- 2. 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.
-
- 3. 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.
-
- 4. There is one disorder of community decision making that is common enough to warrant a colorful name: [bikeshedding](http://bikeshed.com/). Follow the link and read more
- about this topic.
-
-
- 5. To apply the above skills, be sure you are subscribed to the project's [main mailing list](http://openoffice.apache.org/mailing-lists.html#development-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!
-Congratulations, you have completed this Module!
+ 2. 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.
+
+ 3. 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.
+
+ 4. There is one disorder of community decision making that is common enough to warrant a colorful name: [bikeshedding](http://bikeshed.com/). Follow the link and read more about this topic.
+
+ 5. To apply the above skills, be sure you are subscribed to the project's [main mailing list](http://openoffice.apache.org/mailing-lists.html#development-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!
+
+Congratulations, you have completed this Module!
If you have any questions or feedback on this module, please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Comments on Decision Making Module).
Modified: openoffice/site/trunk/content/orientation/how-aoo-project-works.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/how-aoo-project-works.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/how-aoo-project-works.mdtext (original)
+++ openoffice/site/trunk/content/orientation/how-aoo-project-works.mdtext Fri Oct 21 15:39:57 2016
@@ -18,19 +18,16 @@ Notice: Licensed to the Apache Softwa
1. Please send an email to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Starting How the Apache OpenOffice Project Works) to let us know you are working on this module.
-1. As you learned in the [previous module](intro-contributing.html) the Apache Software Foundation formally has Members, who elect a Board of Directors who appoint Officers, including
-PMC (Project Management Committee) Chairs, who work with the PMC's of the individual Top Level Projects and their communities, to publish open source software for the public good. In
-this module we'll take a closer look at how exactly we accomplish this within the Apache OpenOffice project, how we divide up the tasks and get all the stuff done that is needed to release a new version of
-OpenOffice.
+1. As you learned in the [previous module](intro-contributing.html) the Apache Software Foundation formally has Members, who elect a Board of Directors who appoint Officers, including PMC (Project Management Committee) Chairs, who work with the PMC's of the individual Top Level Projects and their communities, to publish open source software for the public good. In this module we'll take a closer look at how exactly we accomplish this within the Apache OpenOffice project, how we divide up the tasks and get all the stuff done that is needed to release a new version of OpenOffice.
1. Volunteers in the project tend to self-identify themselves in one or more of the following categories, depending on their interests, skills and contributitions:
* Developers are the programmers who write, debug and fix the C++ code that is the core of the OpenOffice software.
- * QA (Quality Assurance) are the volunteers to test OpenOffice builds, looking for bugs. They also develop test automation and test cases.
+ * QA (Quality Assurance) are the volunteers to test OpenOffice builds, looking for bugs. They also develop test automation and test cases.
* Support are the volunteers who answer user questions on our Community Forums and User list.
* UX (Usability)
* Localization/Internationalization are the volunteers whose expertise is in adapting OpenOffice so it works well with the writing and other cultural conventions and expectations of
- users around the globe. This includes translations and related activities.
+ users around the globe. This includes translations and related activities.
* Documentation
* Admins, including moderators,
* Marketing
@@ -44,5 +41,4 @@ OpenOffice.
* Conference Committee (ConCom)
* Incubator
-1. Congratulations! You have completed this Level. Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed How the Apache OpenOffice Project Works) so
-we all know you have completed this level. This is also a good opportunity to send along any feedback or questions you might have on this Orientation Module.
+1. Congratulations! You have completed this Level. Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed How the Apache OpenOffice Project Works) so we all know you have completed this level. This is also a good opportunity to send along any feedback or questions you might have on this Orientation Module.
Modified: openoffice/site/trunk/content/orientation/index.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/index.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/index.mdtext (original)
+++ openoffice/site/trunk/content/orientation/index.mdtext Fri Oct 21 15:39:57 2016
@@ -17,30 +17,25 @@ Notice: Licensed to the Apache Softwa
under the License.
##Welcome!
-So you are interested in volunteering with the Apache OpenOffice project, one of the oldest and most famous open source projects around? Great, welcome to the project!
-Getting involved in a large open source project can be a little intimidating. There is so much going on, so many new names, new processes, new ways of communicating. It can be
-confusing, even frustrating at first. In some ways, maybe at the technical level, it is similar to other software development projects you may be familiar with. But as a
-community-led open source project the ways we work, communicate, make decisions, and resolve disputes are very different than what you might see in other environments.
+So you are interested in volunteering with the Apache OpenOffice project, one of the oldest and most famous open source projects around? Great, welcome to the project!
-In order to help new Volunteers fit into the OpenOffice Community and understand socially and technically how we work, we have created a set of self-directed Orientation Modules to
-provide key information and help you develop key skills needed to contribute effectively to the project.
+Getting involved in a large open source project can be a little intimidating. There is so much going on, so many new names, new processes, new ways of communicating. It can be confusing, even frustrating at first. In some ways, maybe at the technical level, it is similar to other software development projects you may be familiar with. But as a community-led open source project the ways we work, communicate, make decisions, and resolve disputes are very different than what you might see in other environments.
+In order to help new Volunteers fit into the OpenOffice Community and understand socially and technically how we work, we have created a set of self-directed Orientation Modules to 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 participation skills. These modules provide the information that every contributor should aim to understand,
-whether they are writing C++ code or user documentation.
+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.
* Level 1: [Introduction to Contributing to Apache OpenOffice](intro-contributing.html) and [How the Apache OpenOffice Project Works](how-aoo-project-works.html)
* Level 2: [Decision Making](decision-making.html) and [Making sense of Project's Technical Infrastructure](infrastructure.html)
-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
-specialized area of the project, like Quality Assurance, Marketing, Translation or Development.
+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 specialized area of the project, like Quality Assurance, Marketing, Translation or Development.
Levels 3 and 4 are specialized Levels, that focus on basic and intermediate knowledge, processes, tools and skills related to that specific area.
Modified: openoffice/site/trunk/content/orientation/infrastructure.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/infrastructure.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/infrastructure.mdtext (original)
+++ openoffice/site/trunk/content/orientation/infrastructure.mdtext Fri Oct 21 15:39:57 2016
@@ -16,71 +16,38 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-In this Orientation Module you will learn about tools and servers that are part of the daily operations of the project. You will interact with many of these on a regular basis,
-or at least hear them discussed on the lists, so it is important to know what they are, and where to go if you
-need more information or run into problems.
-
-1. First, Please send an email to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Starting Infrastructure Module)
-to let us know you are working on this module.
+In this Orientation Module you will learn about tools and servers that are part of the daily operations of the project. You will interact with many of these on a regular basis, or at least hear them discussed on the lists, so it is important to know what they are, and where to go if you need more information or run into problems.
+1. First, Please send an email to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Starting Infrastructure Module) to let us know you are working on this module.
1. List of tools and services we use
- * ezmlm: This is the time-tested EZ Mailing List Manager application that manages our mailing lists. You
-control ezmlm by sending commands to a list address. For example, if the list address is dev@openoffice.apache.org
-then you subscribe to the list with the command dev-**subscribe**@openoffice.apache.org. Some other popular commands
-are listed [here](http://www.apache.org/foundation/mailinglists.html). You can get a full list of commands
-available to you by sending the *help* command, as in dev-**help**@openoffice.apache.org. Each list has moderators
-who have additional capabilities. You can find the moderators for our lists [here](http://openoffice.apache.org/pmc-faqs.html#mailing-lists).
-
-
- * Our two websites: [www.openoffice.org](http://www.openoffice.org) and [openoffice.apache.org](http://openoffice.apache.org). Why two? There is some logic here,
-although it is not perfectly executed (yet). The www.openoffice.org website is our primary user-facing website. It is where we put content intended for end-users
-to use, so downloads, product documentations, support and other related materials. The openoffice.apache.org website, on the other hand, is the main portal for
-project members, the contributors to the project. We run the project on openoffice.apache.org, and the www.openoffice.org website is a service we provide to users.
-
- * MediaWiki (also called MWiki) is used for the wiki on the [wiki.openoffice.org](http://wiki.openoffice.org/wiki/Main_Page) website.
-We use MWiki for many of the user-facing pages on the website, especially in the areas of documentation and support. If you are familiar with Wikipedia and
-the syntax used for authoring articles there, then you will find our MediaWiki very easy to use, since Wikipedia
-also uses MediaWiki. If you are new to MediaWiki please read over this [introduction to the basics](http://meta.wikimedia.org/wiki/Help:Editing).
+ * ezmlm: This is the time-tested EZ Mailing List Manager application that manages our mailing lists. You control ezmlm by sending commands to a list address. For example, if the list address is dev@openoffice.apache.org then you subscribe to the list with the command dev-**subscribe**@openoffice.apache.org. Some other popular commands are listed [here](http://www.apache.org/foundation/mailinglists.html). You can get a full list of commands available to you by sending the *help* command, as in dev-**help**@openoffice.apache.org. Each list has moderators who have additional capabilities. You can find the moderators for our lists [here](http://openoffice.apache.org/pmc-faqs.html#mailing-lists).
+
+ * Our two websites: [www.openoffice.org](http://www.openoffice.org) and [openoffice.apache.org](http://openoffice.apache.org). Why two? There is some logic here, although it is not perfectly executed (yet). The www.openoffice.org website is our primary user-facing website. It is where we put content intended for end-users to use, so downloads, product documentations, support and other related materials. The openoffice.apache.org website, on the other hand, is the main portal for project members, the contributors to the project. We run the project on openoffice.apache.org, and the www.openoffice.org website is a service we provide to users.
+
+ * MediaWiki (also called MWiki) is used for the wiki on the [wiki.openoffice.org](http://wiki.openoffice.org/wiki/Main_Page) website. We use MWiki for many of the user-facing pages on the website, especially in the areas of documentation and support. If you are familiar with Wikipedia and the syntax used for authoring articles there, then you will find our MediaWiki very easy to use, since Wikipedia also uses MediaWiki. If you are new to MediaWiki please read over this [introduction to the basics](http://meta.wikimedia.org/wiki/Help:Editing).
* Confluence Wiki (also called CWiki) is used for some [project management webpages](https://cwiki.apache.org/confluence/display/OOOUSERS/Wiki+Home)
- * [Pootle](http://translate.apache.org) is our translation management server, an online service used by translators to translate the UI
-and help files of OpenOffice into various languages. Unless you are involved with translations or builds you probably will never use Pootle. But you will hear
-it mentioned on the mailing lists.
-
- * Apache CMS (Content Management System) is the software that manages our websites, including the application of side-wide templates used to apply, for example,
-the common page footers that occur on each page). There is a web interface to the Apache CMS that makes it easy to make small updates to a page. If you are interested
-in adding or editing the website you can watch this video on the [Apache CMS's Anonymous Mode](http://www.youtube.com/watch?v=7fvg1pfHLhE) now. Otherwise
-this is a valuable skill you can pick up later.
-
- * Subversion is the Version Control System (VCS) used by the project. Subversion is also its own Apache project. The source code for the OpenOffice product as well as
-the files for the websites are all stored in Subversion. Developers use Subversion heavily in their work. Advanced work in QA and bulk website changes also involve using
-Subversion.
+ * [Pootle](http://translate.apache.org) is our translation management server, an online service used by translators to translate the UI and help files of OpenOffice into various languages. Unless you are involved with translations or builds you probably will never use Pootle. But you will hear it mentioned on the mailing lists.
+
+ * Apache CMS (Content Management System) is the software that manages our websites, including the application of side-wide templates used to apply, for example, the common page footers that occur on each page). There is a web interface to the Apache CMS that makes it easy to make small updates to a page. If you are interested in adding or editing the website you can watch this video on the [Apache CMS's Anonymous Mode](http://www.youtube.com/watch?v=7fvg1pfHLhE) now. Otherwise this is a valuable skill you can pick up later.
+
+ * Subversion is the Version Control System (VCS) used by the project. Subversion is also its own Apache project. The source code for the OpenOffice product as well as the files for the websites are all stored in Subversion. Developers use Subversion heavily in their work. Advanced work in QA and bulk website changes also involve using Subversion.
* phpBB is the software that runs our [Community Forums](http://forum.openoffice.org/en/forum/), used for technical support of our users.
* [Bugzilla](https://issues.apache.org/ooo/) is used to track defect OpenOffice (bug) report.
- * [JIRA](https://issues.apache.org/jira/) is another issue tracking application. Some Apache projects use JIRA instead of Bugzilla. We mainly use JIRA when we
-need to raise an issue with another group at Apache that uses JIRA, for example the Apache Infrastructure Team.
+ * [JIRA](https://issues.apache.org/jira/) is another issue tracking application. Some Apache projects use JIRA instead of Bugzilla. We mainly use JIRA when we need to raise an issue with another group at Apache that uses JIRA, for example the Apache Infrastructure Team.
-1. It is important to understand the role of the [Apache Infrastructure Team](http://www.apache.org/dev/infrastructure.html)
-(Infra or Infra@. The Infrastructure team are essentially the system administrators for all Apache-wide servers and services,
-including many of the services described above. As you can imagine, with all the projects that are part of Apache, this is huge job.
-In order to support this number of projects and provide good service levels in this shared infrastructure environment, we align ourselves
-with the common services that are made available to other projects. In other words, we have a "menu" of services that we can enable for the project,
-and the ability to do some customization, within defined bounds, but we cannot easily use a service outside of that menu.
+1. It is important to understand the role of the [Apache Infrastructure Team](http://www.apache.org/dev/infrastructure.html) (Infra or Infra@. The Infrastructure team are essentially the system administrators for all Apache-wide servers and services, including many of the services described above. As you can imagine, with all the projects that are part of Apache, this is huge job. In order to support this number of projects and provide good service levels in this shared infrastructure environment, we align ourselves with the common services that are made available to other projects. In other words, we have a "menu" of services that we can enable for the project, and the ability to do some customization, within defined bounds, but we cannot easily use a service outside of that menu.
1. What to do if you have a problem:
- * Questions on how to use the service: First, look for intructions on the website. If that fails, post a note to the dev mailing list for hints.
- * Outages: [Current status](http://monitoring.apache.org/status/) is posted. You might also want to subscribe to Infra's [Twitter feed](https://twitter.com/infrabot).
- If you see an outage not noted there already, you can notify Infra via IRC channel #asfinfra on Freenode.
- * Requests to enhance or modify the service: Propose something on dev. Even though Infra is required to carry out some tasks, you still should get consensus
- first on the project's mailing list.
-
-1. Congratulations! You have completed this Module. Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed Infrastructure Module) so
-we all know you have completed this level. This is also a good opportunity to send along any feedback or questions you might have on this Orientation Module.
+ * Questions on how to use the service: First, look for intructions on the website. If that fails, post a note to the dev mailing list for hints.
+ * Outages: [Current status](http://monitoring.apache.org/status/) is posted. You might also want to subscribe to Infra's [Twitter feed](https://twitter.com/infrabot). If you see an outage not noted there already, you can notify Infra via IRC channel #asfinfra on Freenode.
+ * Requests to enhance or modify the service: Propose something on dev. Even though Infra is required to carry out some tasks, you still should get consensus first on the project's mailing list.
+1. Congratulations! You have completed this Module. Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed Infrastructure Module) so we all know you have completed this level. This is also a good opportunity to send along any feedback or questions you might have on this Orientation Module.
Modified: openoffice/site/trunk/content/orientation/intro-contributing.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/intro-contributing.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/intro-contributing.mdtext (original)
+++ openoffice/site/trunk/content/orientation/intro-contributing.mdtext Fri Oct 21 15:39:57 2016
@@ -16,76 +16,44 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-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.
+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.
-1. Introduce yourself to the other project Volunteers by sending an email to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Starting Introduction to Contributing to Apache OpenOffice Module). 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.
-
-1. 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. Introduce yourself to the other project Volunteers by sending an email to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Starting Introduction to Contributing to Apache OpenOffice Module). 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.
+
+1. 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](http://apache.org/foundation/how-it-works.html) (to learn about how the ASF is organized and how its meritocracy works)
1. [ASF FAQ's](http://www.apache.org/foundation/faq.html) (browse to see if it answers any questions you might have)
1. [OpenOffice Wikipedia article](http://en.wikipedia.org/wiki/OpenOffice) (for basic historical background)
1. [14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star](http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/)
-1. 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. [dev](http://openoffice.apache.org/mailing-lists.html#development-mailing-list) This is the
-main mailing list for the project, and gets a lot of traffic. But this is where project-wide discussions occur.
- 1. [announce](http://openoffice.apache.org/mailing-lists.html#announce-mailing-list) This
-is the official announcement list for the project. It is used for announcing things like new releases,
-security patches, conferences, etc.
- 1. [users](http://openoffice.apache.org/mailing-lists.html#users-mailing-list) 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.
-
-1. You can also review other mailing lists we host and which may be of interest, including ones focused on
-specific [project functions](http://openoffice.apache.org/mailing-lists.html) and
-[native languages](http://openoffice.apache.org/native-lang.html).
-
-1. A useful shortcut notation you will often see on the lists. Writing a list name in full, like dev@openoffice.apache.org can be tedious. So you will often see
-it called just "dev@". Similarly, top-level lists like trademarks@apache.org are often referred to as "trademarks@". This shortcut can be used to refer
-either to the mailing list and to the team that operates the mailing list. The context should make it clear, e.g., "You should check with trademarks@ on whether this will be problem".
-
-1. 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 dev list.
-
-1. 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](http://openoffice.apache.org/mailing-lists.html#participation-guidelines)
-and [List Conduct Guidelines](http://openoffice.apache.org/list-conduct.html) for more information.
+1. 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. [dev](http://openoffice.apache.org/mailing-lists.html#development-mailing-list) This is the main mailing list for the project, and gets a lot of traffic. But this is where project-wide discussions occur.
+ 1. [announce](http://openoffice.apache.org/mailing-lists.html#announce-mailing-list) This is the official announcement list for the project. It is used for announcing things like new releases, security patches, conferences, etc.
+ 1. [users](http://openoffice.apache.org/mailing-lists.html#users-mailing-list) 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.
+
+1. You can also review other mailing lists we host and which may be of interest, including ones focused on specific [project functions](http://openoffice.apache.org/mailing-lists.html) and [native languages](http://openoffice.apache.org/native-lang.html).
+
+1. A useful shortcut notation you will often see on the lists. Writing a list name in full, like dev@openoffice.apache.org can be tedious. So you will often see it called just "dev@". Similarly, top-level lists like trademarks@apache.org are often referred to as "trademarks@". This shortcut can be used to refer either to the mailing list and to the team that operates the mailing list. The context should make it clear, e.g., "You should check with trademarks@ on whether this will be problem".
+
+1. 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 dev list.
+
+1. 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](http://openoffice.apache.org/mailing-lists.html#participation-guidelines) and [List Conduct Guidelines](http://openoffice.apache.org/list-conduct.html) for more information.
-1. From Karl Fogel's book ["Producing Open Source Software"](http://producingoss.com/) read through
-["You Are What You Write"](http://producingoss.com/en/communications.html#you-are-what-you-write) and ["Avoiding Common Pitfalls"](http://producingoss.com/en/common-pitfalls.html).
+1. From Karl Fogel's book ["Producing Open Source Software"](http://producingoss.com/) read through ["You Are What You Write"](http://producingoss.com/en/communications.html#you-are-what-you-write) and ["Avoiding Common Pitfalls"](http://producingoss.com/en/common-pitfalls.html).
1. Aside from the mailing lists there are several online services that every volunteer should be signed up for:
1. Our [MediaWiki](http://wiki.openoffice.org/wiki/Main_Page) (sometimes called MWiki) used for user documentation and many other things.
1. Our [ConfluenceWiki](https://cwiki.apache.org/confluence/display/OOOUSERS/Wiki+Home) (sometimes called CWiki) where we do project planning.
- 1. Our [Bugzilla database](https://bz.apache.org/ooo/) (sometimes called BZ) where we report and track status on bugs.
- 1. Our [Community Forums](http://forum.openoffice.org/) These are available in several languages. This is the primary way in which we engage with the user community.
+ 1. Our [Bugzilla database](https://bz.apache.org/ooo/) (sometimes called BZ) where we report and track status on bugs.
+ 1. Our [Community Forums](http://forum.openoffice.org/) These are available in several languages. This is the primary way in which we engage with the user community.
1. Join our [Social Networks](http://openoffice.apache.org/social.html)
-1. Finally, once you have done the above, go to our our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) wiki page and add your
-information. Congratulations! Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed Introduction to Contributing to Apache OpenOffice Module)
-so we know.
+1. Finally, once you have done the above, go to our our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) wiki page and add your information. Congratulations! Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed Introduction to Contributing to Apache OpenOffice Module) so we know.
Modified: openoffice/site/trunk/content/orientation/intro-development.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/intro-development.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/intro-development.mdtext (original)
+++ openoffice/site/trunk/content/orientation/intro-development.mdtext Fri Oct 21 15:39:57 2016
@@ -18,48 +18,34 @@ Notice: Licensed to the Apache Softwa
##Introduction
-In this orientation module you will learn how to get started programming OpenOffice.
+In this orientation module you will learn how to get started programming OpenOffice.
-To complete this module, read through the material on this page, including the linked references. There will also
-be some start-up tasks for you to perform, such as signing up for an account in our defect tracking database.
+To complete this module, read through the material on this page, including the linked references. There will also be some start-up tasks for you to perform, such as signing up for an account in our defect tracking database.
-Your first task is to subscribe to our Recruitment mailing list. You can subscribe by sending an email to
-[recruitment-subscribe@openoffice.apache.org](mailto:recruitment-subscribe@openoffice.apache.org).
+Your first task is to subscribe to our Recruitment mailing list. You can subscribe by sending an email to [recruitment-subscribe@openoffice.apache.org](mailto:recruitment-subscribe@openoffice.apache.org).
-Then you can introduce yourself by [sending an email to the list](mailto:recruitment@openoffice.apache.org?subject=New Dev Volunteer).
-We'd love to hear who you are, where you are from, what your background is, etc. 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 same list.
+Then you can introduce yourself by [sending an email to the list](mailto:recruitment@openoffice.apache.org?subject=New Dev Volunteer). We'd love to hear who you are, where you are from, what your background is, etc. 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 same list.
-Note: In parallel with the Dev-specific items on this page, you may want to also review the [Level 1 and Level 2 Orientation Modules](http://openoffice.apache.org/orientation/index.html). They have useful background information on The Apache Way, mailing list etiquette, decision making in the
-project, etc. A quick review is a good idea, especially if you are new to working in Apache-style open source projects.
+Note: In parallel with the Dev-specific items on this page, you may want to also review the [Level 1 and Level 2 Orientation Modules](http://openoffice.apache.org/orientation/index.html). They have useful background information on The Apache Way, mailing list etiquette, decision making in the project, etc. A quick review is a good idea, especially if you are new to working in Apache-style open source projects.
Now with the introductions out of the way, let's get started!
##OpenOffice Development: Good, the Bad and the Ugly
-Let's be honest. The size, age and complexity of OpenOffice's C++ codebase makes coding a challenge. This is not a trivial codebase to learn. But if you like a good challenge then
-you'll love this project! There are tasks suitable for programmers with a range of programming experience, and we have many veteran OpenOffice hackers
-in the project who are happy to answer your questions.
-
-And in its favor, there are few other programs that you can help develop, that have the reach of OpenOffice. Many millions of users depend on OpenOffice,
-with another million downloads every week, downloads from almost every country in the world. So the work you do, the bugs you fix,
-the features you add, will benefit millions of users around the world.
+Let's be honest. The size, age and complexity of OpenOffice's C++ codebase makes coding a challenge. This is not a trivial codebase to learn. But if you like a good challenge then you'll love this project! There are tasks suitable for programmers with a range of programming experience, and we have many veteran OpenOffice hackers in the project who are happy to answer your questions.
+
+And in its favor, there are few other programs that you can help develop, that have the reach of OpenOffice. Many millions of users depend on OpenOffice, with another million downloads every week, downloads from almost every country in the world. So the work you do, the bugs you fix, the features you add, will benefit millions of users around the world.
## Building OpenOffice
-It all starts by establishing a local build environment. Building OpenOffice on Linux or Mac is relatively easy,
-but expect the first attempt to require some trial and error. Every configuration is slightly different.
+It all starts by establishing a local build environment. Building OpenOffice on Linux or Mac is relatively easy, but expect the first attempt to require some trial and error. very configuration is slightly different.
Building on Windows is more complicated, due to the need to install more prerequisite tools.
-Our [Building Guide](http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO) on the wiki is your starting point. Follow the instructions there, step by step. Ask questions on
-the dev list if you get stuck. If you get an error it can be useful to search our [mailing list archives](http://markmail.org/search/+list:org.apache.incubator.ooo-dev) to see if it
-is a known problem with a known solution.
+Our [Building Guide](http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO) on the wiki is your starting point. Follow the instructions there, step by step. Ask questions on the dev list if you get stuck. If you get an error it can be useful to search our [mailing list archives](http://markmail.org/search/+list:org.apache.incubator.ooo-dev) to see if it is a known problem with a known solution.
-Note also the current list of configuration flags used in building the development snapshot builds at the
-bottom of the [development snapshot builds page](https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1).
+Note also the current list of configuration flags used in building the development snapshot builds at the bottom of the [development snapshot builds page](https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1).
Although there are many other combinations of flags you can use, some of which are very useful for development, the flags on that page are what we use in our official releases.
Once you have a successful build, [post a note to the dev list](mailto:dev@openoffice.apache.org?subject=Successful 1st Build!) for some well-earned congratulations!
@@ -69,26 +55,20 @@ Once you have a successful build, [post
A few suggestions to help you find your way around this massive codebase:
- An explanation of the purpose/function of the various [source directories](http://wiki.openoffice.org/wiki/Source_code_directories)
- - Adfinis Sygroup hosts an [instance of OpenGrok](http://opengrok.adfinis-sygroup.org/source/) for us which is useful
-for understanding the code.
+ - Adfinis Sygroup hosts an [instance of OpenGrok](http://opengrok.adfinis-sygroup.org/source/) for us which is useful for understanding the code.
- We have an [instance of Atlassian Fisheye](https://fisheye6.atlassian.com/browse/ooo) which can be useful for browsing the code base and understanding dependencies.
## Finding Easy Tasks
-As a new developer you will want to find some easy coding tasks. These are tasks that generally can be done with good C++ skills, but do not require comprehensive knowledge of how
-OpenOffice is put together. The tasks are more localized. By doing easy tasks you gain experience and confidence hacking with the code base.
+As a new developer you will want to find some easy coding tasks. These are tasks that generally can be done with good C++ skills, but do not require comprehensive knowledge of how OpenOffice is put together. The tasks are more localized. By doing easy tasks you gain experience and confidence hacking with the code base.
-We use a [Bugzilla issue tracker](https://issues.apache.org/ooo/) to track reported defects in OpenOffice. Some of us also use Bugzilla for tracking feature and enhancement tasks as well. The value of tracking
-all coding-related tasks in Bugzilla is that it helps our QA volunteers know which areas to test. Whether code was changed to fix a bug or enhance a feature -- the QA impact is pretty
-much the same.
+We use a [Bugzilla issue tracker](https://issues.apache.org/ooo/) to track reported defects in OpenOffice. Some of us also use Bugzilla for tracking feature and enhancement tasks as well. The value of tracking all coding-related tasks in Bugzilla is that it helps our QA volunteers know which areas to test. Whether code was changed to fix a bug or enhance a feature -- the QA impact is pretty much the same.
-If you have not done so already, please [sign up for a Bugzilla account](https://issues.apache.org/ooo/createaccount.cgi). This will allow you to enter new bugs or tasks, but also
-assign yourself existing ones.
+If you have not done so already, please [sign up for a Bugzilla account](https://issues.apache.org/ooo/createaccount.cgi). This will allow you to enter new bugs or tasks, but also assign yourself existing ones.
-Many tasks are classified in the "difficulty" field. The ones classified as "easy" or "simple" (one level harder than "easy") are good ones to start with. You can find these with the
-[easy-hacks](https://issues.apache.org/ooo/buglist.cgi?f1=cf_fix_difficulty&o1=equals&resolution=---&query_format=advanced&v1=easy&list_id=42478) and [simple-hacks](https://issues.apache.org/ooo/buglist.cgi?f1=cf_fix_difficulty&o1=equals&resolution=---&query_format=advanced&v1=simple&list_id=42478) queries.
+Many tasks are classified in the "difficulty" field. The ones classified as "easy" or "simple" (one level harder than "easy") are good ones to start with. You can find these with the [easy-hacks](https://issues.apache.org/ooo/buglist.cgi?f1=cf_fix_difficulty&o1=equals&resolution=---&query_format=advanced&v1=easy&list_id=42478) and [simple-hacks](https://issues.apache.org/ooo/buglist.cgi?f1=cf_fix_difficulty&o1=equals&resolution=---&query_format=advanced&v1=simple&list_id=42478) queries.
-Once you pick a bug and assign it to yourself, you might want to post a note to the dev list, letting us know. We might have some helpful hints to get you started.
+Once you pick a bug and assign it to yourself, you might want to post a note to the dev list, letting us know. We might have some helpful hints to get you started.
## Coding Standards
@@ -97,28 +77,20 @@ For reference note the following coding
- [Coding Standards](http://wiki.openoffice.org/wiki/Coding_Standards)
- [Writer/Code Conventions](http://wiki.openoffice.org/wiki/Writer/Code_Conventions)
-The Geneva Convention prevents us from forcing you to read all of those rules, but know that they are there, and
-when your code is reviewed your reviewer might refer to some of those rules if there is an issue. So you'll
-absorb them over time.
+The Geneva Convention prevents us from forcing you to read all of those rules, but know that they are there, and when your code is reviewed your reviewer might refer to some of those rules if there is an issue. So you'll absorb them over time.
## Submitting Patches
-As you read in the [Introduction to Contributing to OpenOffice module](http://openoffice.apache.org/orientation/intro-contributing.html), contributors who have demonstrated merit via
-their project contributions can be voted in as Committers. Committers have the ability to check code into project's source control. Contributors who are not (yet) Committers
-must submit their patches and have them be reviewed first.
+As you read in the [Introduction to Contributing to OpenOffice module](http://openoffice.apache.org/orientation/intro-contributing.html), contributors who have demonstrated merit via their project contributions can be voted in as Committers. Committers have the ability to check code into project's source control. Contributors who are not (yet) Committers must submit their patches and have them be reviewed first.
-Please review these [guidelines for submitting patches](http://openoffice.apache.org/svn-basics.html#creating_and_submitting_patches). A good practice is to attach the patch to the
-Bugzilla issue and then send a link to the issue to the Dev list, asking for someone to review and commit the patch.
+Please review these [guidelines for submitting patches](http://openoffice.apache.org/svn-basics.html#creating_and_submitting_patches). A good practice is to attach the patch to the Bugzilla issue and then send a link to the issue to the Dev list, asking for someone to review and commit the patch.
##Other Useful Resources
-
- * The [OpenOffice.org for Developers](http://www.openoffice.org/development/) web area has
-useful information for getting started.
- * The [OpenOffice.org Development Wiki Area](https://wiki.openoffice.org/wiki/Development) has
-a lot of good general development information.
- * The [commits mailing list](http://openoffice.apache.org/mailing-lists.html#commits-mailing-list) echos every checkin made to the code base. Developers are encouraged to subscribe so they are aware of other changes, and can help review.
+
+ * The [OpenOffice.org for Developers](http://www.openoffice.org/development/) web area has useful information for getting started.
+ * The [OpenOffice.org Development Wiki Area](https://wiki.openoffice.org/wiki/Development) has a lot of good general development information.
+ * The [commits mailing list](http://openoffice.apache.org/mailing-lists.html#commits-mailing-list) echos every checkin made to the code base. Developers are encouraged to subscribe so they are aware of other changes, and can help review.
## Module Completion
-Once you have completed this module, go to our our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) wiki page and add or update
-your information. Congratulations! Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed Introduction to Development) so we know.
+Once you have completed this module, go to our our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) wiki page and add or update your information. Congratulations! Please send a note to [recruitment@openoffice.apache.org](mailto:recruitment@openoffice.apache.org?subject=Completed Introduction to Development) so we know.
Modified: openoffice/site/trunk/content/orientation/intro-doc.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/intro-doc.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/intro-doc.mdtext (original)
+++ openoffice/site/trunk/content/orientation/intro-doc.mdtext Fri Oct 21 15:39:57 2016
@@ -20,27 +20,19 @@ Notice: Licensed to the Apache Softwa
In this orientation module you will learn how to get started in the OpenOffice Documentation Team.
-To complete this module, read through the material on this page, including the linked references. There will also
-be some start-up tasks for you to perform, such as signing up for an account in our wiki.
+To complete this module, read through the material on this page, including the linked references. There will also be some start-up tasks for you to perform, such as signing up for an account in our wiki.
-Your first task is to subscribe to our Documentation mailing list. You can subscribe by sending an email to
-[doc-subscribe@openoffice.apache.org](mailto:doc-subscribe@openoffice.apache.org).
+Your first task is to subscribe to our Documentation mailing list. You can subscribe by sending an email to [doc-subscribe@openoffice.apache.org](mailto:doc-subscribe@openoffice.apache.org).
-Then you can introduce yourself by [sending an email to the list](mailto:doc@openoffice.apache.org?subject=New Doc Volunteer).
-We'd love to hear who you are, where you are from, what your background is, etc. 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 same list.
+Then you can introduce yourself by [sending an email to the list](mailto:doc@openoffice.apache.org?subject=New Doc Volunteer). We'd love to hear who you are, where you are from, what your background is, etc. 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 same list.
-Note: In parallel with the Doc-specific items on this page, you may want to also review the [Level 1 and Level 2 Orientation Modules](http://openoffice.apache.org/orientation/index.html). They have useful background information on The Apache Way, mailing list etiquette, decision making in the
-project, etc. A quick review is a good idea, especially if you are new to working in Apache-style open source projects.
+Note: In parallel with the Doc-specific items on this page, you may want to also review the [Level 1 and Level 2 Orientation Modules](http://openoffice.apache.org/orientation/index.html). They have useful background information on The Apache Way, mailing list etiquette, decision making in the project, etc. A quick review is a good idea, especially if you are new to working in Apache-style open source projects.
Now with the introductions out of the way, let's get started!
##The Big Picture
-As a popular end-user facing product, Apache OpenOffice is used by millions of people around the world, with a wide range of skills and backgrounds. Some have been using OpenOffice for
-a decade. Others are just moving over from Microsoft Office. Some are very familiar with computers and their operating systems. Others may be using a computer for the first time. Some
-are doing just basic editing. Others are "power users" and are creating complex applications built on top of OpenOffice.
+As a popular end-user facing product, Apache OpenOffice is used by millions of people around the world, with a wide range of skills and backgrounds. Some have been using OpenOffice for a decade. Others are just moving over from Microsoft Office. Some are very familiar with computers and their operating systems. Others may be using a computer for the first time. Some are doing just basic editing. Others are "power users" and are creating complex applications built on top of OpenOffice.
When users have a question, when they get stuck, there are a wide range of options for them:
@@ -50,40 +42,30 @@ When users have a question, when they ge
- They might post a question to our [community support forum](http://forum.openoffice.org)
- They might go to the [OpenOffice.org website](http://www.openoffice.org) and look for a solution there
-The documentation we write aids both the end-users as well as those who support the end users. We aim to provide authoritative, up-to-date material for Apache OpenOffice, and to aid
-users of all skill levels. If we do our tasks well, users are more satisfied and more productive.
+The documentation we write aids both the end-users as well as those who support the end users. We aim to provide authoritative, up-to-date material for Apache OpenOffice, and to aid users of all skill levels. If we do our tasks well, users are more satisfied and more productive.
##Varieties of Documentation
We maintain documentation in a variety of forms:
- - Built-in help files that are included in the product installs. These are context-sensitive help files that you get when you press "F1" in an OpenOffice application.
- - User Guides that are available on the website. These include a mixture of overview and task-specific topics.
+ - Built-in help files that are included in the product installs. These are context-sensitive help files that you get when you press "F1" in an OpenOffice application.
+ - User Guides that are available on the website. These include a mixture of overview and task-specific topics.
- Special topics, such as migration guides, scripting cookbooks, etc.
-
+
All OpenOffice documentation is housed on the [OpenOffice wiki](https://wiki.openoffice.org/wiki/Documentation) for ease of maintenance by volunteers with the exception of the help files which are integrated with the OpenOffice product itself.
##Goals and Constraints
In our documentation work we need to be aware of the following goals and constraints:
- - Only around 1/3 of OpenOffice users speak English as their native language. This is true also of the volunteers working on documentation. So in our list conversations, and in our
- documentation, we should aim for good, simple English prose, avoiding regional idioms and jargon. By convention we're adopting U.S. English spelling for the documentation.
- So we should plan for the documentation we write to be translated at some point.
- - We should also write the documentation so it can be translated into other languages. This means we need to be careful about how we mix text and graphics together in any diagrams.
- - We use the [Apache License 2.0](http://www.apache.org/licenses/LICENSE-2.0.html) for all project deliverables. This "permissive" open source license ensures that everyone has the
- ability to adapt and reuse the documentation that we create. But it also means that we need to be careful about what other 3rd party material we use in our documentation. Until you
- are familiar with the Apache rules for using 3rd party material into an Apache product, you should start a discussion on the mailing list for any 3rd party material you want to reuse.
- This includes material from the legacy OpenOffice.org project as well, since some of that was under a different license.
- - We're aiming to provide as much content as possible in the form of MWiki pages. These are easy for users to access, from any device. Also, since they are indexed by search engines
- they will be easy to find for the users who like to resolve issues by searching Google for solutions.
-
+ - Only around 1/3 of OpenOffice users speak English as their native language. This is true also of the volunteers working on documentation. So in our list conversations, and in our documentation, we should aim for good, simple English prose, avoiding regional idioms and jargon. By convention we're adopting U.S. English spelling for the documentation. So we should plan for the documentation we write to be translated at some point.
+ - We should also write the documentation so it can be translated into other languages. This means we need to be careful about how we mix text and graphics together in any diagrams.
+ - We use the [Apache License 2.0](http://www.apache.org/licenses/LICENSE-2.0.html) for all project deliverables. This "permissive" open source license ensures that everyone has the ability to adapt and reuse the documentation that we create. But it also means that we need to be careful about what other 3rd party material we use in our documentation. Until you are familiar with the Apache rules for using 3rd party material into an Apache product, you should start a discussion on the mailing list for any 3rd party material you want to reuse. This includes material from the legacy OpenOffice.org project as well, since some of that was under a different license.
+ - We're aiming to provide as much content as possible in the form of MWiki pages. These are easy for users to access, from any device. Also, since they are indexed by search engines they will be easy to find for the users who like to resolve issues by searching Google for solutions.
##Volunteers are Welcome
-We're looking for volunteers with technical writing experience, a good working knowledge of OpenOffice, or ideally both. The ability to collaborate with others in written English
-on the mailing list is required, but you just need to be understandable. For the actual writing, we have editor volunteers who will review and edit the rough drafts to fix any
-language errors. So you don't need to have native-level English skills.
+We're looking for volunteers with technical writing experience, a good working knowledge of OpenOffice, or ideally both. The ability to collaborate with others in written English on the mailing list is required, but you just need to be understandable. For the actual writing, we have editor volunteers who will review and edit the rough drafts to fix any language errors. So you don't need to have native-level English skills.
For some specialized areas skills in graphic design and programming are also useful.
@@ -97,21 +79,17 @@ Volunteers on the Documentation Team wor
##Getting Started
-The Documentation Team is the easiest one to get started with. There are just a few basic steps:
+The Documentation Team is the easiest one to get started with. There are just a few basic steps:
-1. Subscribe to our Documentation mailing list by sending an email to [doc-subscribe@openoffice.apache.org](mailto:doc-subscribe@openoffice.apache.org).
+1. Subscribe to our Documentation mailing list by sending an email to [doc-subscribe@openoffice.apache.org](mailto:doc-subscribe@openoffice.apache.org).
1. Sign up for an account on our MWiki by sending an e-mail with your preferred user name and e-mail address to the [Documentation mailing list](mailto:doc@openoffice.apache.org?subject=Requesting MWiki Account)
1. Sign up for an account on [our CWiki](https://cwiki.apache.org/confluence/display/OOOUSERS/Wiki+Home) (Why do we have two wikis? It is a long story...)**Note:** **After creation the account must be whitelisted by sending a request with the account name to the [Documentation mailing list](mailto:doc@openoffice.apache.org?subject=Whitelist CWiki Account)**
1. Add your name to our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) and
[Documentation Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Documentation+Volunteers) pages.
-1. Send an email to the [Documentation mailing list](mailto:doc@openoffice.apache.org?subject=New Doc Volunteer) and introduce yourself.
+1. Send an email to the [Documentation mailing list](mailto:doc@openoffice.apache.org?subject=New Doc Volunteer) and introduce yourself.
We can then bring you up to speed on what we're currently working on.
-
-## Module Completion
-
-Once you have completed this module, go to our our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) wiki page and add or update
-your information. Congratulations! Please send a note to [doc@openoffice.apache.org](mailto:doc@openoffice.apache.org?subject=Completed Introduction to Documentation) so we know.
+## Module Completion
-
\ No newline at end of file
+Once you have completed this module, go to our our [Directory of Volunteers](https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers) wiki page and add or update your information. Congratulations! Please send a note to [doc@openoffice.apache.org](mailto:doc@openoffice.apache.org?subject=Completed Introduction to Documentation) so we know.
Modified: openoffice/site/trunk/content/orientation/intro-l10n.mdtext
URL: http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/intro-l10n.mdtext?rev=1766050&r1=1766049&r2=1766050&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/intro-l10n.mdtext (original)
+++ openoffice/site/trunk/content/orientation/intro-l10n.mdtext Fri Oct 21 15:39:57 2016
@@ -18,8 +18,4 @@ Notice: Licensed to the Apache Softwa
1. Please send an email to [L10N@openoffice.apache.org](mailto:L10N@openoffice.apache.org?subject=Starting Introduction to Localization) to let us know you are working on this module.
-
-1. Congratulations! You have completed this Level. Please send a note to [L10N@openoffice.apache.org](mailto:L10N@openoffice.apache.org?subject=Completed Introduction to Localization) so
-we all know you have completed this level. This is also a good opportunity to send along any feedback or questions you might have on this Orientation Module.
-
-
+1. Congratulations! You have completed this Level. Please send a note to [L10N@openoffice.apache.org](mailto:L10N@openoffice.apache.org?subject=Completed Introduction to Localization) so we all know you have completed this level. This is also a good opportunity to send along any feedback or questions you might have on this Orientation Module.