Hallo zusammen, am Freitag, den 9.2.07 hatte ich erneut die Gelegenheit, bei Sun in Hamburg vorbeizuschauen. Wie bereits die letzten beiden Besuche vorher war, auch dieser für mich sehr hilfreich und informativ. Vieles lässt sich direkt in einem persönlichen Gespräch viel besser und schneller besprechen als es über die Online-Kommunikation ginge. Auch wenn ich sicher nicht die kompletten Gespräche wiedergeben kann, möchte ich doch das (aus meiner Sicht) Wichtigste für euch zusammenfassen. Vielen Dank an Rafaella, Berit, Joost, Stefan und Chris, die sich für mich Zeit genommen haben!
## Lokalisierung / Übersetzung ## Am Vormittag habe ich zusammen mit Berit Bonde und Rafaella Braconi über Themen sprechen können, die die de-Lokalisierung betreffen. Insbesondere wollten wir die beiden vergangenen Durchgänge der Community-Hilfe-Übersetzung Revue passieren lassen. Wir besprachen die aufgetretenen Hindernisse und Schwierigkeiten und wie wir die Arbeit für zukünftige Runden einfacher gestalten können. Viele unserer Schwierigkeiten lagen sicher in nicht ausreichender Kommunikation und unserer fehlenden Erfahrung mit den Tools und dem tatsächlichen Arbeitsprozess (was passiert mit den Dateien nach unserer Übersetzung, wie werden sie ins Programm integriert, wer macht wann den Review, wie und wann gelangen die Korrekturen in die Hilfe, etc.). Schon seit der ersten Übersetzungsrunde wollte ich die kleine Wiki-Seite erweitern und dort an zentraler Stelle alle wichtigen Infos sammeln, um so auch späteren Mithelfern den Einstieg zu erleichtern. Ich möchte gerne alle wichtigen Links (zum Glossar, etc.) zusammentragen und auch eine FAQ beginnen. Rafaella will diese Idee auch für die anderen Communities aufgreifen und eine Wiki-Seite ins Leben rufen, auf der alle NL-Communities ihre Erfahrungen sammeln können. Insbesondere die Holländer und Italiener haben in der letzten Zeit viel zu den Übersetzungen beigetragen, so dass das sicher eine große Hilfe für uns alle sein wird. Wie es andere NL-Communities schon vormachen, könnte langfristig das Ziel sein, dass wir die regelmäßigen Übersetzungsrunden komplett übernehmen (derzeit umfasst der übliche Umfang bei einem Update ca. 5000-7000 Wörter). Viele Kleinigkeiten haben wir noch besprochen, wie man z.B. für die zukünftigen Übersetzungen das TM (Translation Memory) zur Verfügung stellen kann. (Manche Dinge sind viel einfacher, als ich dachte: Der Reviewer, der als letztes alle Übersetzungen nochmal durchgeht, kann aus den übersetzten Texten einfach ein komplettes TM erstellen. Dort ist dann alles drin, was man für die nächste Runde braucht). Zudem haben wir darüber geredet, dass deutsch in Zukunft nicht mehr Source-Sprache sein wird und dann genauso wie alle anderen Übersetzungssprachen gehandhabt wird. Von großem Vorteil wird sein, dass Übersetzungsissues deutlich schneller bearbeitet werden können und wir (langfristig) selbst solche Änderungen durchführen können. Konkret bedeutet das für uns schon eine Änderung: Übersetzungsfehler im UI sollen im Issue-Tracker nicht mehr in der jeweiligen Modul-Komponente aufgegeben werden, sondern unter l10n – UI. Issues, die für [DE] bereits aufgegeben wurden, aber noch nicht gefixt sind, sollten wir beizeiten auf l10n umschreiben. Wenn es soweit ist, werde ich dazu noch einen entsprechenden Aufruf starten. Ich habe derzeit keinen genauen Überblick darüber, wie viele Issues dieser Art noch offen sind und ob das ein größerer „Akt“ wird. Bereits im letzten Jahr haben wir uns als Aufgabe einen „UI-Review“ vorgenommen, wegen vieler anderer Projekte bisher aber noch nicht die Zeit gefunden. Ist der Umbau im Programm erfolgt, dass deutsch nicht mehr Source- sondern Übersetzungssprache ist, können wir gezielt die UI nach Schreibfehlern / falschen Begriffen etc. durchkämmen, die Änderungen direkt in den sdf-files vornehmen, damit diese dann integriert werden können. Für diese Aufgabe werden wir einen sogenannten keyid-build bekommen, damit wir die jeweiligen zu korrigierenden Stellen auch leicht in den sdf-files finden. Kombiniert mit der Möglichkeit, mit Hilfe des testtools automatisch Screenshots zu erstellen, sollte das dann eine überschaubare Aufgabe sein. Idealerweise steht dieser besondere Build bereits zum nächsten QA-Wochenende zur Verfügung, vielleicht können wir dann mit solchen Arbeiten schon beginnen oder zumindest die Vorbereitungen dafür treffen (zum QA-Wochenende gibt es bald weitere Infos). ## QA ## Nach dem Mittagessen sprach ich mit Joost Andrae, Stefan Baltzer und Chris Lukasiak. In diesem Gespräch sollte es von meiner Seite zunächst um das nächste geplante QA-Wochenende gehen, das wieder im LinuxHotel stattfinden soll (wahrscheinlich Anfang Mai). Mir ging es vor allem darum, ob wieder jemand von SUN dabei sein kann und welche Themen dort angegangen werden können. Aufgrund des wirklich produktiven letzten Treffens wird Sun die Veranstaltung auch wieder mitgestalten. Ich freue mich sehr, dass Stefan und Joost auch dieses Jahr wieder dabei sein wollen und vielleicht noch weitere aus dem Sun-Team mitkommen. Genaueres zum QA-Wochenende (wann, wer, was und vor allem warum :-) ) werde ich in den nächsten Tagen zusammenstellen, sobald ich genauere Infos habe. Im weiteren Verlauf des Gesprächs ging es um ein Anliegen, das insbesondere Chris und Stefan auf ihrem Programm haben und dazu ein erstes Feedback aus der Community hören wollten. Generell wird von Sun angestrebt, die Community noch stärker in die eigentlichen QA-Arbeiten einzubinden. Während zum Beispiel bei Issues aufgeben die Community bereits einen enormen Anteil von derzeit ca. 86 % hat, liegt in anderen Bereichen der Hauptanteil nach wie vor bei Sun. Langfristig wird angestrebt, dass sich zum Beispiel auch beim CWS-Testen oder beim Verifizieren von gefixten Issues im Master mehr Community-Mitglieder einbringen. In einem ersten Schritt wird derzeit an einer Neuausrichtung der QA-Webseiten gearbeitet. Bei den Überlegungen, wie die Seiten sinnvoll aufgebaut werden sollen, will man sich auch an den gewachsenen Strukturen der de-Community orientieren und diese sozusagen exemplarisch betrachten. Insbesondere steht die Idee im Raum, QA-Teams zu bilden, die den einzelnen Modulen bzw. speziellen Bereichen zugeordnet werden. Sun-intern wird das bereits so gehandhabt und ich kann auch von der de-Community sagen, dass wir das intuitiv so machen. Da man sich bei einem so komplexen Programm nicht mit allem befassen kann, sucht sich jeder den Teil heraus, der ihm am besten liegt bzw. mit dem er am meisten zu tun hat (ich spreche da aus eigener Erfahrung, ich kümmere mich auch am liebsten um Writer- oder Impress-relevante Dinge und weiß zum Beispiel, dass ich beim Überprüfen von Base-Issues am besten mal bei Mechtilde nachfrage :-) ). Die Webseiten sollen solche Strukturen auch nach außen hin transparent machen, so dass man leichter einen passenden Ansprechpartner findet und dass die entsprechenden Aufgaben effizienter erledigt werden können. An dieser Stelle möchte ich erstmal ein Kompliment an euch weitergeben, das ich von den dreien im Gespräch aufgeschnappt habe: Die de-Community macht hervorragende QA-Arbeit, was sich auch international herumgesprochen hat. Wir haben in den letzten Jahren enormes Know-How aufgebaut und haben nicht nur vereinzelt Community-Mitglieder, die sehr regelmäßig, konsequent und auf hohem Niveau im Bereich QA mitarbeiten. Ich gebe aber das Kompliment auch gerne an Sun zurück: Der Aufbau dieses Wissens war und ist insbesondere deswegen möglich, weil wir von Sun entsprechend unterstützt werden, sei es durch die Teilnahme an unseren QA-Veranstaltungen oder dadurch, dass sich immer mehr von den Sunies auf auf den Mailinglisten einbringen und dort mit Rat und Tat zur Seite stehen. Diese Mithilfe wird deutlich wahrgenommen und sehr geschätzt (auch wenn so manche Mailinglisten-Reaktion manchmal etwas anderes vermuten lässt). Zwei Aspekte fand ich an diesem Gespräch noch sehr interessant. Zum einen wurde während des Gesprächs sehr deutlich, dass Qualitätssicherung sicher nicht isoliert betrachtet werden kann, sondern dass viele andere Bereiche direkten Einfluss auf die QA-Arbeit haben. So halte ich es zum Beispiel für sehr sinnvoll, die Community bereits während der Definition der Spezifikationen einzubinden. Damit kann man auf die mE immens wichtige Praxis-Erfahrung der Leute bauen und spätere Probleme bereits im Vorhinein verringern – die üblicherweise in Form von Defects oder Enhancements später auch wieder erstmal am QA-Team hängen bleiben. Wenn man also später eine Teambildung nach Modulen mit entsprechend zugeordneten Community-Mitgliedern hat – wäre es doch nicht schlecht, wenn zu jedem „i-Team“ auch ein Community-Mitglied gehören soll. Auch die Arbeit mit dem Issue-Tracker, in dem ja eigentlich alles zusammenläuft wird direkt mit dem QA-Team und den als erstes zuständigen Leuten in Verbindung gebracht. Hier gilt es, auch mal gesammelt die „Karteileichen“ bzw. größere zusammenhängende Blöcke zu bearbeiten, die im Einzelnen vielleicht nicht so relevant sind, die aber trotzdem angegangen werden müssen. Und damit komme ich auf einen weiteren interessanten Aspekt, den wir besprochen haben. Nämlich ging es um die Frage, wie man die Community für bestimmte Aufgaben motivieren kann, die vielleicht nicht so „spannend“ sind. Ich konnte ein bisschen über meine Erfahrungen aus dem de-Projekt erzählen. Es ist eben was anderes, ob man beruflich mit einer Aufgabe befasst ist oder das in seiner Freizeit tut. Das ist auch relevant, ob ich als Freiwilliger mich einer Verantwortung überhaupt stellen kann (nicht nur inhaltlich sondern auch zeitlich – die meisten von uns wissen nicht, ob sie auch in einem halben oder in einem Jahr noch genauso viel Zeit haben, bei OOo mitzuarbeiten). Insofern ist es mE immer wichtig, überschaubare Aufgaben zu definieren, die keine langfristige Bindung mit sich bringen. So kamen wir auf die Idee, vielleicht jedes Release unter ein „Motto“ zu stellen, wo eines dieser Themen aufgegriffen und so aufbereitet wird, dass es zusammen mit der Community auch bearbeitet werden kann. Wenn man kleine überschaubare „Päckchen schnürt“, ist es viel leichter die entsprechenden Mithelfer zu finden, da sie für die konkret anstehende Aufgabe entscheiden können, ob sie -jetzt- Zeit und Lust haben. Kaum jemand von uns kann und will langfristige Verpflichtungen eingehen. In den kommenden Wochen soll die geplante Umstrukturierung der QA-Seiten Formen annehmen, dann werden die Infos sicher nochmal in aufbereiteter Form weitergegeben und diskutiert. Auch am QA-Wochenende wünschen sich die Sunies von uns ein entsprechendes Feedback. So, das war es erstmal von mir (war ja auch lang genug :-) ), Jacqueline --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
