[de-discuss] Nachlese QA-Wochenende 2011

Hallo zusammen,

mit etwas Verspätung möchte ich eine Nachlese zu unserem QA-Wochenende im
Essener LinuxHotel nachreichen, das vom 17. bis 19.06.2011 stattfand.

Das QA-Wochenende ist seit Jahren eine fest eingeplante Veranstaltung, die für
mich immer wieder ein Highlight ist. Es ist sicher die Mischung aus Information,
produktivem Arbeiten und geselligem Beisammensein an einem beeindruckenden Ort,
die die Veranstaltung stets zu etwas ganz Besonderem macht. An dieser Stelle
nochmals ein großes Dankeschön an Reinhard, Ingo und alle anderen vom
LinuxHotel, die uns das alles überhaupt möglich machen. 

Dieses Jahr war ich etwas wehmütig, da trotz der vielen bekannten Gesichter und
einiger neuer Mitstreiter einige wichtige fehlten, die die Diskussionen und das
Arbeiten mit ihrem Fachwissen und auch ihrem Humor immer sehr bereichert haben.
Ich denke, den meisten ist klar, wen ich meine. Darüber hinaus fehlten zwei
Teilnehmer, weil sie erkrankt bzw. verletzt waren. Von hier aus nochmals gute
Besserung an Volker und Uwe!

Der Freitag dient immer der Anreise, an dem üblicherweise kein Programm geplant
ist. Auch schon fast in alter Tradition wird der Grill angemacht und über Gott
und die Welt (und LibO :-) geplaudert. Mittlerweile wird dabei auch regelmäßig
das Wetter ignoriert. Grillen bei Sonnenschein ist ja auch wirklich nur etwas
für Anfänger. Dieses Jahr wollten wir die Jahresbestmarke übertreffen, sind aber
nur auf insgesamt 3 x Grillen gekommen und haben damit den Vorjahreswert
eingestellt. Für das nächste Jahr rege ich an, bereits das Frühstück auf dem
Grill vorzubereiten.

Am Samstag starteten wir nach einem gemeinsamen Frühstück mit dem Programm, das
wir nur locker zusammengestellt haben, um Luft für aktuelle Themen und
Fragestellungen zu haben.

Link zum Programm im Wiki:
http://wiki.documentfoundation.org/DE/QAWochenende2011

Der Vormittag stand ganz unter dem Zeichen LibreOffice / TDF und den aktuellen
Geschehnissen rund um die Apache Foundation und das OpenOffice.org-Projekt.
Florian und André informierten uns über den aktuellen Stand und wir schauten in
unsere Glaskugeln und diskutierten, wie es wohl mit den Projekten weitergehen
wird. Dieser Programmpunkt war natürlich ergebnisoffen...

Es kam auch die aktuelle Webseite de.libreoffice.org zur Sprache und wir
stellten fest, dass es sinnvoll sei, dort Hinweise auf Referenzkunden und auf
Dienstleister für LibO zu geben. Während diese Listen bei OOo mit der Zeit in
den Hintergrund getreten sind, ist es unserer Ansicht nach gerade jetzt
besonders wichtig, die Präsenz von LibreOffice zu zeigen und auch zu vermitteln,
dass bereits heute Firmen auf LibreOffice für den produktiven Einsatz setzen.
Die Referenzkundenliste und Anwenderberichte sollen auf de.libreoffice.org
veröffentlicht werden, während die Liste von Dienstleistern wieder auf den
Seiten des Vereins Freies Office Deutschland e.V. verfügbar gemacht werden soll.

Rainer brachte dann ein weiteres Thema zur Sprache, was im unmittelbaren
Zusammenhang mit dem Ziel des Wochenendes stand. Er berichtete von der stetig
steigenden Anzahl der "unconfirmed" Bugs und den Problemen, diese sinnvoll zu
bearbeiten. Hier sind dringend weitere Mithelfer gefragt, die dabei helfen, die
neuen Bugs nachzuvollziehen und zu bestätigen. Er hatte jetzt auch schon eine
Mail rumgeschickt, dass ein monatliches Bughunting im irc stattfinden soll, an
dem man gemeinsam die neuen Bugs bearbeitet.

Recht lange haben wir auch über den Bugtracker an sich bei freedesktop.org
diskutiert. Es gibt das ein oder andere, was wir uns für die bessere Übersicht
und Bearbeitung der Bugs wünschen, was aber nicht möglich ist, weil wir keinen
Einfluss auf den Bugtracker selbst haben. Hier kam die Frage auf, ob es Vorteile
bringt, einen Bugtracker wieder selbst aufzusetzen. Die größte Schwierigkeit ist
derzeit, dass Bugs - unabhängig davon von wem sie erstellt werden -
standardmäßig den Status "New" erhalten und nicht "unconfirmed". So fällt unsere
bisherige Strategie weg, dass alle "new" Issues bereits bestätigt wurden,
während die "unconfirmed" diejenigen sind, die man noch anschauen muss. Rainer
arbeitet derzeit mit einer sehr individuellen Abfrage, die aktuell noch gut
funktioniert, weil die Anzahl der Mithelfer im Bereich QA noch sehr
übersichtlich ist. Das wollen wir aber so bald wie möglich ändern. :-)

Nach der Mittagspause (und dem Grillen!) widmeten wir uns dem Thema
"Übersetzungen". André berichtete von der letzten Übersetzungsrunde und fragte
insbesondere nach Schwierigkeiten, die im Zusammenhang mit dem
Übersetzungsprozess und insbesondere mit dem Online-Tool "Pootle" auftraten.
Insgesamt laufen die Übersetzungen schon recht rund, da es einige wenige sehr
aktive Übersetzer gibt, die auch diese großen Mengen bewältigen.

Zum Thema Übersetzungen haben wir einige To Do's aufgenommen:

- allfiles.tree:
In Erfahrung bringen, wie diese Datei zur Modifikation der Hilfe für neue
Versionen generiert werden kann.

- Änderungen in Pootle:
Ein Manko bei Pootle ist nach wie vor, dass man als Reviewer nicht erkennen
kann, wo genau Änderungen gemacht wurden. Daher ist es aktuell noch wichtig,
parallel zu den Übersetzungsrunden die Wikiseiten zu pflegen und dort zu
kennzeichnen, welchen Status die Übersetzungen haben.

- Kommentare in Pootle:
Kommentieren ist nur dann möglich, wenn man entsprechende Rechte hat, die
gleichzeitig das Bestätigen von Übersetzungen ermöglichen. Jeder, der bereits
einmal gewissenhaft mitgearbeitet hat, soll diese Rechte erhalten.

- Neue UI-Begriffe:
Bei der Übersetzung der UI sollten neue Begriffe direkt mitprotokolliert werden,
damit die Übersetzung der Hilfe dann konsistent erfolgen kann. Die Begriffe
sollten direkt ins Glossar aufgenommen und im Wiki gelistet werden.

- Build mit UI-Übersetzung:
Um die Hilfeübersetzung zu vereinfachen und zur Kontrolle der Textlängen in den
Dialogen sollte rechtzeitig ein Build bereitgestellt werden, der die
UI-Übersetzung bereits enthält.

- Terminologie in Pootle:
Bei den Übersetzungen werden Begriffe, die im Glossar enthalten sind,
eingeblendet, allerdings nur, wenn nicht das Zeichen ~ (zur Kennzeichnung der
Mnemonics) enthalten ist. Hierfür sollte direkt bei Pootle ein Bugreport
aufgegeben werden.

- Weitere Aufgabe für Übersetzer:
In Pootle werden die Übersetzungen automatisch nach typischen Fehlern überprüft
(zum Beispiel doppelte Leerzeichen, o.ä.). Die erkannten Fehler müssten einmal
systematisch durchgegangen und bearbeitet werden. Dies könnte eine Aufgabe für
das Projektwochenende in Hof sein.


Als nächsten Programmpunkt haben wir das Thema QA / neue Funktionen
durchleuchtet. Konsens bestand darin, dass wir aus Sicht der Qualitätssicherung
Spezifikationen brauchen und insbesondere eine zentrale Stelle, wo man
Informationen zu neuen Funktionalitäten finden kann. Diese müssen auch für die
Qualitätssicherung nachvollziehbar sein. Zwar sind aktuell in der Regel alle
Änderungen transparent und im Web einsehbar, jedoch muss man sich die Infos
teilweise an sehr verstreuten Stellen wie Blogs, Issuetracker, Mailingliste o.ä.
zusammensuchen.

Im Kreis der Anwesenden waren wir uns einig, dass die Spezifikationen nicht zu
formal sein sollten, da sonst wieder die Gefahr besteht, dass diese Arbeit wegen
des zu großen Aufwands nicht gemacht wird. Wir wollten daher versuchen, ein
einfaches Schema im Wiki vorzubereiten, das anhand eines konkreten Features
durchgespielt wird, ob es den ersten Anforderungen genügt. Hier hat André
bereits einen sehr guten Anfang gemacht, danke dafür!

Einige wenige Stichpunkte, die eine solche Wikiseite enthalten soll, haben wir
direkt zusammengetragen:
- Template Owner
- Summary
- Status 
- Verantwortliche Mitwirkende
- Entwickler
- UI-relevant ja/nein
- Änderung Hilfe / Documentation erforderlich
- Beschreibung
- Related Issues / Blogs
- Additional Proposals
- Roadmap / Geplante Version

Das Thema Spezifikationen kann nur sinnvoll angegangen werden, wenn hier
Qualitätssicherung und Entwicklung an einem Strang ziehen. Für Entwickler muss
ebenso nachvollziehbar sein, warum Specs notwendig und sinnvoll sind. Hierzu
würden wir gerne ein gemeinsames Treffen planen, um über diese Thematik zu
besprechen. Geeignet wäre dies zum Beispiel während der geplanten
LibO-Konferenz, die im Oktober in Paris stattfinden wird.


Nach diesem Themenblock gingen wir nahtlos zum Abendprogramm über. Nach einer
kurzen Stärkung am Grill (was auch sonst?) kümmerten wir uns direkt um das
Bughunting, erstellten ein Glossar, überprüften einige der gekennzeichneten
Fehler in Pootle, kümmerten uns um die Webseite, Infrastruktur etc. Schön ist es
immer mit anzusehen, wie dann kreuz und quer durch den Seminarraum die Gespräche
gingen, Issuenummern genannt wurden, wie sich zeitweise hinter einem Laptop
kleine Menschentrauben versammelten, oder wie man auch das ein oder andere
Fluchen oder andere "Schreie" vernehmen konnte.

Alles in allem haben wir einen sehr produktiven Tag verbracht, der mir zudem
auch viel Spaß gemacht hat (und ich hoffe, den anderen Teilnehmern auch).


Am Sonntag Morgen begann das Programm wieder mit Florian, der uns viele
interessante Infos zur eingesetzten Infrastruktur bei LibO/TDF gab und uns
erklärte, wie der Releaseprozess und die Bestückung der Mirrors aus
Infrastruktur-Sicht vonstatten geht. Es ist wirklich beeindruckend, wer und was
da alles im Hintergrund "werkelt" und welchen Aufwand es bedeutet, all das zu
administrieren und am Laufen zu halten. Das sind leider alles Dinge, die man
erst dann sieht, wenn etwas nicht mehr läuft und andere ihre Arbeit nicht mehr
machen können. Daher Dank an Florian und all die anderen, die sich stetig darum
kümmern!


Den Abschluss des QA-Wochenendes gestaltete Andreas mit seiner Präsentation zum
LibreOffice-Extension-Center. Er stellte uns das geplante Extension-Repository
vor und zeigte live den aktuellen Stand.

Auch bei diesem Thema schlossen sich direkt Diskussionen an. Wir besprachen,
dass es eine automatische Account-Generierung geben muss, so dass jemand, der
eine Extension bereitstellen möchte, dies sofort tun kann, ohne dass er auf eine
manuelle Bestätigung warten muss. Dennoch sollen bei dem Extension-Portal auch
Leute aus der Qualitätssicherung mithelfen. Vor Veröffentlichung einer Extension
soll zumindest eine kurze Prüfung erfolgen, so dass kein "Unsinn" hochgeladen
wird.

Zu einem späteren Zeitpunkt, wenn das Portal erst einmal steht und genutzt wird,
soll auch eine inhaltliche Qualitätssicherung der Extensions erfolgen. In der
Vergangenheit haben wir häufig die Erfahrung gemacht, dass nicht jede Extension
mit einer neueren Version funktioniert oder dass es Schwierigkeiten auf
einzelnen Betriebssystemen gibt. Die Ergebnisse eines solchen Checks sollen dann
im Portal sichtbar gemacht werden, so dass sich potenzielle Nutzer vor der
Installation einer Extension informieren können.

Damit endete das diesjährige QA-Wochenende und ich freue mich schon jetzt wieder
auf das nächste Jahr!

Sooo viel Text... danke an alle, die es geschafft haben, bis hierhin zu lesen!

Viele Grüße,

Jacqueline

P.S.: Einige der hier geschilderten Ergebnisse sollten eigentlich noch ins Wiki
übertragen werden. Ich komme dazu erst am Wochenende, falls also bis dahin
jemand Langeweile verspürt, kann er/sie das gerne übernehmen.



-- 
Informationen zum Abmelden: E-Mail an discuss+help@de.libreoffice.org
Tips zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: http://listarchives.libreoffice.org/de/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert