Ubuntu Wiki

Hier entsteht eine Seite mit Informationen darüber, wie wir in Zukunft bei der Übersetzung eines neuen Releases vorgehen wollen. Im Moment fehlen uns für eine derartige Vorgehensweise noch Zeit und Mitarbeiter.

- == Zu erledigende Aufgaben (grober Zeitplan) == - - === Vor Release === - - * Umfang der nötigen Übersetzungen feststellen (und bis zum Freeze vorgenommene Änderungen überwachen) - * Pakete in unserem Aufgabenbereich (Ubuntu-spezifisch) - * Pakete mit Ubuntu-spezifischen Anpassungen - * Pakete (v.a. aus main) mit bekannten Schwächen / die, weil komplett neue Version, überprüft werden sollten - * Zuweisen von Prioritäten - * (siehe Übersetzungsprozess) - * letzte Überarbeitung (Korrekturlesen) nach Freeze - - === Nach Release === - - * Auf Fehlermeldungen reagieren (evtl. Supportzeitraum angleichen -> längerer Support für LTS-Releases) - * Ggf. Korrekturen an Upstream übermitteln - * Gibt es Fälle, in denen neue zu übersetzende Strings hinzukommen? - - === Ständige Aufgaben === - - * Pflege der Standardübersetzungen und Richtlinien - * Pflege / regelmäßige Aktualisierung Wiki allgemein - * Kommunikation (v.a. mit Upstream) - * evtl. Listenmoderation - * evtl. rudimentäre PR (Reaktionen auf schlechte Presse, Kommunikation mit z.B. ubuntuusers.de) - * Einführung möglicher neuer Mitglieder (Mentoren) - * neue Mitglieder aufnehmen / feststellen, welche aktiv sind (lässt Leistung evtl. nach?) und ob neue Kräfte benötigt werden (Admin) - * Regelmäßiges Reflektieren über Vorgehensweise, QA (jährliche Treffen?) */

Rollen

Vorschlag für Rollen im Team:

Daraus entwickeln wir eine »Teamseite« auf der wir die Rollen beschreiben und die dann auch eine Übersicht bereitstellen, welcher Mitarbeiter welche Aufgaben wahrnimmt.

Schrittweise entwickeln wir dann für die einzelnen Aufgaben Prozesse und dokumentieren diese im Wiki.

Fehlende Festlegungen

Momentan werden Aufgaben oft noch »spontan« erledigt. Das klappt zwar oft, aber birgt die Gefahr, dass bei ähnlichen Problemen ganz unterschiedliche Ergebnisse erzielt werden oder die Abläufe nicht für jeden nachvollziehbar ist (was zu Frust führen kann).

Daher sollte es für zentrale Aufgaben Festlegungen oder Prozesse geben. Im Folgenden werden dazu einige Ideen zur Diskussion gestellt. Diese Aufstellung kann gerne ergänzt werden.

Roadmap

Ziele müssen langfristig für jedes Release geplant werden; verantwortlich dafür sollte der Teamkoordinator sein. Wenn man versucht, kurzfristig vor einem Release noch neue Ziele anvisiert, wird es chaotisch und die Qualität leidet. Ich (Jochen) bin daher dafür, pro Release einen Zeitplan festzulegen. Dabei sollten wir eine begrenzte Zeit die (neuen) Ziele für ein Release diskutieren und diese danach umsetzen. Zur »Roadmap« gehört für mich auch, dass wir in der »heißen Phase« zwischen Documentation String Freeze und Ende der Übersetzungen keine neuen Übersetzer aufnehmen.

Diskussionen über Richtlinien

• Wir sollten ein klares Vorgehen für die Diskussion von Richtlinienänderungen definieren.
• Eine solche Diskussion sollte sich in eine Diskussions- und Abstimmungsphase unterteilen.
• Bei Richtlinienänderungen, bei denen in der Diskussion unterschiedliche Standpunkte vertreten wurden, sollte die Entscheidung inkl. Pro- und Contra-Argumente im Wiki dokumentiert werden.
• Um die Diskussion effizienter zu gestalten, sollten wir feste Zeitpunkte (x Monate vor einem Release) festlegen, zu denen über alle neuen Vorschläge bzw. bereits vorhandene Standardübersetzungen diskutiert wird.

Verbesserung Qualitätssicherung

• Unabhängig vom Korrekturlesen sollten wir die Ubuntu-Dokumentation und Ubuntu-Software prüfen
• Ich (Jochen) halte es manchmal für sinnvoll, zwischen der Fehlerdokumentation und der Fehlerbehebung zu trennen. Dies ermöglicht es, systematisch zu prüfen, ob ein Fehler in anderen Packages auch auftritt. Eine Idee wäre, Prüfungen, die unabhängig vom Korrekturlesen durchführen, mit »Review-Berichten« (im Wiki?) dokumentieren
• Sollten wir den Bugtracker von Launchpad stärker nutzen? Eine Idee wäre, Fehler, die etwa über ubuntuusers.de gemeldet werden, zunächst einen Bug einzustellen. Im Einzelfall wäre das vielleicht etwas aufwändiger, aber langfristig könnte man eventuell mehr Anwender dazu bringen, direkt Bugs zu melden.
• Ich (Moritz) hielte es für sinnvoll, wenn Übersetzer nur in bestimmten Bereichen (z.B. Xubuntu) übersetzen, in die sie sich bereits eingearbeitet haben (Standardübersetzungen etc.). Dadurch würde die Konsistenz und somit die Qualität gefördert.
• Bei jährlichen (z.B. Ubucon) oder halbjährlichen persönlichen Treffen könnte man ausführlichere Diskussionen über langfristige Ziele führen.

Überwachung des Übersetzungsfortschritts

• Es kann immer wieder vorkommen, dass man sich in die Aufgabenlistee einträgt, aber dann doch andere Dinge dazwischenkommen, sodass man die Aufgabe nicht abschließen kann
• Eventuell sollten wir in die Aufgabenliste ein »Endedatum« einfügen. Nach Ablauf prüft der Aufgabenkoordinator, ob die Aufgabe vollständig bearbeitet wurde. Ist dieses nicht der Fall, organisiert er - etwa über die Mailingliste - einen neuen Bearbeiter organisieren.
• Für jeden größeren Bereich ((K/X)Ubuntu-Doku (K)Ubuntu-Programme etc.) sollten wir langfristig einen Aufgabenkoordinator finden, der den Überblick über seinen Bereich behält. Dieser sollte gewählt werden.

Neuaufnahme von neuen Mitgliedern ins Launchpad-Team

• Die Kriterien zur Aufnahme ins Launchpad-Team sollten festgelegt werden. Dazu gehören meiner Meinung nach Dauer der Mitarbeit, Anzahl der Übersetzungen und Qualität der Übersetzung
• Vielleicht sollten wir ein Verfahren einführen, bei dem man sich über die Mailingliste für das Launchpad-Team bewerben muss, Korrekturleser die Bewerbung unterstützen müssen oder Veto einlegen können.

• In anderen Teams gibt es Regeln wie Aufnahme erst nach 6 Monaten und/oder mit einem Karma > 500. Sind solche Regeln auch sinnvoll für uns?

Allgemeine Fragen

• Wie verbessern wir die Zusammenarbeit mit Upstream-Projekten?
  • Eine Möglichkeit wäre, zu festgelegten Zeitpunkten die »Changed in Launchpad-Strings« (soweit sinnvoll) an Upstream zu schicken.
  • Eine andere Möglichkeit zur Verbesserung der Zusammenarbeit wäre es, an den Übersetzungen der in »main« enthaltenen Programmen mitzuarbeiten (bei Upstream Übersetzung reservieren, in Launchpad übersetzen, Abgleich mit Upstream).
• Wie integrieren wir uns besser in die deutsche Community?
• Wir sollten ggf. im Wiki auch eine englischsprachige Zusammenfassung unserer Vorgehensweise veröffentlichen, da wir ja auch Berührungspunkte zu Entwicklern und anderen Übersetzungsteams haben.