| <!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>™ 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™.</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 "spam" and to ensure that communication among community members is |
| carried out politely and efficiently. We have posted some " <a href="../ml_guidelines.html">Mail-List Guidelines</a>" 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>"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.</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 "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.</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 "bug fix" 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 ("Projects")</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 "Observer" 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á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 "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.</p> |
| |
| </body> |
| </html> |