Difference between revisions of "DE/PrOOo-Box-Issues"

Revision as of 19:34, 27 April 2006

Hier soll eine genauere Beschreibung des Lebenszyklus' eines Issues zur PrOOo-Box entstehen, bisher kam ich aber erst dazu, die Angaben aus einer Listenmail hierher zu kopieren (aus Bernhards Mail an cdrom-Liste - ich modifiziere sie aber immer mal wieder...):

(Vorbemerkung: Die hier beschriebenen Änderungen werden im Entwickler-Bereich durchgeführt, aus dem das nächste ISO gebildet wird und das dann auf den Live-Bereich übertragen wird.)

prinzipieller Verlauf der Issue-Bearbeitung

Die Überarbeitung der PrOOo-Box wird über den Issue Tracker koordiniert, in dem die einzelnen Aufgaben in Issues aufgegeben werden, die dann einzelnen Mitarbeitern zugeordnet werden.

Dieser Mitarbeiter bekommt (auch wenn er diesen Issue noch nicht beobachtet hatte) automatisch eine Mail zu diesem Issue und kann auf die Kommentare im Issue reagieren. Entweder, indem er den Teil der Arbeit, für den er sich (entweder im Allgemeinen oder durch eine Mail auf die cdrom-Liste) bereit erklärt hat, tut, und danach den Issue wieder zurück- oder an den nächsten Bearbeiter "assign"t. Oder er möchte diese Arbeit im Moment nicht übernehmen - dann schreibt er einen entsprechenden Kommentar und "assign"t den Issue einfach an 'prooobox' (s.u.).

Wenn es absehbar ist, dass man sich innerhalb der nächsten Woche überhaupt nicht darum kümmern wird (es wird niemand nach den Gründen fragen), dann wäre eine kurze Mitteilung sinnvoll (oder die Issue-Zuordnung an 'prooobox').

Zuordnung eines Issues

Alle Issues mit dem Subprojekt "cdrom" werden standardmäßig dem "Besitzer" diees Subprojektes zugeordnet: 'prooobox'. Dahinter stehen die Ansprechpartner der PrOOo-Box: Friedrich Strohmeier und Bernhard Dippold. Sie bekommen sofort eine automatische Mail, wenn ein solcher Issue angelegt wird. Einer der beiden entscheidet, was weiter mit diesem Issue geschieht.

Wenn einem Mitarbeiter das Issue zugeordnet ist, dann hat er die Berechtigung, nach dem Einloggen als OOo-user deutlich mehr Felder zu ändern als sonst.

So kann er unterhalb des Feldes, in das er den Kommentar schreibt zusätzlich einen Auswahlknopf wählen, um das Issue jemand anderem zuzuordnen ("assignen"). In der Regel wird das Issue vom Bearbeiter entweder dem nächsten Bearbeiter oder dem "owner of the selected subcomponent" (=Besitzer des gewählten Unterbereichs) zugeordnet (für "subcomponent=cdrom" ist das 'prooobox').

Ändern des Issue-Status

Ein neu aufgegebener Issue hat den Status "NEW" (bei internationalen Issues "UNCONFIRMED", weil ein Mitarbeiter der QA ihn noch bestätigen muss).

Sobald der erste Mitarbeiter (Im Beispiel untern Mitarbeiter_1 oder Mitarbeiter_2) sich dieses Issues annimmt, ändert er den Status auf "STARTED". Wie schon beim "assignen" geht das in der Regel nur, wenn der Issue diesem Mitarbeiter zugeordnet ist. Damit sagt er aus, dass er sich dieses Issues annimmt (muss aber noch nicht unbedingt damit begonnen haben).

Nach dem Einbau der überarbeiteten HTML-Seiten und Programme in die PrOOo-Box-Struktur ist der Issue "RESOLVED". Der Mitarbeiter, der den Einbau durchgeführt hat, ändert den Status (vor dem Zuordnen - sonst geht das nicht mehr!) auf diesen Wert mit der Zuordnung der Art der "Resolution" - in der Regel "FIXED" (die anderen Möglichkeiten dienen der Differenzierung, warum ein Issue nicht - oder noch nicht bearbeitet wurde)

Wenn das Issue getestet wurde, wird (wieder vor dem Zuordnen!) der Status auf "VERIFIED" geändert.

Ist alles in Ordnung, schließt der letze Bearbeiter (bei uns André) den Issue ->Status "CLOSED" - Falls noch ein Problem auftreten sollte, kann er auch wieder "REOPENED" werden...

(ausführlichere englische Beschreibung in der Issue Tracker-Hilfe)

Beispiel des Ablaufs

Ein Beispiel wäre die Aktualisierung der Logos:

1. Meldung durch Mitarbeiter (oder "Externe")

-> assigned to: 'prooobox'

2. Übersicht, was daran getan werden muss (Friedrich oder ich) und Weiterleitung an jemanden (Mitarbeiter_1), der sich für die Suche von Dateien aus dem Projekt bereit erklärt hat (schlechtes Beispiel: ich weiß, wo die Logos stehen - aber ich denke, Ihr versteht, was ich meine)

-> assigned to: Mitarbeiter_1

3. Dieser Mitarbeiter sucht die Dateien heraus und meldet den Link im Issue. Wenn er schon weiß, wer den nächsten Schritt macht (Mitarbeiter_2), assigned er ihn direkt an ihn (sonst gibt es noch einen Zwischenschritt: "reasssign to owner of selected subcomponent", wodurch 'prooobox' die Weiterverteilung übernimmt)

-> assigned to: Mitarbeiter_2 (im Moment Erich = 'epix')

4. Mitarbeiter_2 aktualisiert die HTML-Seite(n) und hängt sie an den Issue (falls er nicht gleich Mitarbeiter_3 ist). Im gleichen Zuge muss auch die Datei Changelog.txt im devel-Hauptverzeichnis aktualisiert werden, in der alle Änderungen der Box dokumentiert sind. Wenn diese Datei mit der letzten veröffentlichten Version beginnt, bitte eine neuen Absatz oberhalb mit Titel "aktualisiert in der Devel-Version" einfügen - der Titel wird vor dem ISO-Bauen dann auf den neuen Versionsnamen geändert.

Der Issue wird weiter an Mitarbeiter_3 (oder, falls nicht bekannt, zurück an 'prooobox') geschickt.

-> assigned to: Mitarbeiter_3 (auch noch Erich = 'epix')

5. Die Seite(n) wird/werden in die devel-Box eingebaut, danach ist die letzte Aufgabe ihre Überprüfung (Text, Inhalte und alle Links, die von der Seite ausgehen). Hierzu wieder das gleiche Vorgehen: Entweder an prooobox oder direkt an Mitarbeiter_4

-> assigned to: Mitarbeiter_4 (im Moment: Michael = 'reichowmi')

6. Dieser Tester "Überprüfer" (Mitarbeiter_4) hat sich bereit erklärt, die Box auf Rechtschreibfehler und funktionierende Links zu testen (für eine einzelne oder einige zusammengehörende Seiten ist das wesentlich einfacher als für die gesamte Box direkt vor dem Release). Nach der Überprüfung bekommt André als für den Verein Verantwortlicher den Issue zugeordnet, um die rechtliche Seite abzusichern.

(-> assigned to: 'andreschnabel')

André möchte aber nicht, dass wir mit dem Bauen/Veröffentlichen eines ISOs warten, bis er alle Issues geschlossen hat - wenn er sich nicht schon vorher geäußert hat, dürfen wir sein Einverständnis voraussetzen.