Sammlung (vermutlich) häufig gestellter Fragen und Antworten zur Mitarbeit am de-Projekt von OpenOffice.org (Mitarbeiter-FAQ)
Eine Mailingliste ist eine der beliebtesten Methoden, eine E-Mail an mehrere Leute gleichzeitig zu schicken. Technisch verbirgt sich hinter der Emailadresse der Mailingliste ein Programm (Listenserver), das Deine E-Mail an alle weiterschickt, die sich in diesen E-Mailverteiler eingetragen haben. Gleichzeitig verwaltet der Listenserver die Mitglieder und legt ein Archiv aller jemals an ihn geschickten Emails an.
Sende eine Email an dev-subscribe@de.openoffice.org.
Hinweise zum Eintragen in die dev - Mailingliste des de-Projektes gibt es unter
http://de.openoffice.org/dev/about-ooo/about-mailinglist.html.
Praktisch funktioniert die Kommunikation mit einer Mailingliste genauso wie mit einem einzelnen E-Mailempfänger. Wenn Du also Dein E-Mailprogamm im Griff hast, dann sollten auch mit den Mailinglisten von OpenOffice.org keine Schwierigkeiten auftreten. Bitte bedenke aber immer, dass einige hundert Menschen mitlesen und fasse Deine Beiträge mit entsprechender Sorgfalt ab, um uns Lesern das Verständnis zu erleichtern. Die Sprache der Mailingliste ist Deutsch und wir Duzen uns. Eine gute Idee ist es meist, erst mal einige Zeit die Mailingliste lesend zu verfolgen, um ein Gefühl für den Ton zwischen den Mitarbeitern zu erhalten. Des weiteren gibt es eine so genannte Netikette, also eine Etikette für das Netz, die allgemeine Hinweise zu guten Umgangsformen im Netz gibt.
Eine kurze Vorstellung mit Deinem Namen und Beruf wird gern gesehen, ist aber keine Pflicht. Es ist sehr hilfreich, wenn Du noch zufügen kannst, in welchem Umfeld (Schule, Universität, Behörde, Firma etc.) Du OpenOffice.org einsetzt und wo Du Deine Stärken und Ziele bei der Mitarbeit siehst. Wenn Du Dich gerne vorstellen willst, aber noch nach Worten suchst, vielleicht inspirieren Dich diese Beispiele: http://de.openoffice.org/dev/team.html
Die dev-Mailingliste dient der (internen) Organisation des Projekts und ist für diejenigen gedacht, die sich aktiv
ins Projekt einbringen wollen. Hier geben die Kollegen auch Hilfestellung, wenn es um die Bedienung von IssueZilla und anderen Werkzeugen
geht oder es werden neue Ideen diskutiert. Über die dev-Mailingliste werden auch Aufgaben verteilt. Letztlich gibt es
keinen Aspekt der internen Projektorganisation, der nicht auf dev besprochen werden könnte.
Allerdings gibt es einige spezialisierte Listen zum Thema marketing
und business, in denen diese Themen besser
aufgehoben sind.
Fragen von Nutzern werden umfassend auf der Mailingliste users
beantwortet.
Themen, die anderen Projekten zuzuordnen sind, sollten auf deren
Mailinglisten angesprochen werden.
Schau in die "Project tools"-Box auf einer unserer Webseiten. Klicke auf Mailing lists und schon hast Du die Links
zu den einzelnen Mailinglistenarchiven des de-Projekts. Oder Du klickst diesen Link an.
Als Alternative kann man sich auch an ein externes Archiv wenden, z.B. hier.
Eine PM ist eine persönliche Mail. Keinesfalls alle Kommunikation zwischen Mitarbeitern des Projektes muss über die Mailingliste laufen, sondern meist nur das, was auch für mehr als zwei von Interesse ist. Das ist natürlich im Ermessen des Einzelnen, aber im Zweifelsfall solltest Du Dich an die Liste wenden. Nicht an die Liste sondern direkt an den entsprechenden Mitarbeiter schicken solltest Du Dateianhänge, z.B. mit korrigierten und überarbeiteten Dokumenten.
Zudem kann PM auch Pressemitteilung bedeuten.
Am Anfang ist es nicht ungewöhnlich, nicht alle Mails zu verstehen, das gibt sich aber schon nach kurzer Zeit. Wenn Du eine Abkürzung,
einen Ausdruck oder die Bedeutung eines Themas nicht verstehst, dann frage einfach in der Liste nach.
Wirklich alle Mails zu lesen ist nicht notwendig. Konzentriere Dich am Anfang am besten auf die Mails, in denen es um allgemeine Fragen
geht oder um den Themenkomplex, an dem Du mitarbeiten willst. Um das auch anderen zu erleichtern, solltest Du ein aussagekräftiges
Subject/Betreff in Deinen Mails wählen.
dadurch wird Zustimmung (+1) oder Ablehnung (-1) zu einem Abstimmungsvorschlag, einer Idee oder einem Diskussionsgegenstand geäußert.
Wenn die Haltung der Mitglieder des Projektes zu einer Frage unklar ist, kann ein Abstimmung durchgeführt werden, bei der alle
Projektmitglieder auf der Mailingliste ihre Meinung durch ein +1 oder ein -1 kundtun.
Bei Abstimmungen sollte man darauf achten, dass der Vorschlag verständlich formuliert ist und allen Beteiligten genug Zeit
(im Rahmen von Tagen) gegeben wird, darauf zu reagieren. Ebenso kann eine Abstimmung die Meinungsbildung durch Diskussion in der Liste nicht ersetzen.
Abstimmungen können auch über zu vergebende Posten geführt werden. Dabei sollte vorher genug Gelegenheit bestehen, Kandidaten in
der Mailingliste vorzuschlagen. Wenn möglich sollten diese sich in der Mailingliste vorstellen. Die Durchführung obliegt zwei
Wahlleitern und geschieht per Mail an den Wahlleiter, lediglich das Ergebnis wird auf der Liste bekannt gegeben. Eine derartige Abstimmung
kann auch für wesentliche Projektentscheidungen verwendet werden.
Folgende deutschsprachigen Mailinglisten werden angeboten:
Die Anmeldung erfolgt durch einen Klick auf den Namen in der obigen Liste oder auf der Seite: http://de.openoffice.org/servlets/ProjectMailingListList.
Alle Moderatoren bekommen eine Mail mit dem Betreff "MODERATE for ...@de.openoffice.org" in der die abgewiesene Mail als Anhang dabei ist.
Die Mail können wir dann akzeptieren (einfach auf die Mail antworten) oder mit einem Kommentar abweisen. Spam löschen wir einfach nur.
Wenn eine Mail abgewiesen wurde und der andere sie dann durchgehen lassen würde, geht das auch nicht. Dann gibt es eine Meldung zurück,
dass die Nachricht bereits "rejected" wurde.
IssueZilla ist ein eigenes Werkzeug von OpenOffice.org. Es basiert auf Bugzilla, was OpenSource ist und von dem Mozilla-Projekt entwickelt wurde. Es wurde aber von CollabNet erweitert, um alle Typen von Anliegen handhaben zu können und nicht nur solche, die den Quelltext betreffen. Zur Zeit werden folgende Anliegen unterstützt: Fehler (defect), Erweiterung (enhancement), Feature, Aufgabe (task) und Patch. Wir können in Zukunft neue Typen hinzufügen und sie können verschiedenen Komponenten der Projekte zugeordnet werden: 'Dokumentation', 'Code', 'Benutzeroberfläche (ui)', 'Definition'. Projekte bei OpenOffice.org sind beispielsweise 'API', 'Diagramme (chart)', 'Datenbankzugriff (database access)', 'Zeichnen (drawing)', 'Formeleditor (formula editor)', 'Präsentation (presentation)', 'Tabellenkalkulation (spreadsheet)', 'Textverarbeitung (word processor)' und 'XML', um nur einige zu nennen. Wirf einen Blick auf die Projektliste, um alle zu sehen.
Vermutlich hast Du vergessen, Deinem Browser zu sagen, er müsse Cookies zulassen. Die Authentifikation von OpenOffice.org zu Dir wird über Cookies gewährleistet. Leider gibt sie keine Rückmeldung, wenn die Erlaubnis zum Setzen von Cookies fehlt. Erlaube Cookies und lade die Seite neu. Dann sollte IssueZilla kooperativer sein.
Einige Felder werden bereits automatisch ausgefüllt, andere sind erst zu einem späteren Zeitpunkt der Bearbeitung interessant.
Es ist nicht schlimm, wenn am Anfang nicht alle absolut korrekt ausgefüllt ist. Neue Issues werden zuerst von Mitgliedern des
QA-Projektes bearbeitet, die die Einstellungen überprüfen und gegebenenfalls noch einmal nachfragen, wenn mehr Informationen benötigt werden.
Du solltest aber auf jeden Fall eine möglichst treffende Kurzbeschreibung Deines Anliegens im Feld "summary" hinterlassen und soviel wie
möglich Informationen im Kommentar hinterlassen, dass andere Dein Anliegen verstehen.
Dazu kannst Du Dich in die Mailingliste eintragen, die diese Information für das de-Projekt verbreitet:
issues@de.openoffice.org, Liste zur Verteilung aller IssueZilla-Nachrichten des de-Projekts.
Zudem werden Issues, die wichtig für das de-Projekt sind, auch auf der dev-Mailingliste angekündigt.
Das hängt davon ab, was Du über den Issue weißt.
Wenn es einer von Deinen Issues ist, dann steht er auf der Seite, die Du durch den Link My Issues in der linken Navigationsleiste finden kannst.
Wenn Du die Nummer kennst, kannst Du diese auf der Seite Find an Issue, die Du über
die linke Navigationsleiste erreichst, in das Feld Jump to Issue ganz rechts oben eintragen und wirst sofort dahin geführt.
Wenn Du sonstige Informationen hast, dann kannst Du diese in die Felder der Seite
Find an Issue eintragen und die Suche starten. Besonders interessant sind die Felder
Summary und Description. Aber Du kannst auch einfach bei Component "de" auswählen und Dir
alle offenen Issues des de-Projekts
anzeigen lassen, was vermutlich ein ganz guter Einstieg ist, wenn Du einfach etwas Übersicht gewinnen willst.
In der Datei issuezilla_suchen.pdf oder im
OOowiki findest Du weitere Informationen und natürlich hilft Dir auch die dev-Mailingliste.
In einigen Fällen bekommst Du automatisch eine E-Mail zugestellt, wenn jemand an einem Issue arbeitet:
Falls Du über alle Issues eines Projektes oder über alle Issues informiert werden möchtest, kannst Du die issue-Mailinglisten der Projekte oder die globale liste allbugs@openoffice.org abonnieren.
Als erstes willst Du vermutlich über alle Veränderungen an diesem informiert werden. Dazu kannst Du den Issue abonnieren,
indem Du Deine OOo Emailadresse in das Feld Add CC: einträgst. Nach jeder Änderung der Felder musst Du
diese dem Issuezilla mitteilen, indem Du auf den Commit Knopf klickst. Du musst hierzu natürlich eingeloggt
sein und Cookies aktiviert haben.
Als nächstes willst Du Dich vermutlich an der Diskussion im Issue mit Deinen Ideen beteiligen. schreibe Deinen Text in das
große Textfeld Additional Comments und mache einen Commit. Es ist eine gute Angewohnheit
auch zu jeder Änderung eines der Felder einen Kommentar zu schreiben.
Nach demselben Muster kannst Du auch Dateien hinzufügen. Klicke dazu auf
Create a new attachment, das etwas
versteckt am Ende der bereits zugefügten Attachments steht. Es öffnet sich eine neue Seite, in der Du den Ort des
Attachments auf Deiner Festplatte, eine Kurzbeschreibung und den Filetyp angeben kannst. Bitte verwende Binary für OOo Dokumente.
Submit fügt das Attachment hinzu.
Änderungen am Status eines Issues (z.B. lösen, neu zuweisen ...) dürfen neben demjenigen, der den Issue eröffnet
hat und dem aktuellen Bearbeiter nur Helfer mit speziellen Rechten. Wenn Du Dich intensiver mit Issues befassen möchtest, solltest
Du beim qa-Projekt mitarbeiten. Eine detailliertere Beschreibung der dortigen Prozesse würde über diese Einstiegshilfe hinausführen.
Bitte das Projekt "documentation" benutzen und "translation@openoffice.org" dann direkt bei "Assigned to" eintragen. Bitte immer die deutsche Texte, die fehlerhaft sind, genau zitieren, und die Korrektur dann ebenfalls dazu schreiben, falls möglich. Die Beschreibung im Issue sollte jedoch auf Englisch sein, weil der translation@openoffice.org-Manager nur Englisch versteht. Er leitet die Issues dann entsprechend weiter an die Übersetzer der jeweiligen Sprachen.
Die Webseite des deutschsprachigen OpenOffice.org-Projekts ist für alle Interessenten und Anwender des
OpenSource Office Suite die erste und bequemste Anlaufstelle. Hier erhält man alle Informationen zu neuen Programmversionen,
findet eine Übersicht aller Downloadserver, kann Dokumentationen, FAQs und "Erste Schritte"-Anleitungen für die Module
von OpenOffice.org finden und sich über aktuelle Projekte informieren.
Auf den ersten Blick ist nicht gleich zu erkennen, dass sich die Startseite von de.OpenOffice.org
aus mehreren Bereichen zusammensetzt, die in der unteren Grafik markiert sind:
Am oberen Rand (1) der Startseite von de.OpenOffice.org findet man das Menü
der internationalen Seite des OpenOffice.org-Projekts. Alle Links führen auch direkt zur internationalen Seiten.
Diese Menüleiste findet man auf allen Seiten der OpenOffice.org-Projekte.
In der rechten oberen Ecke befinden sich die Felder und Links, um sich auf der Webseite anzumelden bzw. einzuloggen. (2)
Der untere Teil der Webseite ist projektspezifisch (3). Aufgrund der hohen Besucherzahlen auf den deutschsprachigen Seiten hat
das Projekt eine eigene Startseite, die an die internationale Startseite angelehnt ist. Sie soll die Besucher möglichst
schnell direkt zu ihrem Ziel leiten.
Im Zentrum ist eine Kurzbeschreibung des ProDukts und der Download-link zu finden. Auf der linken Seite (4) findet man vier
farblich hervorgehobene Links zu einer Einführungsseite, dem Support, der Sitemap und einer Seite zu Kontaktadressen.
Auf der rechten Seite (5) sind detailierte Produktbeschreibungen verlinkt. Darunter befinden sich aktuelle Mitteilungen (6)
und Links zu Veranstaltungen und Neuigkeiten (7).
Bei allen anderen Seiten außer der Startseite findest Du auf der linken Seite allgemeine Projektlinks und die "Project tools",
die z.B. Mailinglisten, Dokumentationen und Foren enthalten können. Auf der rechten Seite findet sich die Navigationsleiste
unseres deutschsprachigen Projektes. Alle Links auf dieser Seite führen in der Regel zu Webseiten, die innerhalb
des Projekts erstellt und gepflegt werden. Über den Link "Infos für Helfer", der sich am unteren Ende der
rechten Navigationsleiste befindet, gelangt man zu einer Seite, welche sich in erster Linie an die (potenziellen) Helfer
des Projekts wendet.
Das OpenOffice.org-Projekt besteht aus einer großen Anzahl von freiwilligen Mitarbeitern, die zum Großteil einen Teil
ihrer Freizeit damit verbringen, sich für OpenOffice.org einzusetzten – was auf eine Vielzahl von unterschiedlichen Weisen passieren kann.
Neben den vielen Vorteilen, die durch die freie Mitarbeit bestehen, ergibt sich auf der anderen Seite aber auch die Notwendigkeit, auch weiterhin neue
Mitarbeiter zu werben, die das bereits bestehende Team verstärken und durch ihre Mitarbeit auch die Zuverlässigkeit erhöhen.
Nur durch neue Mitstreiter kann das Projekt wachsen und sich auch in Zukunft weiterentwickeln.
Bevor im Folgenden beschrieben wird, wie man dem OpenOffice.org-Projekt allgemein und dem deutschen Sprachprojekt (lang/de) insbesondere
beitritt, sei noch versichert, dass man durch eine Anmeldung keinerlei Verpflichtungen eingeht und sich von nichts abhängig macht.
Jeder Mitarbeiter kann seine Zeit selber einteilen und entscheiden, wann er mit welchem Zeitaufwand welche Tätigkeiten macht und
wann er OpenOffice.org einfach OpenOffice.org sein lässt. Niemand kann aufgrund seiner Anmeldung zu etwas verpflichtet werden.
Die Rolle, d.h. die Stellung und Verantwortlichkeit einer Person im Projekt, hängt von ihrer früheren Leistung ab. Diejenigen, die für lange Zeit wertvolle Mitarbeiter waren, bekommen das Recht, Quellcode direkt an den Server zu übermitteln.
Für Projekte, die Code entwickeln, sind Rollen essenziell, da nur so die Qualität des Produkts durch die Erfahrung
der Developer garantiert werden kann.
Da wir im de-Projekt keine Code-Entwicklung betreiben, sind Rollen nicht so wichtig, jeder kann unabhängig von seiner
Stellung helfen. Dennoch solltest Du Dir überlegen ob Du nicht die Observer-Rolle beantragen willst. Zum einen tust Du damit
Dein Interesse am de-Projekt kund und zum anderen erhälst Du das Recht zur Abstimmung bei den regelmäßig stattfindenden
Wahlen der Projektleiter. Mit der Observerrolle gehst Du keine bindenden Verpflichtungen ein.
User (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.
Observer (wörtlich Beobachter, besser: Mitwirkender): 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. Im Quelltext dürfen alle Beitragenden, die an der Datei gearbeitet haben, ihren Namen zu der Liste der Mitwirkenden hinzufügen.
Developer (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 des Projektes. Ein Entwickler
von Inhalten (Content Developer) 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.
Project Owner (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.
Unsere Übersetzungsarbeiten an Dokumenten laufen überwiegend auf http://oooauthors.org/de. Dort findest Du eine kurze Einleitung, wie wir das dort handhaben. Auf http://oooauthors.org/de/authors findest Du eine Übersicht der übersetzten und zu übersetzenden Dokumente. Dieser Leitfaden enthält umfangreiche Hinweise für Übersetzer und Korrekturleser.
Nachdem Du Dein Wunschdokument gefunden und Dich als Mitarbeiter dort eingetragen hast, solltest Du als erstes das Dokument auf "retract"/
zurückziehen setzen, damit es aus der "Review List"/ Revisionsliste verschwindet und nicht mehrere Mitarbeiter gleichzeitig
an einem Dokument arbeiten.
Beim Korrekturlesen solltest Du erstens das Dokument auf Rechtschreibungs- und Grammatikfehler überprüfen und zweitens prüfen,
ob Menüpunkte, Beschreibung und Screenshot zur aktuellen Version passt. Und drittens geht es nicht nur um eine fehlerfreie Dokumentation,
sondern vorrangig darum, ob sie verständlich ist.
Wenn Du auf den Verweis in der Review-Liste klickst, hast Du oben rechts in der grünen Leiste ein "State:"/ Status. Das steht jetzt auf "pending"/ sichtbar. Wenn Du auf den Pfeil daneben klickst, wählst Du "retract"/ zurückziehen aus dem Aufklappmenü. Damit verschwindet es dann von der Review-Liste.
Ja. Aber vergiss nicht, das Aufzeichnen der Änderungen einzuschalten: "Bearbeiten - Änderungen - Aufzeichnen". Für alternative Formulierung kannst Du auch Notizen ("Einfügen -Notiz") nehmen.
Mach es so, wie Du es schaffst. Zeitlich gibt es bei uns keine Vorgaben.
Die Webseite wird von CollabNet gehosted. Einige Seiten, besonders die zu den Mailinglisten, dem Datenbereich und der Projektverwaltung werden durch Skripte von CollabNet erstellt. Aber der Inhalt der meisten de-Webseiten wird von Mitgliedern des de-Projektes als (x)html-Dateien erstellt und gepflegt. Zur Verwaltung der Dateien wird dasselbe CVS (Concurrent Versions System) eingesetzt, das auch für den Code von OpenOffice.org Verwendung findet. Ein besonderes Verwaltungssystem für die Inhalte existiert nicht.
Du öffnest einen ssh-Tunnel zu CollabNet, logst Dich mit Deinem OOo-Nutzernamen im CVS ein, führst zunächst ein Update
der fehlerhaften Dateien auf Deine lokale Festplatte durch, korrigierst die fehlerhafte Datei dann lokal und commitest danach die korrigierte
Version mit einem vielsagenden Kommentar wieder ins entfernte CVS. Bei der Korrektur sollte man darauf achten, dass durch den html-Editor
keine zusätzlichen, überflüssigen Veränderungen auch in der Kodierung von Sonderzeichen eingebracht werden.
Aus diesem Grund ist OOo-Writer nicht als Editor geeignet.
Du kannst zunächst die Webseite lokal im CVS-Verzeichnis erstellen. Dann öffnest Du einen ssh-Tunnel zu CollabNet, logst Dich mit Deinem OOo-Nutzernamen im CVS ein, und teilst dem CVS mit, dass eine neue Datei eingepflegt werden soll (Add). Hierbei wird unterschieden, ob es sich um eine reine Textdatei handelt, zu der spätere Änderungen zeilenweise erfolgen sollen, oder ob es eine Binärdatei ist. Dann führst Du ein normalen Commit der Datei mit einem vielsagenden Kommentar durch.
Tunnel und Anmeldung dienen der Zugangskontrolle, damit tatsächlich nur die Personen, die eine entsprechende Berechtigung haben,
die Webseiten ändern können. Die Verwendung des CVS erleichtert zudem die Versionierung und erlaubt es, sowohl die Veränderungen
zu verfolgen als auch bei Fehlern alte Versionen wieder herzustellen.
Grundsätzlich sind die jeweiligen Schritte einfach und wiederholen sich immer wieder. Nur die ersten Versuche sind etwas schwierig.
Bei Fragen stehen die erfahrenen Nutzer auf der dev@de-Liste gerne helfend zu Seite. Besonders wenn Du nicht planst nur wenige Korrekturen
vorzunehmen, ist es einfacher, die Korrekturvorschläge an jemanden zu schicken, der schon CVS-Schreibrechte hat.
Dazu sind sowohl einige technische als auch administrative Hürden zu überwinden.
Zunächst benötigst Du Content-Developer-Status im de-Projekt. Diesen kannst Du in der Projektverwaltung beantragen
und er wird Dir vom Projektleiter zugeteilt. Eine Unterzeichnung des JCA ist (für die Webseite allein) nicht mehr unbedingt
notwendig aber empfohlen. Schließlich legst Du noch einen Issue an, in dem Du die Techniker von CollabNet bittest, einen selbst
erzeugten ssh-Schlüssel zu akzeptieren und wartest, bis das erfolgt ist.
Auf der technischen Seite werden Software für Schlüsselerzeugung, ssh-Tunnel und den CVS-Zugriff selbst benötigt.
Je nach verwendetem Betriebssystem existieren hier verschiedene freie und kommerzielle Lösungen. Im unixoiden Bereich sind Kommandozeilentools
meist bereits integriert, für Windows kann Cygwin, WinCVS oder SmartCVS verwendet werden.
Detailierte Anweisungen finden sich auf:
Auf der Mailingliste cvs@de.openoffice.org werden alle Änderungen im entsprechenden Verzeichnis angezeigt. Dabei werden aufgeführt: Namen des Bearbeiters, Datum, Namen der geänderten Dateien, die eingegebenen Kommentare und die Änderungen selbst aufgeführt. Dies dient vor allem denjenigen, die häufig Änderungen durchführen, zur Information. Für andere Mitglieder ist sie bestenfalls langweilig.
Alle auf den Seiten des Projekts genannten Ansprechpartner und diejenigen, die in der Mailingliste dev@de.OpenOffice.org eingeschrieben sind. In diese Liste kannst Du auch Mails schicken, ohne eingeschrieben zu sein.
zurück zu "Wer wir sind" | zurück zu "Wie wir uns organisieren" | zurü zu "Lizenzen"
zurück zur Mitarbeiter-FAQ-Hauptseite | zurück zur Übersichtsseite der deutschsprachigen FAQs