How to contribute to OpenOffice.org

(Draft 0.1 2003/10/31 please provide feedback to mh at openoffice.org)

This document describes different possibilities about how to contribute to (or participate in) the OpenOffice.org project. I assume that you are already a user of OpenOffice.org and want to take the first steps of being more than just a user.

Roles in OpenOffice.org Project

OpenOffice.org User

You may have question about the usage of OpenOffice.org? You even may have answers for other users questions? Subscribe to users@openoffice.apache.org and help by answering questions. You can also contribute templates and documentation to the documentation project for other users to make use of.

OpenOffice.org Macro Programmer, Plug-in or Addon Developer

In this role you are probably most interested in developing you own code using the interfaces provided by OpenOffice. These interfaces are called UNO APIs and you can get documentation from the http://api.openoffice.org project and help from the dev@api.openoffice.org list.

OpenOffice.org Power User

If you already know about internals of OOo you may subscribe to the different dev@*.openoffice.org lists. Here you are able to discuss with the developers about problems and enhancements. You also can use IssueZilla, the OpenOffice.org Bug Tracking System to file your problems or feature requests into the Database. (see also ircs://irc.libera.chat/openoffice for on line discussions)

OpenOffice.org Quality Assurance

If you are interested on being on the bleeding edge it might be useful to join the QA Team (qa@openoffice.apache.org). There are several interesting projects like automatic GUI testing (http://qa.openoffice.org/qatesttool) and OOo API testing (http://qa.openoffice.org/qadevOOo) as well as the daily QA work (see also ircs://irc.libera.chat/openoffice )

OpenOffice.org Content Developer

In the OpenOffice.org Project there are not only things to do directly related to the Product but there is also a lot of other work left in the OpenOffice.org project. If you want to enhance any of the OOo web pages, you need status of a content developer. Ask your project lead for this role. You are encouraged to sign an JCA, but as long we have the common understanding that the contribution to any web content is treated as Public Domain, this is not mandatory.

Native Lang Projects

There are several Native-Lang projects on OpenOffice.org which you can join. These projects offer users information about OpenOffice.org in their native languages. This makes OpenOffice.org more open to non English speaking people.

Established Projects

Also the already established long existing projects are looking for helpers to extend project documentation.

Marketing Project

Incubator Projects

Bibliographic, WordPerfect filter, Groupware, etc. All of these are in need of developers to contribute and because they use only the OpenOffice UNO APIs, it should be easier for a developer wanting to get their hands on code to develop and contribute.

OpenOffice.org Developer

You may even have patches attached to issues, new implementations for the OpenOffice.org code base. Participate on the projects dev lists and you may achieve developer status quickly. This includes the content developer status.

OpenOffice.org Porting

You want to port OpenOffice.org to a new platform ? Look on dev@porting.openoffice.org for other interested people.

OpenOffice.org Localizations

See L10N@openoffice.apache.org and http://l10n.openoffice.org/adding_language.html for more info regarding all questions around this topic.

Miscellaneous

• Team OpenOffice.org ( www.teamopenoffice.de *German*)

• Ximian ( ooo.ximian.com)

• NeoOffice (www.neooffice.org)

• ooodocs www.ooodocs.org

Setting Expectations

An Office Suite does have many users who have a lot ideas on how to extend the product or have problems with this product. There are only a few developers which are able to understand these requests and are able to implement a solution for it. So for every enhancement or bug fix we have to find somebody who is able and willing to do so. At the time of writing there are about 3000 issues which being are worked on for the next version of OpenOffice.org. This work is done by about 120 developers from which the major part is employed by Sun Microsystems. We expect that during the life cycle of the next version about 15000 issues get raised and fixed. And there will be many more issues which can not be addressed in time for the next version. Due to the complexity and size of the OpenOffice.org product it is not possible to wait until all known issues are fixed. We have to find the balance between “the product that contains long awaited features” and all “severe bugs” are gone.

For this reason we introduced the term “Target Milestone” to be able to set an expectation about what version issues are scheduled to get fixed. It is common understanding that “severe issue” has to be fixed by the next version. Minor issue will get fixed, if resources for fixing them are allocable or fixes are already available (see http://tools.openoffice.org/release/TargetMilestone.html).

It's quite important to understand these resource constraints, just asking or voting on an issue will not necessarily ensure that an the issue will get fixed. If there is any different interpretation about targeting of issues every party has to argue why this is an issue should been worked on as soon as possible, over other equally important issues. If it is not possible to get agreement on this issue it should be raised to the relevant team lead(s) or the releases@openoffice.org team. As a last resort, if agreement cannot be achieved it should then be raised with the Community Council to resolve the issue.

Development Process

There are some simple rules to follow for the development process:

Master WorkSpaces (mws)

Builds are done on code lines, which are actually branches in cvs repository. These branches are called master branches and for each code line there is a separate branch. Currently we have this situation:

1.1 code line = mws_srx645, 2.0 code line = HEAD

Once the 2.0 code line has been closed before delivery, the 2.0 code line will also move to a branch (e.g. mws_src680, and development of following release (3.0 ??) will then happen on CVS HEAD.

Contributions to these code lines have to have their corresponding issues in IssueZilla and will not generally be made directly to those branches, but on sub branches called child workspaces (cws).

Child Workspaces (cws)

Having child workspaces means it is possible to review and test all changes before they get applied on the master branch. This have several advantages but also constraints:

• Less regressions on the master branch

  • We should be able to do a release at production quality from the master branch.

  • The HEAD of the branch is always consistent and buildable.

• Before reintegration into the master, the cws has to QA'd. Without QA approval there is no reintegration.

• Liberal access rights and 'lazy commits' on cws branches.

  • Since a commit to cws will not influence the master before reintegration, we are able to grant commit access more liberally since review is easier and QA is mandatory.

  • We can grant commit access to any third parties in a very free way, reducing the hurdle for getting patches in. Patches are reviewed and QAed on the cws before reintegration. This mean cws can be treated as play ground for developers and vendors.

  • If a cws gets applied to a master branch, Release Engineering ensure that it is applied also on the following product master branch.

A cws does not necessarily have every module tagged with the cws branch tag. In most cases only needed modules are tagged with cws branch tag, remaining modules have to be taken from the master branch (as long as no changes are needed). There are also cws, where all modules have been tagged to be on the cws branch, this makes life for casual contributor easier, they don't have to take care that the module is already available for the specific cws.

Any implementation of a feature will happen on a separate cws, this ensures that no incomplete or only partly tested feature will get into the master. Please avoid implementing more than one big or a few minor features on one cws. Also don't group too many bug fixes in one cws to avoid dependencies. A cws should be shortlived if possible to avoid divergence from the master.

How to get your code contribution to OpenOffice.org

Issue handling

If you are going to make your first contribution to the code basis you have to be familiar with bug handling in IssueZilla. File an Issue with a good description of what you want to achieve. Make sure that you got the correct target milestone and the correct owner assigned. The owner should be always the one, from whom the next action is expected.

Confirmed/Unconfirmed status

As default issue will be submitted as unconfirmed. The first step is to get the issue confirmed by a QA or Project member. QA members will scan unconfirmed issues, if this takes too long, you should ask for confirmation on the projects dev list. Once the team recognises the valuable issue submissions you will be granted “can confirm” status or simply ask the project lead for this. Developers often ignores issues with unconfirmed status or will treat them with lower priority.

Target Milestone

By default issues will have no target milestone. Target milestones will be set by qa team or developers. If there are different opinions about target milestone these should solved by the project lead or releases@openoffice.org.

Component/Owner

Dependent on the selected component (and subcomponent) the issue will be assigned to an default owner. Don't be afraid to select the wrong component, the issues will get reassigned after a while to the correct owner. If you are unsure about which component to use, you should only choose among: Chart, Database Access, Drawing, Formula Editor, Installation, Presentation, Spreadsheet and Word processor.

Nothing happens ?

If nothing happens to your issue after a while, don't hesitate to ask the current owner directly on the dev list about the status. If you don't get reaction, ask once more. Also if you get some insufficient feedback like “worksforme”, “cantreproduce” don't hesitate to ask once more if you think this might not be correct. Please provide a reason why you think it is important.

Patches

Code contribution can be attached to an issue. If this contribution is of significant size (i.e. >= 10 line of code) you need to sign a JCA before submitting (http://www.openoffice.org/contributing.html). Your name will be listed on the web page it will last 1 – 2 weeks :( .

committing patches to cvs

Once you have been recognised as valuable patch contributor, you will get granted commit access to cvs. Then you will be able after set up a cvs ssh tunnel to commit patches directly to a cws. But every commit to cvs has to be accompanied with an issue number, so that every patch which is going into OpenOffice.org is documented by an issue. Ask your project lead or releases@openoffice.org to get cvs commit access.

Creating a cws

Unfortunately we are not able to create a cws by our own, yet. We have to ask Sun employees to create them for us Ask the project lead or releases@openoffice.org for creation of a cws. Important data for creating these is the expected life time, the targeted code line and who will be responsible person which will give the ok for passed QA. A descriptions of the purpose of the cws is also helpful. Creating a full blown cws (where all modules get tagged within a cws branch tag ) will last up to two days.

Working on a cws

Do whatever you want there. It's your cws. You may want to use Bonsai (http://ooo.ximian.com/bonsai) to track any changes on the cws.

It is also possible to set up a tinderbox which multiple build and verify the cws is buildable on many platforms.

Resyncing a cws

With the longer lifetime of a cws, conflict risks for reintegration of the cws will also grow. For this reason a resync of the cws to a newer version of the master workspace (mws) is possible. At this time this also can be done by Sunnies. Ask for help to do the resync for you.

QA of a cws

The minimum QA of a cws is that all issues which have been fixed on this cws, have been verified by your peers. If features got implemented, a test plan also should be available. Mandatory is the successful pass of the smoketest_oo module and the verification on at least two platforms (Windows and one Unix derivate is a good choice). A clean and build of is always a good idea, see tinderbox for permanent builds. on specific branches.

Reintegration into master workspace

Reintegration of a cws into the master workspace will done by Hamburg Release Engineering. They will be delighted by every cvs conflict and build error :). Please try to avoid them and you will get new friends for life.