[VoIP] Ticket workflow

[Ralf Schlatterbeck]

On Tue, Apr 15, 2008 at 06:16:49PM +0200, Darshaka Pathirana wrote:
> Hallo!
> 
> Wie versprochen unser Vorschlag zum Ticket-Workflow!
> 
> [1] http://trac.qutecom.org/chrome/common/guide/basic-workflow.png
> [2] http://trac.qutecom.org/wiki/TracWorkflow
> 
> Wir lehnen uns bei den Stati primär am trac-workflow[1][2] an. Dieser
> sollte weitestgehend selbst erklärend sein.

Hmm. Derzeit ist mein Workflow
+--------------------+
|     +------------+ | +-------------------+
| V   V            | V V                   |
| analyzing ---+-> open ------+---+---> testing
|     |  ^     |    | ^       |   |        |
|     |  |     |    V |       |   |        |
|     |  |     +->escalated   |   |        |
|     |  +---------+ | ^      |   |        |
|     |              | |      |   |        |
|     |         +--+ V |      |   |        |
|     |         | suspended <-+   |        |
|     |         |                 |        |
|     |         V                 |        |
|     +------> closed    <--------+        |
|              |  ^                        |
+--------------+  +------------------------+

.. aber den hätte ich gern signifikant vereinfacht. Der WF ist im
prinzip konfigurierbar, möglich, dass es einige Zusatz-Checks auf
State-Namen gibt (aber diese Checks würden dann einfach nicht
triggern).

analyzing - open - testing - closed
entspricht dem Diagramm in trac mit
new - assigned - accepted - closed

- einen eigenen "reopened" gibts nicht, möglicherweise sollte man hier
  wieder nach analyzing gehen statt nach open.
- Zusätzlich gibts "suspended" steht für "won't fix now or in forseeable
  future"
- 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.

> Zu den Stati sollten für Roundup noch folgende Eigenschaften
> abgebildet werden (vor allem deswegen, damit die Übertragung zum
> Upstream-BTS[4] einfacher ist):

> ad milestone)
> Beschreibt im Wesentlichen die Version bis zu der dieser Task fertig
> gestellt werden sollte. Ob Zwischenmilestones (wie "0.4.0")
> benötigt werden bedarf noch Diskussionen. Wir sind aber der Meinung,
> dass für den Anfang ein Milestone "1.0.0" ausreicht. Siehe z.b. [3]
> 
> [3] http://trac.edgewall.org/roadmap
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.

Damit und mit dem "Effort"-Feld (und der Ressourcenzuteilung, d.h. der
Festlegung wer das Issue erledigt) kann man dann im Prinzip eine Planung
machen, da gibts eine gehackte Version von pygantt, die ein Gantt-Chart
ausspuckt.

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

> ad severity)
> Beschreibt unsere (also subjektive) Bewertung der Schwierigkeit des
> Tasks:
> - unknown
> - difficult
> - medium
> - easy
Hmm, Serverity ist in meinem Tracker die Schwere eines Bugs (aus
User-Sicht). Mit den derzeitigen Werten:
- Minor
- Major
- Showstopper
Aus der Anzahl Bugs mit bestimten Kategorien und Stati wird dann ein
Maturity index berechnet.

Für die Bewertung des Aufwands gibt es ein "Effort" Feld, in das man den
Aufwand in Personentagen eintragen kann. Würde vorschlagen, das zu
verwenden. Damit lässt sich das dann auch besser planen. Schätzen sollte
das natürlich der, der es auch implementiert. Ist wesentlich konkreter
als die obige Bewertung der Schwierigkeit.

> ad type)
> Beschreibt den Typ des Tasks.
> - bug
> - feature
> - (task)
> Ob der Task ein Bugfix oder Feature-Enhancement darstellt sollte klar
> sein. Eventuell können wir auch Tasks mit aufnehmen. Ich persönlich
> bin aber eher dagegen, da ich das System eher als Bug-Tracker sehe und
> nicht als Ticket-System. Ist natürlich auch noch subject-to-discuss.

Gibts, heisst "kind" und enthält derzeit:
- Bug
- Change-Request
- Mistaken (Reporter Error, issue wird automatisch geschlossen)
- Obsolete (Nicht mehr relevant, issue wird automatisch geschlossen)
- Support  (Nur falsche Bedienung, kein Code-Change)
- Wart (schwächer als Bug but doesn't need immediate fix)

Mit Mistaken bzw Obsolete kann man einen Bug ohne über "testing" gehen
zu müssen schliessen. Sonst braucht es einen independent tester.

> ad component)
> 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.

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.

> ad upstream)
> Ist ein boolean welches angibt ob dieser Task für upstream interessant
> ist.
> - yes
> - no
in meinem Tracker gibt es Keywords, da würde ich "Upstream" und
"possibly upstream" vorschlagen. Man kann dann immer noch danach suchen.

> ad owner)
> Beschreibt den Verantwortlichen für diesen Task:
> - Gerald
> - Ralf
> - Darsha
Jupp. Heisst "Responsible".

> 
> Soweit zu den Eigenschaften!
> 
> 
> 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.
- Es gibt *immer* einen Verantwortlichen. Der wird anhand der Category
  bestimmt. Der kann das dann weiter assignen.

> JEDER neue Task muss zusammen eingehend bewertet werden indem der
> Sourcecode überprüft und das Problem optimalerweise genau lokaliert
> wird. Pro Task sollte dafür ca. eine Stunde eingerechnet werden.
Das passiert über "Effort": Wenn der kleiner als 1 Personentag ist, ist
ein sofortiger Übergang nach "open" erlaubt. Sonst muss es über
"escalated" gehen. Ziel ist, dass kleinere Dinge, die ein Entwickler
entdeckt trotzdem über den Tracker gespielt werden, damit es
dokumentiert ist und trotzdem der Prozess nicht zu kompliziert wird.

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

> An dieser Stelle wird der Verantwortliche nach dem
> Roundrobin-Verfahren bestimmt (owner). Auch das ist natürlich
> subject-to-discuss, ich denke aber dass so eine gerechte Aufteilung
> geschehen kann.
Hängt auch noch sehr von der Erfahrung der einzelnen Leute in
verschiedenen Bereichen ab, aber da stehen wir z.Zt. wohl etwa gleich.

> Sollte es sich um einen Upstream-Task handeln sollte
> der Verantwortliche (owner) den Task in das BTS von QuteCom[4]
> einpflegen und auch dafür sorgen, dass die Community sich aktiv an dem
> Problem beteiligt (so er probleme haben sollte, den Task alleine zu
> lösen). Beim Eintragen ins Upstream-BTS[4] ist darauf zu achten, dass
> ein Querverweis von und zu unserem BTS besteht.
Gute Idee. Querverweise kann man einfach mit einem Link im Text
bewerkstelligen.

> [4] http://trac.qutecom.org/
Da ist derzeit nix drin, oder?

> ad Post-Bewertung)
> Wichtig! Damit die Community auch die Möglichkeit hat uns zu helfen,
> ist der erste Schritt nach der Bewertung uns Assignment der, alle
> Upstream-Tasks ins Upstream-BTS einzupflegen.
OK.

> Task-Tausch (unter uns) ist prinzipiell möglich sollte aber erst
> vollzogen werden, wenn die jeweils wichtigsten Task (priority 4 und 5)
> der jeweiligen Verantwortlichen gelöst worden sind.
OK.

> [erledigen]
> 
> Ein (nicht-upstream) Task gilt dann als "closed", wenn alle Beteiligten
> (inkl. der Mobilkom) das gelöst ansehen.
Dafür gibts bei mir den Zustand "testing" ohne den es nicht nach
"closed" gehen kann. Der Verantwortliche im Zustand "testing" muss von
dem im Zustand "open" verschieden sein.

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

> Um die Community ein wenig zu motivieren sich aktiv zu beteiligen
> haben wir uns folgende Möglichkeiten überlegt:
> - Einladung zu den Innovation Days
> - Bounty aussetzen
> - ... ?
> 
> Diese Möglichkeiten sollten zuerst intern diskutiert werden und von
> der Priorität des Problem abhängig gemacht werden.
> 
> Sollten noch Unklarheiten oder Fragen bestehen bitte melden. Die
> Policy sollte dann entsprechend erweitert werden.

Nach Möglichkeit würde ich nicht zuviel Policy im Tracker codieren.
"It's eaier to ask for forgiveness than permission". D.h. in Roundup
kann man immer nachvollziehen, welche Änderung von wem gemacht wurde.

vG 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