Hallo zusammen,
nachdem Jacqueline ja bereits aus Ihrer Sicht vom Besuch in Hamburg
berichtet hat, möchte ich das nun auch nachholen.
Für mich lag der Schwerpunkt eher auf dem Donnerstag, der grösstenteils
für die Diskussion mit Thorsten Ziehm (Manager StarOffice QA) genutzt
wurde. (Danach auch mit mehreren Leuten aus dem SUN QA-Team).
Wir haben einige ToDo's definiert .. zunächst möchte ich aber meinen
groben Eindruck zusammenfassen.
Insgesamt empfand ich das Treffen als sehr positiv. Thorsten hatte
einige Zahlen und Statistiken zur QA-Arbeit zusammengefasst. Aus denen
ergibt sich für mich, dass die Teams bei Sun und in der Community sicher
unterschiedliche Arbeitsprozesse haben und in verschiedenen Bereichen
arbeiten. Das ist aber aus meiner Sicht nicht wirklich hinderlich
sondern sollte sinnvoll genutzt werden. So kann das Team bei Sun in der
Regel viel schneller reagieren (da fest angestellt) hat mehr Ressourcen
für das Testing und diverse Tools zur Verfügung, die Informationen
zusammenfassen, die sonst mühsam gesucht werden müssten (z.B.
Zusammenfassung von Issuezilla, EIS, Mozilla und debian Bugtracking
Systemen).
Die Community kann aber ein wesentlich breiteres Spektrum an
Plattformen, System- und Sprachumgebungen abdecken und hat auch ein viel
breiteres Spektrum an Wissen, welches man in einem zahlenmässig
begrenztem Team kaum aufbauen kann.
Interessant waren die Zahlen, die klar zeigten, dass die Community in
verschiedenen Bereichen immer mehr Arbeit übernimmt. So wurden in der
1.x Codelinie 87% der Bugs von Sun selbst gemeldet ... für die
2.0-Codelinie sind es nur noch 25%.
Eine Befürchtung von mir, dass wir mehr Arbeit erzeugen, als wir
erledigen, konnte klar ausgeräumt werden. Die Arbeit der Community beim
confirmen von Issues wird als sehr hilfreich empfunden.
Allerdings war zu spüren, das wir die Prozesse, ablaufen bzw. die in
letzter Zeit geändert wurden, zu wenig kennen und untereinander
abstimmen. Das war einer der Gründe, warum es zum Release der 2.0 /
2.0.1 ziemlich chaotisch zuging.
Wichtig an dieser Stelle ist zu bemerken, dass für die 2.0 codelinie das
Testing bei Sun wesentlich in Richtung CWS-Testing verlagert wurde. D.h.
während bei 1.x neue Features intensiver im "zusammengebauten"
Masterbuild getestet wurden, werden sie jetzt eher einzeln getestet.
Als Konsequenz daraus wollen wir versuchen, dass für die nächsten
Versionen (2.0.3) kurz nach dem FeatureFreeze Testversionen
bereitgestellt werden und auch Tests koordiniert werden. (zum Vergleich
- das wäre für 2.0.2 m150 gewesen, Anfang Januar). Ausserdem soll die
RC-Phase etwas ausgedehnt werden, da diese auch intensiver getestet
werden müssen als die RC's von 1.x.
einige weitere ToDo's, die demnächst angegangen werden sollen:
- verstärktes Testen neuer features durch die Community (es gibt dazu
Testbeschriebungen, die aber noh auf "Veröffentlichbarkeit" geprüft
werden müssen)
- stärkeres einbeziehen der Community in das CWS-Testing (entsprechende
Dokus und Anleitungen müssen bereitgestellt werden)
- mehr Informationen in Issuezille bereitstellen (z.B. in welchem CWS /
Milestone ein Issue gefixed wird .. diese Infos sind bei Sun durchaus
vorhanden, es ist nur nicht trivial, diese nach IssueZille zu "bugsieren")
- Community besser in die Featureplanung einbeziehen (sicher ein
long-term Ziel ... wobei zuerst einmal die Informationen fliessen
müssen, wann mit de Planung neuer features begonnen wird)
- Auflisten von Wünschen bzgl. TCM und schrittenweises umsetzen der
Wünsche ( Wünsche sind hier willkommen:
http://wiki.services.openoffice.org/wiki/TCM_wishes)
- Commnity stärker in das verifizieren / schliessen gefixter Issues
einbringen (also das, was wir jetzt schon für die ersten Schritte im
Leben eines Issues machen, auch für die letzten übernehmen)
Einige Punkte davon kann man kurzfristig angehen .. andere eher nicht ;-)
Die meisten brauchen etwas Vorbereitung, damit zumindest grundlegende
Beschreibungen bereitgestellt werden können .. also bitte nicht
erwarten, dass wir morgen mit all dem anfangen.
Über den zweiten Tag bzgl. des Hilfe Reviews und der Lokalisierung hatte
Jacqueline ja schon ausführlicher geschrieben. Wichtig aus meiner Sicht
war dabei, dass man solche fokussierten Aufgaben nicht ohne intensive
vorherige Abstimmung angehen kann und soll. Es wurde mehrfach bestätigt,
dass das Problem vor dem Review massiv unterschätzt wurde und ohne diese
spezielle Form des Reviews würden Korrekturen wohl ewig brachen.
Insofern auch nochmal von mir Anerkennung und Dank an alle, die dort
mithelfen.
Soviel für den Moment,
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
