content/dev_docs/guidelines.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <title>OpenOffice.org - Guidelines</title>
</head>

<body>

<h2>Guidelines for Participating in OpenOffice.org</h2>
<br />

<h3>General</h3>

<p>OpenOffice.org is an open-source project through which <a href="http://www.sun.com">Sun Microsystems</a> has released the technology for the popular
<a href="http://www.sun.com/staroffice">StarOffice</a>&trade; 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&trade;.</p>

<p>The Project's primary features include:</p>

<ul>
  <li>Downloadable sources and information; and</li>
  <li>Community and communication mechanisms, such as mailing lists, forums, bugtracker, wikis.</li>
</ul>

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

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

<h3>Governance</h3>

<p>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
<a href="http://council.openoffice.org/">Council website</a>.</p>

<p>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.</p>

<p>For guidelines on the protocols for proposing projects to OpenOffice.org, please see
<a href="../about_us/protocols_proposing.html">Protocols for Project Proposal</a>.</p>

<h3>Roles and Responsibilities</h3>

<p> 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. </p>

<p>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 &quot;spam&quot; and to ensure that communication among community members is
carried out politely and efficiently. We have posted some &quot; <a href="../ml_guidelines.html">Mail-List Guidelines</a>&quot; that detail our
commitment.</p>

<h3>Commercial Activity </h3>

<p>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:</p>

<ul>
  <li>Outside of designated areas, such as the <a href="/support/">Support</a> 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
  <a href="/contributing/donate.html">Team OpenOffice.org e.V.</a> 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
  <a href="/support">Support</a> 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.</li>
  <li> 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 <a href="/support/">Support</a> page, and other similar locations, with exceptions determined by the Community
  Council.</li>
</ul>

<h3>Members</h3>

<p>"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.</p>

<h3>Contributors<a name="contributors"></a></h3>

<p>&quot;Contributors&quot; 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.</p> 

<h3>Developers</h3>

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

<p>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.</p>

<p>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.</p>

<p>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 &quot;bug fix&quot; commit. The situation must be rescinded before the change can be included in any
public release.</p>

<h3>Project Leads</h3>

<p>There are three main categories of public projects in OpenOffice.org:</p>

<ul>
  <li>Accepted Projects (&quot;Projects&quot;)</li>
  <li>Incubatored Projects</li>
  <li>Native-Language Confederation (NLC or Native-Lang)</li>
</ul>

<p>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.</p>

<p>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:</p>

<ul>
  <li>Content</li>
  <li>Membership management</li>
  <li>Mailing list management</li>
  <li>Work coordination</li>
</ul>

<p>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.</p>

<p>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 &quot;Observer&quot; or higher status in the project, not
subscription to the mailing lists.</p>

<p>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 <a href="mailto:agenda@council.openoffice.org">agenda@council.openoffice.org</a>. The Council
will act as soon as is feasible.</p>

<p> Project Leads may also be removed by a vote of project members (see <a href="#nextpgraph">below</a>) 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.</p>

<p><a name="nextpgraph"></a>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 <a href="mailto:louis@openoffice.org">Community Manager</a>, Louis Su&aacute;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. </p>

<p>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.</p>

<p>A list of our current Project Leads can be found in the <a href="/projects/">list of projects</a>.</p>

<h3>Sources<a name="Sources"></a></h3>

<p>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.</p>

<p>All source code committed to the Project's repositories must be covered by <a href="//license.html"><b>LGPL</b></a>. Files in the
repository must contain a header according to the OpenOffice.org templates (available for
<a href="//dev_docs/source/templates/code">code</a> and
<a href="//dev_docs/source/templates/makefile">makefiles</a>). Contributors of source code larger than small changes must have signed
the <a href="/contributing/programming.html#oca.pdf">Oracle Contributor Agreement (OCA)</a> before their contribution can be
committed to the repository.</p>

<p>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.</p>

<p>There are three different types of changes:</p>

<table width="100%" border="1" cellpadding="4" cellspacing="2">
  <col width="48*" />
  <col width="208*" />
  <tr valign="top">
    <td width="19%">
      <p>info</p>
    </td>
    <td width="81%">
      <p>Informational notice about an API change, no developer action necessary.</p>
    </td>
  </tr>
  <tr valign="top">
    <td width="19%">
      <p>recommended</p>
    </td>
    <td width="81%">
      <p>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.</p>
    </td>
  </tr>
  <tr valign="top">
    <td width="19%">
      <p>required</p>
    </td>
    <td width="81%">
      <p>Not complying to the new API will break the build or cause runtime failure. Developer action is mandatory.</p>
    </td>
  </tr>
</table>

<p style="margin-bottom: 0cm"></p>
<p> Proposals for inter-project changes of type &quot;recommended&quot; or &quot;required&quot; 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.</p>

</body>
</html>