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

From Apache OpenOffice Wiki
< DE
Jump to: navigation, search
m (PrOOo-Box-Issues moved to DE/PrOOo-Box-Issues: Reorganisation der DE-Wiki-Seiten.)
m (Kategorie (einordnen unter Seitennamen, nicht unter D[E]).)
Line 1: Line 1:
[[category:PrOOo-Box]]
+
[[category:PrOOo-Box|PrOOo-Box-Issues]]
  
  

Revision as of 21:39, 18 June 2008



Vorbemerkung:

Die hier angesprochenen Änderungen werden in den Live-Bereich eingearbeitet, aus dem dann das nächste ISO erstellt wird.

Bei Problemen mit dem Zuordnen, Statusändern oder etwas anderem meldet Euch einfach auf der Liste - aber keine Angst beim Ändern: alle Zuordnungen können wir auch wieder korrigieren ;-)

Issuetracker - Besonderheiten

Im Issue Tracker des DE-Projektes gibt es für Belange der PrOOo-Box eine Subkomponente "cdrom".

Mit den unten stehenden Links kann man direkt auf die Seiten des Issue Trackers zugreifen, wenn man sich die Liste der offenen PrOOO-Box-Issues anzeigen lassen will oder nach einem bestimmten PrOOo-Box-Issue sucht (Suchstring unten auf der Seite unter "Summary" eingeben, für mehrere Wörter benachbartes Feld auf "all words/string" umstellen): Link zur Suchseite

Aufgaben oder Fehler zur PrOOo-Box können hier direkt eigegeben werden, nachdem man sich mit seinem Mitgliedsnamen angemeldet hat (Es hilft auch sich auf der bei diesem Link aufgehenden Fehlerseite anzumelden und dann mittels "zurück" und "neu laden" an's Ziel zu kommen): zu den Aufgaben und zu PrOOo-Box-Fehlern

(Fragen zum Produkt OpenOffice.org bitte an die Mailingliste users@de.openoffice.org richten)

Prinzipieller Verlauf der Issue-Bearbeitung

Mit Hilfe des Issue Trackers können einzelne konkrete Aufgaben als issues erfasst, und einem Mitarbeiter 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: Erich Christian und Friedrich Strohmaier. 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, muss (wieder vor dem Zuordnen!) der Status erst wieder auf "RESOLVED - FIXED" geändert werden, bevor "VERIFIED" eingegeben werden kann - ich denke, dieses Hin und Her können wir uns sparen.

Wir sollten im Kommentar einfach eingeben, was gemacht wurde und was der nächste machen soll.

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 (Erich oder Friedrich) 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é den Issue zugeordnet, um die rechtliche Unbedenklichkeit für den Verein OpenOffice.org Deutschland e.V. zu prüfen.

(-> 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.

Personal tools