Montags-Meeting

Das Montags-Meeting dient der Absprache, Einteilung und ggf. Zuweisung von neu erstellten Git-Issues und der generellen Planung der Woche. Alle 2 Wochen beginnt eine neue Iteration, die einen "Sprint" darstellen soll. Dort enthaltene Issues sollten in diesem Zeitraum abgearbeitet werden, sofern das möglich ist.

Vorbereitung

Die Vorbereitung auf das Montags-Meeting sollte von jeder Person einzeln durchgeführt werden. Nur wenn jede Person sich damit beschäftigt, können wir die Dauer des Meetings reduzieren.

1. Überlegen, ob generelle Themen angesprochen werden müssen, die unabhängig vom Gitlab relevant sind.
2. Anschauen der selbst erstellten Issues in den letzten 7 Tagen. Es sollte darauffolgend eine kurze Erklärung möglich sein.
3. Überblick über das eigene Issue board verschaffen.
   • Die Issues sollten selbständig zwischen den Phasen: Open, Analysis, Development und Review verschoben werden, sodass sich ein grober Überblick über die potenzielle Auslast verschafft werden kann.
   • Review: Welche Issues können geschlossen werden und benötigen ggf. neue labels wie z.B. To Be Tested oder To Be Documented.
   • Development: Kurzen Überblick über den Entwicklungsstand verschaffen, Issues ggf. ins Review schieben und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?

Vorgehensweise

1. Ansprechen von generellen Themen, die unabhängig vom Gitlab erwähnt werden sollten.
2. Iteration über das Issue board anschauen und besprechen (Raindancer Gruppe).
   • Issue board mit Iteration=Current. 
   • Review: Welche Issues können geschlossen werden und benötigen ggf. neue labels wie z.B. To Be Tested oder To Be Documented.
   • Development: Kurzen Überblick über den Entwicklungsstand und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?
3. Betrachten aller neuen Issues, die in den letzten 7 Tagen in der Raindancer Gruppe erstellt wurden. Zur Zeit sind hier nur Issues aus dem Server-Projekt relevant.
   • Assignee=None, Milestone=None und Epic=None mit absteigender Sortierung nach Created Date.
   • Jedes Issue muss dabei ein label (Bug, Feature Request, Optimization, Tech Issue oder Rework) und eine Priorisierung durch Sterne erhalten. Zusätzlich muss ein Milestone hinterlegt werden.
   • Sofern es möglich ist, sollten Zeitangaben als estimates für die Fertigstellung angegeben werden. Ist das nicht ohne eine Analyse möglich, so bezieht sich die Zeitangabe auf die erste Analyse. Nach der Analyse soll die Zeitangabe angepasst werden.
   • Optional: Es können weitere labels wie z.B. Quick vergeben werden.
   • Optional: Hat das Issue einen assignee erhalten, so kann es einer Iteration zugewiesen werden, sofern die jeweilige Person noch ausreichend Platz hat.
   • Wichtig: Ist es nicht möglich, das Issue aufgrund von fehlenden Personen zu erklären oder zu bewerten, so muss das Issue ein Due Date erhalten.
4. Überprüfen von offenen Issues, die aufgrund von fehlenden Person ein Due Date erhalten haben (Derzeit nur Server-Projekt der Raindancer Gruppe).
   
   • Assignee=None, Milestone=None und Epic=None mit absteigender Sortierung nach Due Date.
   • Bearbeitung erfolgt analog zum vorherigen Schritt.
5. Anschauen der Issue boards innerhalb der Raindancer Gruppe.
   • Es müssen die Boards von allen relevanten Personen geöffnet werden. Person sind nicht relevant, wenn diese nicht anwesend sind oder einer externen Firma angehören.
   • Review: Welche Issues können geschlossen werden und benötigen ggf. neue labels wie z.B. To Be Tested oder To Be Documented.
   • Development: Kurzen Überblick über den Entwicklungsstand und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?
   • Open: Sortieren der Issues, sodass bei Bedarf neue Issues ohne Rückfragen genommen werden können.