[VoIP] Ticket workflow

[Darshaka Pathirana]

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.

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

- milestone
- priority
- severity
- type
- component
- upstream
- owner

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

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.

ad severity)
Beschreibt unsere (also subjektive) Bewertung der Schwierigkeit des
Tasks:
- unknown
- difficult
- medium
- easy

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.

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.

ad upstream)
Ist ein boolean welches angibt ob dieser Task für upstream interessant
ist.
- yes
- no

ad owner)
Beschreibt den Verantwortlichen für diesen Task:
- Gerald
- Ralf
- Darsha

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

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

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

[4] http://trac.qutecom.org/

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.

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.

[erledigen]

Ein (nicht-upstream) Task gilt dann als "closed", wenn alle Beteiligten
(inkl. der Mobilkom) das gelöst ansehen.
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.


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.

LG,
 - Darsha