Richtlinien für die Teilnahme an OpenOffice.org

Letztes Update: 04. September 2005

Allgemeines

OpenOffice.org ist das OpenSource-Projekt, über das Sun Microsystems die Technologie des beliebten StarOffice^TM Office-Pakets veröffentlicht. OpenOffice.org ist ein neues Projekt, das von Sun gesponsort und bei der Weiterentwicklung unterstützt wird. OpenOffice.org ist der Name des ganzen Projekts und befindet sich auf den Servern von CollabNet.

Die wichtigsten Merkmale von OpenOffice.org sind:

 Quellcode und Informationen zum Herunterladen

 Mechanismen für die Gemeinschaft und zur Kommunikation wie etwa Mailinglisten

Das OpenOffice.org-Projekt stellt die notwendigen Mittel zur Verfügung, um die OpenSource-Technologie der Entwicklergemeinde zugänglich zu machen. Diese Projekt-Seite enthält derzeit Ressourcen zu Ihrer Information sowie Diskussionsforen. Grundsätzliche Ziele des Projekts sind:

  Etablieren eines offenen, XML-basierten Standard als Dateiformat für das Office-Paket und sprachunabhängige Bindungen an die APIs der Komponenten.

  Öffentlicher Zugriff auf den Quelltext über die CVS-Versionsverwaltung, um die Entwicklung der nächsten Generation von offenen Netzwerk-fähigen Büropaketen zu ermöglichen

Die folgenden Kapitel enthalten Richtlinien, die die fachlichen Rollen und Verantwortlichkeiten bei OpenOffice.org sowie die Handhabung des Quelltexts beschreiben. Grundsätzliche Erweiterungen oder Änderungen dieser Richtlinien benötigen die Zustimmung der 2/3-Mehrheit der Projektleiter.

Richtlinien über die Protokolle um Projekte für OpenOffice.org vorzuschlagen, finden Sie auf der folgenden Seite: Protokolle für Projektvorschläge.

Rollen und Verantwortlichkeiten

Die Stellung und die Verantwortlichkeit, die eine Person im Projekt einnehmen kann, hängt von ihrer Leistung ab. Jeder kann unabhängig von seiner Stellung helfen. Diejenigen, die für lange Zeit wertvolle Mitarbeiter waren, bekommen das Recht, Quellcode direkt an den Server zu übermitteln.

Anwender

Anwender sind Personen, die die Produkte aus dem Projekt verwenden. Personen in dieser Position entwickeln keinen Quellcode, aber durch das Verwenden der Software können sie Fehler melden, sich Funktionen wünschen, usw. Das ist die mit Abstand wichtigste Gruppe von Personen, da keine Notwendigkeit für dieses Projekt bestünde, wenn es keine Anwender gäbe. Sie können ihr Interesse an einem bestimmten Projekt zeigen, indem sie den Status eines Beobachters annehmen. Sobald ein Anwender anfängt, Quellcode zu entwickeln oder Korrekturen an der Dokumentation vornimmt, wird er zum Beitragenden.

Mitwirkende

Mitwirkende, ein Ausdruck, der alle Rollen in einem Projekt ohne das Recht Daten über CVS zu übermitteln einschließt, sind Personen, die Quelltext schreiben, Korrekturen an der Dokumentation vornehmen oder anderweitig an dem Projekt mitarbeiten. Der Beitrag eines Mitarbeiters ist immer bekannt. Im Quelltext dürfen alle Beitragenden, die an der Datei gearbeitet haben, ihren Namen zu der Liste der Mitwirkenden hinzufügen.

Entwickler

Mitwirkende, die regelmäßig wertvolle Beiträge für ein Projekt abliefern, können in diesem Projekt zum Entwickler befördert werden. Ein Entwickler hat Schreibzugriff auf den Quelltext. Ein Entwickler von Inhalten hat Zugriff auf die Dokumentation eines Projekts, nicht aber auf den Quelltext.

Um vom Beitragenden zum Entwickler zu werden, muss man von einem anderen Entwickler als solcher ernannt werden. Der Projektleiter kann den Beitragenden zum Entwickler machen und ihm Schreibzugriff auf den Quelltext des Projekts gestatten.

Entwickler können aus verschiedenen Gründen inaktiv werden. Ein Entwickler, der für mindestens sechs Monate lang inaktiv war, kann seine Stellung verlieren. In diesem Fall oder in jenem Fall, dass der Wert der Beiträge eines Entwicklers abnimmt, kann der Schreibzugriff von dem zuständigen Projektleiter wieder entzogen werden.

Eine übermittelte Änderung muss rückgängig gemacht werden, falls das von dem zuständigen Projektleiter oder der Mehrheit aller Projektleiter gefordert wird und die Bedingungen nicht sofort durch das Übermitteln eines "Bug-Fixes" erfüllt werden können. Die Situation muss geklärt sein, bevor die Änderung in eine Version, die veröffentlicht wird, aufgenommen werden kann.

Projektleiter

Personen, die bereits für lange Zeit Entwickler sind und wirklich an der Entwicklung von Code beteiligt sind, großes Wissen in ihrem Arbeitsbereich und OpenOffice.org als Ganzes vorweisen können sowie Führungsqualitäten besitzen, können zum Projektleiter eines bestehenden Projekts ernannt werden. Ein Projektleiter ist verantwortlich für die Leitung des Projekts. Er muss die Richtung vorzeigen und ist Teil des OpenOffice.org-Rats.

Von Entwicklern ernannt, kann ein Kandidat von der 2/3-Mehrheit der Projektleiter für ein neues oder ein verwaistes, bestehendes Projekt angenommen werden.

Der Status des Projektleiters kann nicht nur durch Inaktivität bei der Veröffentlichung von Beiträgen (wie bei den Entwicklern beschrieben) verloren gehen, sondern auch bei der mangelhaften Erfüllung der Verantwortung für jenes Projekt, für das der Projektleiter zuständig ist. Die 2/3-Mehrheit der Projektleiter kann den Status als Projektleiter aufheben.

Eine Liste unserer gegenwärtigen Projektleiter kann in der Projektliste gefunden werden.

Quelltexte

Die Codebibliothek wird in gemeinsam genutzten Archiven mit Hilfe von CVS verwaltet. Nur Entwickler und Projektleiter haben Schreibzugriff auf diese Bibliothek. Jeder hat anonymen, lesenden Zugriff auf CVS über ein Web-Frontend.

Der komplette Quelltext, der in die Codebibliothek übertragen wird, unterliegt der LGPL (GNU Lesser General Public License). Dateien in der Bibliothek müssen einen Kopf enthalten, der gemäß den OpenOffice.org-Vorlagen aussieht (verfügbar für Quelltext und Makefiles). Mitwirkende, die am Quelltext große oder kleinere Änderungen vornehmen, müssen das "Joint Copyright Assignment - Formular" unterzeichnet haben, bevor ihre Beiträge in die Bibliothek aufgenommen werden können.

Patches und das Implementieren von neuen Funktionen können ohne vorherige Bekanntgabe oder Diskussion übermittelt werden. Zweifelhafte Änderungen oder groß angelegte Überarbeitungen müssen vor der Übertragung in die Bibliothek diskutiert werden. Jeder Änderung, die die Semantik einer existierenden API-Funktion, Konfigurationsdaten, Dateiformate oder andere große Gebiete betrifft, muss zugestimmt werden. Ein Projektleiter kann Änderungen an seinem Projekt zwanglos zustimmen.

Es gibt verschiedene Arten von Änderungen:

info	Bekanntgabe einer API-Änderung zur Information, keine Aktion eines Entwicklers notwendig.
recommended (empfohlen)	Die neue API soll so schnell wie möglich verwendet werden. Die alte API ist veraltet und kann in der nahen Zukunft entfernt werden. Neuer Code sollte immer die neue API verwenden.
required (erforderlich)	Falls die neue API nicht verwendet wird, kann es zu einem Fehler beim Kompilieren kommen oder es können Laufzeit-Fehler auftreten. Eine Aktion der Entwickler ist zwingend notwendig.

Vorschläge für projektübergreifende Änderungen der Typen "recommended (empfohlen)" oder "required (erforderlich)" müssen mit einem Vorschlag für das Änderungsdatum in der Schnittstellen-Diskussions-Mailingliste veröffentlicht werden. Nach einer Woche der Prüfung muss eine Änderungsankündigung in der Schnittstellen-Ankündigungs-Mailingliste veröffentlicht werden. Während diesem Ankündigunszeitraums müssen abhängige Projekte vorbereitet werden, damit beim Kompilieren des Pakets kein Fehler entsteht. Sie - und nicht derjenige, der die Änderungen gefordert hat - sind dafür verantwortlich, über die Änderungen in ihrem Projekt nachzudenken. Innerhalb dieser zwei Wochen der Diskussion und Ankündigung können Projektleiter Einspruch erheben und die Mehrheit der Projektleiter muss entscheiden, ob dem Einspruch stattgegeben wird.

Eine übermittelte Änderung muss rückgängig gemacht werden, falls das von dem zuständigen Projektleiter oder der Mehrheit aller Projektleiter gefordert wird und die Bedingungen nicht sofort durch das Übermitteln eines "Bug-Fixes" erfüllt werden können. Die Situation muss geklärt sein, bevor die Änderung in eine Version, die veröffentlicht wird, aufgenommen werden kann.