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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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 [email protected]
-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 [email protected] 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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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 [email protected] can be tedious. So you will
often see
-it called just "dev@". Similarly, top-level lists like [email protected]
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 [email protected] can be tedious. So you will often
see it called just "dev@". Similarly, top-level lists like
[email protected] 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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
-[[email protected]](mailto:[email protected]).
+Your first task is to subscribe to our Recruitment mailing list. You can
subscribe by sending an email to
[[email protected]](mailto:[email protected]).
-Then you can introduce yourself by [sending an email to the
list](mailto:[email protected]?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:[email protected]?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:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
-[[email protected]](mailto:[email protected]).
+Your first task is to subscribe to our Documentation mailing list. You can
subscribe by sending an email to
[[email protected]](mailto:[email protected]).
-Then you can introduce yourself by [sending an email to the
list](mailto:[email protected]?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:[email protected]?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
[[email protected]](mailto:[email protected]).
+1. Subscribe to our Documentation mailing list by sending an email to
[[email protected]](mailto:[email protected]).
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:[email protected]?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:[email protected]?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:[email protected]?subject=New Doc Volunteer) and
introduce yourself.
+1. Send an email to the [Documentation mailing
list](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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
[[email protected]](mailto:[email protected]?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.
