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 zusätzlich eine neue Iteration, die einen "Sprint" darstellen soll. Dort enthaltene Issues sollten in diesem Zeitraum abgearbeitet werden, sofern das möglich ist.

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).
   
   • 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, Issues ggf. ins Review schieben 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 oder Optimization) 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: 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, Issues ggf. ins Review schieben 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.