Hallo, Am Mittwoch, den 15.07.2009, 11:47 +0200 schrieb Steffen Eibicht: > Hallo, > > erstmal wollte ich los werden, dass ich so eine Aufstellung und die > Diskussion darüber richtig gut finde. > > Hier meine Meinung: > > 1. die Rollenzuordnung finde ich passend. Ich muss aber dazu sagen, dass > ich mich in den Strukturen der Zusammenarbeit mit den einzelnen > Projekten nicht auskenne, da ich eben noch relativ frisch in der > Linuxwelt bin.
Ich habe eigentlich auch keinen Einblick in die Arbeitsweise anderer Teams. Wichtig ist, denke ich, dass wir Strukturen finden, die zu uns passen. > > 2. Aufgrund meiner noch nicht ganz so vorhandenen Erfahrung würde ich > gern weiterhin "nur" als Übersetzer arbeiten. Das ist eine Rolle, die > mir liegt und die ich ohne Überforderung ausfüllen kann. Ich kann auch > wie in der jüngeren Vergangenheit schon getan, die Lokalisierungssparte > von ubuntuusers.de durchforsten und ggf. auf Basis von dort angebrachten > Kritikpunkten Korrekturen in Launchpad durchführen. Gerade für die Mitarbeit bei den Anfragen aus ubuntuusers.de bin ich wirklich sehr dankbar. Dadurch wird nach außen deutlich, dass wir ein funktionierendes Team sind und auf die Anliegen der Benutzer reagieren. Manchmal werden hier aber Probleme gemeldet, die man nicht ad hoc in Launchpad lösen kann, weil etwa eine Abstimmung mit dem Upstream notwendig sind. Aktuelles Beispiel hierfür ist etwa das Problem mit »Orte => Computer«. Da hier mehrere Leute bei der Fehlerbehebung beteiligt werden müssen, wäre es vielleicht eine Idee, bei solchen Problemen einen Fehlerbericht in Launchpad zu erstellen, über den wir dann unsere Aufgaben abstimmen. Das könnte auch für die Anwender eine bessere Transparenz bringen, wenn wir etwa den Fehlerbericht in ubuntuusers.de verlinken. > > 3. zu den Festlegungen: > > die Festlegung eines Zeitplans finde ich gut. Das gibt den Leuten > Orientierung. > Zusätzlich würde ich aber auch die Fertigstellung des Zeitplans selbst > auf einen bestimmten Zeitpunkt festlegen. Eventuell könnte das ja > während der Richtliniendiskussion passieren? Damit haben die Leute die > Sicherheit, dass der Zeitplan zu einem bestimmten Zeitpunkt herauskommt > und man nicht orientierungslos im »luftleeren Raum« hängt. Ja, die Festlegung des Zeitplans wäre einer der ersten Aufgaben. Meine groben Ideen zum Zeitplan wären: - im 1. Monat nach jedem Release nehmen wir uns eine Auszeit ;-) - bis Ende des 2. Monats vereinbaren wir die Ziele. Hier sollte sich jeder grob überlegen, wie viel Zeit er investieren kann, sodass wir die Aufgaben priorisieren können. Am Ende dieser Phase steht der Zeitplan und die Aufgabenliste. - bis zum Ende des 3. Monats ist die Richtliniendiskussion offen. Änderungswünsche an den Richtlinien und neue Standardübersetzungen können eingebracht und diskutiert werden. Danach sind die Richtlinien für dieses Release »eingefroren«. Weitere Änderungswünsche können erst im nächsten Release wieder diskutiert werden. Somit haben wir bei jedem Release eine stabile Basis für die jeweiligen Übersetzungen. > > Qualitätssicherung: > - Beim Lesen von "Review Berichten" ist mir aufgefallen, dass ich z.B. > die Hilfetexte usw. die ich Übersetzt habe, noch nie "in echt" im System > gelesen habe. > Vielleicht sollten wir generell Reviews durchführen und sie in der > ruhigeren Zeit nach den Releases mit auf die Aufgabenliste schreiben? Gute Idee! > Denn zumindest mir geht es so, dass ich mir zwar Aufgaben annehme und > sie auch durch- und zu ende führe - das aber nur in der erforderlichen > Disziplin, wenn irgendwo eine Aufgabe steht. Reviews sind wichtig, wenn > sie aber nirgends aufgeführt sind, macht sie auch keiner. Deshalb: > können wir sie mit auf die Aufgabenliste schreiben, mit der Bemerkung, > dass sie ausschließlich in der ruhigeren Phase durchgeführt werden? Ggf. sollten wir die Aufgabenliste in mehrere aufsplitten, denn sie ist jetzt ja schon relativ lang. Eine mögliche Aufteilung wäre: - Software - Dokumention - Qualitätssicherung > > - ich denke, dass wir den Bugtracker im Zusammenhang mit den in > ubuntuusers.de gemeldeten Fehlern vergessen können. > Die User melden die Fehler im Forum, worüber ich persönlich auch dankbar > bin. Wenn sie aber zusätzlich noch einen Bugreport schreiben sollen, > überfordert man sie und ihre Geduld, denke ich. > Manche können Bugreports schreiben, manche nicht, manche haben keine > Launchpad-ID... usw. Daraus könnte evtl. eine verbreitete Ansicht > erwachsen: "wenn ich den Fehler im Forum melde, wollen die, dass ich > einen Bugreport schreibe, also lasse ich es, weil ich keinen Bock auf > Bugreport-schreiben habe". Sehe ich auch so. Wie gesagt, meine Idee wäre, dass wir Übersetzer bei Problemen, die zur Behebung länger benötigen. selbst Bug-Reports erstellen. > > - Konzentration der Übersetzer auf ein bestimmtes Aufgabengebiet finde > ich auch gut. Es sollte aber nicht in "Stein gemeiselt" sein, was > bedeutet, dass Übersetzer auch andere Aufgaben annehmen können, wenn > dort gerade Mangel an Manpower ist. Sehe ich genauso. > > - Aufnahme von Mitgliedern ins Launchpad-Team: > Ich finde die ersten Punkte gut. Man sollte die aufgeführten Kriterien > (Dauer der Mitarbeit, Anzahl der Übersetzungen und Qualität der > Übersetzung) auf jeden Fall einführen. > Das mit der Bewerbung über die Mailingliste finde ich aber nicht so > toll. Ich fände es besser, wenn der Aufgabenkoordinator und die > Team-Admin's sich über die Aufnahme der neuen Mitglieder aufgrund o.g. > Kriterien abstimmen und auch die Entscheidungsgewalt darüber haben. > Ich denke, dass man solche starren Regeln, wie Mitarbeit >6 Monate, > Karma >500 nicht unbedingt anwenden sollte. Denn das wichtigste ist doch > die Qualität der abgelieferten Ergebnisse und ob der einzelne ins Team > passt. Ich verstehe, dass eine Bewerbung über die Mailingliste nicht so toll ist. Für mich ist es aber auch nicht in jedem Fall ganz einfach, zu entscheiden, wer aufgenommen werden sollte und wer nicht. Mir wäre es lieb, wenn es da entweder objektive Kriterien oder eine Art Abstimmungsprozess gäbe. > > - zu den allgemeinen Fragen: > Verbesserung der Zusammenarbeit mit Upstream... > Das alles ist für mich eine Sache, von der ich absolut keine Ahnung > habe. > Vielleicht wäre es deshalb nicht schlecht, den Leuten, die keine Ahnung > von den Details in der Zusammenarbeit mit z.B. Debian, Gnome oder KDE > usw. haben, so etwas wie eine Erläuterung ähnlich dem > Übersetzungsprozess an die Hand zu geben? Also z.B.: was tut das Ubuntu > Translators Team im großen open source Universum?, was tun die Debian-, > Gnome- und KDE, usw. Leute? Wie fließen die Übersetzungen von Upstream > in Ubuntu und wie kommen die Übersetzungen von Ubuntu wieder zurück in > Debian, Gnome, KDE usw.? Das ist nicht systemtechnisch gemeint (= »in > Launchpad übersetzen wir "xy" und das fließt dann über Software "abc" > über Kanal "0815" dort hin«) sondern schematisch, abstrakt. > Denn ich denke, das fehlendes Verständnis der detaillierten > Zusammenhänge auch zu schlechterer Zusammenarbeit führen. Gute Idee! > > Das wären meine Punkte und Meinungen... Vielen Dank für deine Ideen. Besten Gruß, Jochen -- Jochen Skulj http://www.jochenskulj.de GPG Key-ID: 0x37B2F0B8 Finger Print: F239 5D8D 97CD F91F 9D08 AE94 AA3B 1ED5 37B2 F0B8
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Translators-de mailing list [email protected] https://eshu.ubuntu-eu.org/mailman/listinfo/translators-de
