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.

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. Wenn man versucht, kurzfristig vor einem Release noch neue Ziele anvisiert, wird es chaotisch und die Qualität leidet. Ich 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.

Verbesserung Qualitätssicherung

• Unabhängig vom Korrekturlesen sollten wir die Ubuntu-Dokumentation und Ubuntu-Software prüfen
• Ich 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.

Ü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.

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?
• 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 andere Übersetzungsteamss haben.