Guidelines for Participating in OpenOffice.org

General

OpenOffice.org is an open-source project through which Sun Microsystems has released the technology for the popular StarOffice™ productivity suite. Sun sponsors and participates in OpenOffice.org. The overall name of the Project is OpenOffice.org, the name of the product being, also, OpenOffice.org™.

The Project's primary features include:

• Downloadable sources and information; and
• Community and communication mechanisms, such as mailing lists, forums, bugtracker, wikis.

OpenOffice.org has established the necessary facilities to make this open-source technology available to all interested participants. Principal Project objectives are:

• Establishment of open, XML-based standards for office productivity file formats and language-independent bindings to component APIs
• Open access to the source code via concurrent versioning to enable innovation for building the next generation of open-network productivity services.

Governance

OpenOffice.org is governed by the Community Council, which is constituted by members from the OpenOffice.org community, which created the charter establishing the Council. The Council holds periodic meetings by IRC, as well as conducting business via the 'discuss@council.openoffice.org' mailing list. Both IRC records and mail-list archives are public. Agenda items may be proposed by any member. For more information, go to the Council website.

The following sections describe guidelines regarding technical roles and responsibilities at OpenOffice.org and the handling of source code. Substantial enhancements or modifications of these guidelines need approval of the Community Council.

For guidelines on the protocols for proposing projects to OpenOffice.org, please see Protocols for Project Proposal.

Roles and Responsibilities

Everybody can help no matter his or her role. The more a person becomes involved in the project, the more he or she develops a trusting relationship with others.

OpenOffice.org respects the rights of its community to post messages and use the mailing lists to further the aims of the Project. In fact, we encourage people to use the mailing lists. To this end, we will do our best to limit "spam" and to ensure that communication among community members is carried out politely and efficiently. We have posted some " Mail-List Guidelines" that detail our commitment.

Commercial Activity

To ensure that works created using the OpenOffice.org Project resources benefit the entire community, the following guidelines are to assist all stakeholders (individuals and companies) who invest in OpenOffice.org:

• Outside of designated areas, such as the Support page, where works may be placed by 3rd-parties for sale, revenue from works for sale listed on the Project website must be remitted entirely to OpenOffice.org, via either Team OpenOffice.org e.V. or a similar organization. If revenue from works created using OpenOffice.org Project resources is remitted to the individual author or authors or an association of them then that work must be listed on the Support page (or designated equivalent), along with other third-party works. The idea is to clearly distinguish works whose sale benefits OpenOffice.org from those that do not. Misplaced listings will be removed at the discretion of the Project Lead.
• Sponsor ads are accepted (as agreed by the Community Council or its delegates), and are to be located in designated areas, such as the sponsors' page for conferences, the Support page, and other similar locations, with exceptions determined by the Community Council.

Members

"Members" refers to those persons who have joined the Project by registering with OpenOffice.org and have a username. A member may not have subscribed to a mailing list, and a subscriber to a mailing list who is using the Project may not have registered; only those who have registered are members. It is strongly encouraged that all members join the general and relevant specific project lists as well as joining a particular project. Initially, one can only join as an Observer, a role that allows one to contribute to the project and otherwise participate in it.

Contributors

"Contributors" refers to those who are members of an OpenOffice.org project, Accepted, Incubator or Native Language, who write code, documentation, extensions, create artwork, work on localizations or other relevant translations, contribute webwork or otherwise contribute positively to the Project.

Developers

Project members who give frequent and valuable contributions to a project can have their status promoted to that of a "Developer" for that project. A Developer has write access to the source code repository. A "Content Developer" has write access to a project's documentation but not to the source code.

In order for a Contributor to become a Developer, another Developer nominates that Contributor. The Project Lead may convert the Contributor into a Developer and give write access to the source code repository for his project.

At times, Developers may go inactive for a variety of reasons. A Developer that has been inactive for six months or more may lose his or her status as a Developer. In this case or if the value of a Developer's contributions diminishes, write access may be revoked by the responsible Project Lead.

A committed change must be reversed if this is requested by the responsible Project Lead or by the Community Council or its delegates and the conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The situation must be rescinded before the change can be included in any public release.

Project Leads

There are three main categories of public projects in OpenOffice.org:

• Accepted Projects ("Projects")
• Incubatored Projects
• Native-Language Confederation (NLC or Native-Lang)

All Accepted Projects must have two leads, a lead and co-lead. It is up to each project to determine the actual content of the roles each lead will take on. Native-Lang and Incubator projects may have one lead; size and complexity is the determining factor: A large project requires two leads.

A Project Lead is responsible for giving guidance and directions for his or her project and its part in the OpenOffice.org effort. The lead is also responsible for:

• Content
• Membership management
• Mailing list management
• Work coordination

A Project Lead may delegate some of these duties. A Project Lead should make sure that questions about his or her project are answered and that a friendly and supportive environment is created. Contributions, mail-list discussions and forum interchanges, as well as issues, and other administrative duties should be handled in an encouraging and productive fashion.

Transitioning from one Project Lead to another is almost always a graceful and smooth affair. The Project Lead or leads are encouraged to nominate their successors, who must be members of the project, and hold a plebiscite on the primary public mailing list. One can nominate oneself. Voters should be limited to those who are actually members of the project. Membership in a project means having "Observer" or higher status in the project, not subscription to the mailing lists.

Occasionally, disputes over leadership arise in a project. In these cases, the project members and lead should first seek to amicably resolve the dispute among themselves, via the primary mailing list. If discussions among project members (including the lead) do not resolve the situation, the Community Council may be asked to intervene. Any project member, including a Project Lead, is entitled to request that the Community Council adjudicate the dispute. The project member should send a post explaining the desire to agenda@council.openoffice.org. The Council will act as soon as is feasible.

Project Leads may also be removed by a vote of project members (see below) or, in extraordinary circumstances, by the direct intervention of the Community Council. An extraordinary circumstance would include the dereliction of a lead's duties and responsibilities, as named above, as well as a prolonged absence, defined as lasting more than 3 months without prior notice and without introducing a stand-in. In cases where the Community Council intervenes to remove a Project Lead, it will also arrange for the election of a new Lead, should that be necessary.

OpenOffice.org has the use of a secure and private voting mechanism that can be quickly set up for project votes. Interested members should contact the Community Manager, Louis Suárez-Potts, for more information. Members are also entitled to ask the Community Council to intervene and conduct the vote for a new Project Lead. If a Project Lead feels he or she has been removed unjustly, he or she is naturally entitled to bring a grievance before the Community Council.

A Project Lead who has been voted out of office must be notified by the members of the project, which will then be required to elect a new lead.

A list of our current Project Leads can be found in the list of projects.

Sources

The codebase is maintained in shared information repositories using CVS. Only Developers and Project Leads have write access to these repositories. Everyone has read access via anonymous CVS or the Web frontend.

All source code committed to the Project's repositories must be covered by LGPL. Files in the repository must contain a header according to the OpenOffice.org templates (available for code and makefiles). Contributors of source code larger than small changes must have signed the Oracle Contributor Agreement (OCA) before their contribution can be committed to the repository.

Straightforward patches and feature implementations can be committed without prior notice or discussion. Doubtful changes and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics of an existing API function, configuration data or file formats or other major areas must receive approval. A Project Lead may informally approve changes within his project.

There are three different types of changes:

info	Informational notice about an API change, no developer action necessary.
recommended	Use the new API as soon as possible. The old API is obsolete and might go away in the near future. New code should always use the new API.
required	Not complying to the new API will break the build or cause runtime failure. Developer action is mandatory.

Proposals for inter-project changes of type "recommended" or "required" must be published with the suggested change date to the interface discussion mailing list. After one week of review, a change announcement must be published to the interface announce mailing list. During this announcement period, depending projects have to prepare their projects for the changes so that the following build will not break. They are responsible for reflecting the change in their project, not the requester. Within the two weeks of discussion/announcement Project Leads may raise a flag and Project Leads majority has to decide about cancellation of the change request.