[VoIP] Ticket workflow

[Ralf Schlatterbeck]

On Wed, Apr 16, 2008 at 09:27:10AM +0200, Darshaka Pathirana wrote:
> 
> Hmm. Ich hab mir das nochmal überlegt. In deinem Workflow wird
> assigned und accepted anscheinend mit open zusammengefasst. So wie ich
> das verstandnen habe, ist der Status "assigned" für den
> Verantwortlichen deswegen interessant, da er sofort erkennt, dass
> jemand anderer ihm einen Task übertragen hat. Mit "accepted" erkennt
> er diesen Task aktiv an. Ist jetzt natürlich nicht unbedingt
> notwendig, hört sich aber sehr brauchbar an und ich würde stark dafür
> plädieren.
Das wird dort mündlich gelöst. Schaun wir mal, ob wir da wirklich einen
zusätzlichen Zustand brauchen. Wir sind auch am Anfang der Versuchung
erlegen, alle Prozesse über den Tracker festzulegen. Bis ein Audit kam,
dann haben wir das wieder vereinfacht. Das wichtige an einem Prozess
ist, dass er so informell wie möglich und so formal wie nötig ist. Nur
dann wird er auch gelebt.

Nachdem die ganze History in Roundup aufgezeichnet wird, ist immer
feststellbar, wer was geändert hat -- und damit ist z.B. herausfindbar,
wer wem ein Issue zugeschoben hat, ohne es vorher abzusprechen. Daher
glaubich, dass wir den zusätzlichen Zustand nicht brauchen.

Ausserdem brauchen bestimmte Zustandsübergänge verbindlich eine
Nachricht im "Message" Feld, die dann auch per Email zugestellt wird.
Damit wird der neue Verantwortliche auf jeden Fall über sein neues Glück
verständigt.

> Was aber im trac-WF fehlt ist der äusserst wichtige Status "testing"
> mit einem zum Status "accepted" unterschiedlichen Verantwortlichen.
> Diese Policy gefällt mir sehr gut und sollten wir umbedingt umsetzten.
> Praktisch sollte es dann so ausschauen:
> 
> new - assigned - accepted - testing - closed
> 
> Können wir diese Namensgebung übernehmen und wäre dieser workflow für
> dich auch ok?
Der WF ist OK. Das Umbenennen ist dzt. schwierig, weil einige auditoren
auf den Status-Namen existieren, die dann vielleicht brechen (obwohl die
Zustandsübergänge prinzipiell übers Web-Interface änderbar sind).

Daher möchte ich erstmal die State-Namen nicht ändern, geht aber später
immer noch (obwohl das dann eine leichte Geschichtsfälschung ist).

Ich hab' nächste Woche einen Termin mit einem Kunden, die auch einen
Tracker wollen. Wenn ich diesen Auftrag bekomme, werde ich vermutlich
die Bindung an die State-Namen konfigurierbar machen und das dann auch
in unserem Tracker nachziehen. Sonst würd' ich vorschlagen, erstmal
damit zu leben.

> > - einen eigenen "reopened" gibts nicht, möglicherweise sollte man hier
> >   wieder nach analyzing gehen statt nach open.
> 
> Hmm. Das mit reopened ist so eine Sache. Kommt nicht oft vor und wenn
> sollte man vielleicht doch wissen, dass es ein "alter" bug war. Aber
> fürs erste ist "new" wohl ok.
OK, dann lassen wir es einstweilen so. Alternativ könnte man das Reopen
auch über den Zustand "escalated" spielen (statt direkt nach open zu
gehen). Lass' es uns beobachten, ob die Abläufe passen.

> > - Zusätzlich gibts "suspended" steht für "won't fix now or in forseeable
> >   future"
> 
> Würd ich persönlich über die Priorität (0 oder 1) lösen. So haben wir
> für einen aktiv als unwichtig bewerteten Punkt zwar einen
> Verantwortlichen und müssen nicht extra noch eine "suspended" Liste
> durchgehen.
Von mir aus OK, ich hab den Zustand suspended mal aus den möglichen
Übergängen rausgenommen. Macht die Sache einfacher.

> > - Zusätzlich "escalated" für Bugs die erst beschlossen werden müssen,
> >   s. weiter unten in meinen Kommentaren. Aber dieser Zustand ist ein
> >   Kandidat fürs Entsorgen.
> 
> Bin auch dafür.
OK.

> > Gibts derzeit nicht. In meinem Tracker kann man issues hierarchisch
> > gruppieren (ein issue kann part eines grösseren Issues sein). Damit
> > wurde bisher die Release-Planung gemacht, indem man einfach alles was zu
> > einem Release gehört in einen Container-Issue schmeisst. Was da auch gut
> > ist wenn man an mehreren SW-Teilen parallel arbeitet: Es gibt ein Feld
> > "effective prio" das die Priorität auf Unter-Issues vererbt (wenn die
> > des übergeordneten Issues grösser ist). Die hierarchische Gruppierung
> > kann beliebig tief sein. Ist auch gut, wenn man für die Planung ein
> > grösseres Feature in mehrere Teile zerlegt.
> 
> Ok. Das ist für mich auch in Ordnung. Wir sollten aber in
> Selbstkontrolle schauen dass wir die Tasks nicht zu weit in die Tiefe
> wachsen lassen.
Jupp. Auch aus Performance-Gründen ...

> Sonst hätte ich ein weiteres Feld a la "Topics" mit Milestone
> bezeichet. Soll in Roundup ja nicht so schwer sein... Solange man alle
> in einem Container befindlichen Issues in Listenform anzeigen kann,
> ist es mir aber egal.
Schau doch mal in eines der Container rein. Da gibts ne nette Liste (wo
man optional noch die Hierarchie aufklappen kann) mit Links auf die
einzelnen Issues in verschiedenen Farben...

> >> ad priority)
> >> Beschreibt die Wichtigkeit des Projects. Wobei gilt:
> >> 5 ... showstopper
> >> 4 ... very important
> >> 3 ... important
> >> 2 ... would be nice
> >> 1 ... maybe
> >> 0 ... probably not
> >>
> >> Mit 5 sollten alle Punkte bewertet werden, welche (primär) für
> >> die Mobilkom (oder auch für uns) bis zum nächsten Milestone
> >> unabdingbar sind.  Sparsam verwenden!
> >> Der Rest sollte selbsterklärend sein. Für die meisten Punkte gibt es
> >> im Wiki / Excel-Sheet eh schon den ersten Versuch einer Bewertung.
> > 
> > Es gibt derzeit eine numerische Prio. Die können wir beliebig belegen.
> > Für "effective prio" s.o. In der Praxis (wenn man mit obigen
> > Planungs-Features arbeitet) hat sich bewährt, die Prio im Bereich 0-100
> > zu vergeben. Dann kann man besser Nuancen zwischen Features in der
> > Planung berücksichtigen.
> 
> Ist auch ok. Wir sollten die sechs verbal beschriebenen Prioritäten
> eben auf 100 aufblasen. Wir sollten nur Anhaltspunkte bekommen wir
> hoch wir die Priortät bewerten können oder sollten.
Ich hab jetzt einfach mal alle existierenden Prios mit 10 multipliziert.

> Ok... Wenn du Effort schon hast, dann können wir kurz bewertete Bugs
> als einfach und längere als mittel bis schwierig ansehen. Ich denk,
> wenn wir das so machen ist das auch sehr ok.
Fein.

> >> Beschreibt die (wahrscheinliche) Komponente im Source.
> >> - frontend / gui
> >> - build system
> >> - lib (jede einzeln aufzählen?)
> >> - voice
> >> - video
> >> - branding
> >> - configuration
> >> Fürs erste scheint mir das ausreichend. Ob wir die libs alle einzeln
> >> aufzählen oder einfach nur "library" nehmen, sollten wir auch noch
> >> diskutieren.
> > 
> > Gibts derzeit garnicht bzw. jein, es gibt ein Feld "Category" das aber
> > ursprünglich gedacht ist, um verschiedene Projekte zu tracken. Können
> > wir dafür verwenden wenn wir das wirklich brauchen.
> 
> Ja, dann nehmen wir das. Für weitere Projekte würd ich eher einen
> weiteren Tracker oder ein neues Feld "Project" vorschlagen.
> > Oder "Area" was z.Zt. die Werte Doc, SW, HW, IT enthält und sich als
> > ziemlich nutzlos erwiesen hat. Vermutlich können wir das für die
> > modellierung von component recyclen.

Ich hab jetzt Area genommen, Category bleibt damit für weitere Projekte
möglich.
> Wie auch immer. Wir haben zwei Felder. Das sollte reichen, oder?
Jupp. Die Category hat noch zusätzlich die Möglichkeit, eine default
nosy-list und einen default Verantwortlichen für neue issues zu
definieren. Daher hab ich jetzt die Area genommen und die Category für
neue Projekte gelassen.

> >> ad upstream)
> >> Ist ein boolean welches angibt ob dieser Task für upstream interessant
> >> ist.
> > in meinem Tracker gibt es Keywords, da würde ich "Upstream" und
> > "possibly upstream" vorschlagen. Man kann dann immer noch danach suchen.
> 
> Ja. Die Keywords (oder Tags) sind sowieso ne tolle Sache. Wie wir das
> abbilden und danach suchen können überlasse ich dir. 
> Im schlimmsten Fall kann man sogar alle drei (category, project,
> upstream) über Keyword lösen wenn man prefixe für die Keywords
> verwendet. z.B. proj-A, cat-C, upstream für gehört zu Project "A",
> Category "C" und ist ein upstream bug....

Suchen geht eh, schau Dir mal das Query-interface an.

> >> Zum Ablauf:
> >>
> >> Ein neuer Task hat zuerst immer den Status "new", Severity "unknown"
> >> und Priority nach eigenem ermessen des Submitters (im Zweifelsfall 3).
> > - in meinem Tracker ist das "analyzing", Priority 1 (weil die Prio der
> >   Implementierer und nicht der Reporter festlegen sollte) und Severity
> >   wie vom Submitter festgelegt (Major/Minor/Showstopper), im
> >   Zweifelsfall Minor.
> 
> Wenn wir uns geeinigt haben welche Terminologie wir verwenden und
> unter der Vorraussetzung, dass du den Tracker einfach daran anpassen
> kannst, würd ich sagen, dass Status "new", Priority 1 und Severity
> nach eigenem ermessen im Zweifel "minor" für einen neuen Bug sehr gut
> klingt.

Fein, können wir ja dann bei Gelegenheit noch verbessern.

> > - Es gibt *immer* einen Verantwortlichen. Der wird anhand der Category
> >   bestimmt. Der kann das dann weiter assignen.
> 
> Full ACK. Aber nicht vergessen. Ein reassign sollte noch accepted
> werden. Das halte ich für nicht so schlecht.
Nein, würde ich nicht machen, sollte ausserhalb des Trackers gelöst
werden: Its easier to ask for forgiveness than permission. Und die
menschliche Kommunikation kannst Du eh nicht über den Tracker spielen
(wir hatten alle möglichen Diskussionen, was man alles
erlauben/verbieten können soll und haben uns dann drauf geeinigt, dass
es einfacher ist, das nachher nachzuvollziehen was passiert ist und im
Zweifelsfall mehr zu erlauben).
Was mit so einem zusätzlichen Zustand passiert ist, dass das Issue in
einem Zwischenzustand ist: Der eine will es nicht mehr, der andere hats
noch nicht angenommen.

Wir haben auch gedacht, dass es dann zu wilden Ping-Pongs von Issues
kommt. Ist bis jetzt nie aufgetreten.

> Hmm. Das verstehe ich nicht ganz. Meinst du, dass wenn ich im Code
> einen Fehler finde und behebe trotzdem einen Bug eintragen soll...
> Wenn ja, brauchen wir trotzdem kein "escalated"... Die Bewertung des
> Fixes und das Assignen auf sich selbt sollte der Entwickler schaffen.
> Und die Bewertung passiert eh erst von "new" auf "assigned". Immer.
Ja, da ist eher die direkte Kommunikation in einer
Entwicklungsmannschaft in einer Firma gemeint: Da passiert es oft, dass
irgendwas "auf Zuruf" geändert wird, weil es eh nicht viel Aufwand ist.
Stimmt auch meistens, ist aber besser das trotzdem -- mit einem
einfachen Prozess -- im Tracker sichtbar zu haben. Hat sich auch
bewährt.

> >> Danach sollte klar sein, mit schwierig dieser Task in etwa zu lösen
> >> ist (serverity), in welche Komponente dieser fällt (component) und ob
> >> es sich auch um ein Upstream-Problem handelt (upstream).
> > s.o. ja, das sollte nach der analyse feststehen.
> 
> Wir sollten gezwungen werden alle "new" Bugs gleich zu bewerten und es
> nicht nochmal auf eine "escalated" Liste zu setzen... Ist meiner
> Meinung nach nur ein unnötiger weitere Arbeitsschritt.

Zwingen will ich Dich nicht: Lieber das Reporting mit einer niedrigen
Eingangsschwelle machen. Du *kannst* einen neuen Bug schon bewerten und
ihn gleich auf Open setzen *musst* das aber nicht tun.
Stell Dir vor, Du hast gerade nur wenig Zeit, einen Bug einzutragen...

> >> Ein (upstream) Taks gilt dann als gelöst, wenn der jeweilige Patch es
> >> ins upstream-repository geschafft hat und voher entsprechen (positiv)
> >> kommuniziert worden ist.
> > OK, s.o., kann man über den Zustand "testing" lösen.
> 
> Dann ist owner = "upstream"... oder so.
Ich würde den Owner = Owner des upstream reports machen. Der bekommt
dann von upstream den Bericht, dass es gefixt ist (im Idealfall).

> P.s. Wenn die mail nicht über auch über die Liste ankommt, bitte weiterleiten.
Ist angekommen :-)

lG Ralf

-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  Fax:   +43/2243/26465-23
Reichergasse 131                        www:   http://www.runtux.com
A-3411 Weidling                         email: office at runtux.com
osAlliance member                       email: rsc at osalliance.com