@@ -55,6 +55,7 @@ Für _Tiny Improvement Commits_ ([TICs](Regeln#tics)) gelten die folgenden Regel
...
@@ -55,6 +55,7 @@ Für _Tiny Improvement Commits_ ([TICs](Regeln#tics)) gelten die folgenden Regel
Bevorzugt wird die erste Variante, da sie klar erkennen lassen, worauf sich der entsprechende Branch bezieht. Die zweite Variante ist die, die von gitlab erzeugt wird, wenn zu einem Issue über die GUI ein Merge Request erstellt wird.
Bevorzugt wird die erste Variante, da sie klar erkennen lassen, worauf sich der entsprechende Branch bezieht. Die zweite Variante ist die, die von gitlab erzeugt wird, wenn zu einem Issue über die GUI ein Merge Request erstellt wird.
- Idealerweise sollte frühzeitig ein Merge Request erstellt werden. Solange der TIC in Entwicklung ist, sollte der Merge Request den "Draft"-Status haben, damit man schnell erfassen kann, welche TICs sich noch in Entwicklung befinden und welche bereits abgeschlossen sind.
- Idealerweise sollte frühzeitig ein Merge Request erstellt werden. Solange der TIC in Entwicklung ist, sollte der Merge Request den "Draft"-Status haben, damit man schnell erfassen kann, welche TICs sich noch in Entwicklung befinden und welche bereits abgeschlossen sind.
- Ist die Entwicklung beendet, sollten die relevanten Label für das Qualitätsmanagement am Issue gesetzt werden, damit die Qualitätsbeauftragten mit dem Review beginnen können. Das Codereview erfolgt am Merge Request und erst, wenn der Merge Request genehmigt wurde, kann das entsprechende Label am Issue geändert werden.
- Ist die Entwicklung beendet, sollten die relevanten Label für das Qualitätsmanagement am Issue gesetzt werden, damit die Qualitätsbeauftragten mit dem Review beginnen können. Das Codereview erfolgt am Merge Request und erst, wenn der Merge Request genehmigt wurde, kann das entsprechende Label am Issue geändert werden.
- Minimal benötigt der Mergerequest in einem Qualitätsreview ein **Code-Plus**, damit er gemerged werden kann. Weitere Plusse sind je nach Art der Änderung sinnvoll. Die Code-Reviewer sind angehalten, bei Bedarf festzulegen, dass andere Qualitätsbeauftragten ebenfalls ein Review durchführen sollen, falls zum beispiel neue GUI-Komponenten eingeführt werden.
- Wurde der Merge Request für den TIC akzeptiert, kann er ab diesem Zeitpunkt in das Hauptsystem (also den Branch `main`) überführt werden.
- Wurde der Merge Request für den TIC akzeptiert, kann er ab diesem Zeitpunkt in das Hauptsystem (also den Branch `main`) überführt werden.
- Das Issue kann geschlossen werden sobald der Merge Request überführt wurde.
- Das Issue kann geschlossen werden sobald der Merge Request überführt wurde.
- Werden bei den neu implementieren Funktionen des TICs Fehler entdeckt und das Issue ist bereits geschlossen, müssen diese als BIEST eingetragen. Das Issue für den TIC muss dann als "Linked Issue" eingetragen werden. Dies geschieht über die GUI, indem man in einem Issue unterhalb des Beschreibungstextes die entsprechende Funktion aufruft. Solange das Issue des TICs noch offen ist, können Fehler auch dort als Kommentar berichtet werden.
- Werden bei den neu implementieren Funktionen des TICs Fehler entdeckt und das Issue ist bereits geschlossen, müssen diese als BIEST eingetragen. Das Issue für den TIC muss dann als "Linked Issue" eingetragen werden. Dies geschieht über die GUI, indem man in einem Issue unterhalb des Beschreibungstextes die entsprechende Funktion aufruft. Solange das Issue des TICs noch offen ist, können Fehler auch dort als Kommentar berichtet werden.
