Absprachen (Entwicklung) [Code of conduct]

IssueBoard

Einträge

Kein Editieren von Kommentaren durch andere Entwickler // 2020-10-06
Keine endlose Checkbox-Liste // 2020-10-06
Bei Problemen mit Oberflächen sollte vor dem MergeRequest der Ersteller des Eintrags die Lösung prüfen // 2012-07-12 (siehe Erkannte Probleme > Auslastung durch MR)
Sammelbugs nur für Feldtests: Aufwendigen Problemfällen, die ‚nur‘ unter realen Bedingungen wirklich geprüft werden können. // 2020-11-30 (siehe Erkannte Probleme > Feldtest)

Bearbeitung von Einträgen

Einträge (Issue) werden durch Sternanzahl priorisiert unabhängig davon, welche weiteren Markierungen (Label) er trägt // 2022-11-01
Über die Markierungen wird gesteuert, was für ein Eintrag hier gemeint ist // 2022-11-01
- Neue Funktionalität mit Einfluss auf die Oberfläche (Kunden-releveant) → Feature-Request
- Neue Funktionalität ohne Einfluss auf die Oberfläche, Umbauten in der Auslieferungsstruktur → Tech Issue / Optimization
- Umbau der alten Funktionalität auf moderne Füße → Rework / Optimization
- Fehler und Fehlverhalten → Bug
Meilensteine werden entweder zeitlich limitiert oder sind das Sammelbecken für technische / thematische Einträge. Neue Einträge werden Montags einem Meilenstein zugewiesen und werden priorisiert // 2022-11-01
Um die Schätzungen zu verbessern, soll, wenn ein Eintrag eine Zeitschätzung hat (Kommentar: /estimate <Zeit> - neuere Einträge überschreiben alte), der Entwickler die aufgewendete Zeit in das Issue schreiben (Kommentar: /spend <Zeit> - mehrere Einträge addieren sich). // 2021-01-18
Wenn die Stage Analysis fertig ist, soll eine Schätzung für den Zeitaufwand eingetragen werden. // 2021-02-15
Die Einträge werden im Montags-Meeting geschlossen, um ggf. noch Labels zu vergeben, wie 'Tested' oder 'ToBeTested' // 2021-03-12
Die Einträge, die den Test nicht bestanden haben, werden vom Tester zurück in die Stage Development geschoben. // 2022-01-31
Einträge, die mehr Aufwand als einen Tag bedeuten oder umfangreichere Umbauten mit sich ziehen ('Feature', 'Optimization'), sollen einen Reviewer zugewiesen bekommen (idealerweise am Montag, wenn der Auftrag verteilt wird (siehe Montags-Meeting 2021-07-12). // 2022-01-31
Bei der Entwicklung darauf achten, nur Dateien einzuschecken, die auch wirklich Teil der Lösung sind, um die Übersicht für den Reviewer nicht zu erschweren. // 2022-02-28
Teilerfolge nicht auf State: Review, sondern Merge-Request (Draft/WIP) // 2020-10-06
Draft/WIP-Merge-Requests werden nur dann überprüft, wenn eine namentliche Nennung erfolgt.
Mittels Drafts/WIP können aber schon mal die Pipeline getestet werden. // 2021-01-29
Merge-Requests erhalten, da sie für das Change-Log genutzt werden sollen, eine ordentlich beschreibende Überschrift und eine Beschreibung der Änderungen mit dem Link zum zugehörigen Issue. Darüberhinaus gehende Testanweisungen sollten in einen separaten Kommentar laufen. // 2023-01-16
Um den Überblick zu bewahren, schaut sich FD im Wesentlichen nur noch Meilensteine an die Feature-getrieben sind. Technische Aufgaben klärt das Team unter sich, aber Rückfragen sind jederzeit erlaubt (siehe Erkannte Probleme > Hohe Auslastung) // 2022-11-01
Es soll keine Issues mehr bearbeitet werden, ohne dass sie einem Meilenstein zugewiesen sind, eine Schätzung vorliegt und Labels vorhanden sind (siehe Erkannte Probleme > Übersicht) // 2024-02-12
~~Bearbeitungsreihenfolge der Einträge: // 2020-10-06~~
1. ~~Bugs (Sterne 3, 2, 1)~~
2. ~~Optimization (Sterne 3, 2, 1)~~
3. ~~Feature Request (Sterne 3, 2, 1)~~

Montags-Meeting:

Vorbereitung

Vorstellung von Features. Neue entwickelte Features sollen präsentiert werden. // 2021-01-29
Prüfen des Stand: (Offene Issues, Geschlossene Issues, Worum geht es in diesen Issues?, ...) // 2020-10-06
- Wenn Issue länger als 5 Tage gedauert hat: // 2020-11-02 (siehe Erkannte Probleme > Geringe-Entwickler-Performance)
  Selbstkritische Prüfung: Was hält mich von der Arbeit ab?
  Pro-Aktiver Zugang bei Problemen/ offenen Punkten; Keine ‚fast-fertig-Issues‘ liegen lassen.
  Aufteilung vorbereiten.
  - Was ist fertig?
  - Welche Punkte sind offen und wie kann man die Aufgabe zerlegen?
  - Wo lagen die Problem mit der Abarbeitung und der Einschätzung?
- Issues, die aus Sicht des Entwicklers fertig sind (finaler MR - kein Draft), werden von ihm in Review geschoben. Im Meeting wird besprochen, ob dort noch Dokumentationspflicht und Test-Möglichkeit besteht. // 2021-03-22

Durchführung

Die Issues werden besprochen und geschaut, ob Dokumentation noch nötig ist und ob ein Test durchgeführt werden kann und ggf. worden ist. // 2021-03-12
Im Montag-Meeting sollten für einen Issue nicht nur ein Bearbeiter zugewiesen werden, sondern auch ein Reviewer, der bei den Diskussionen dabei ist und als Co-Entwickler genutzt werden kann, um Fragen zu stellen und ein Review for dem MergeRequest durchzuführen // 2021-07-12 (siehe Erkannte Probleme > Auslastung durch MR)
Am Ende des Meetings werden neue Features präsentiert // 2021-01-29
Alle Issues, die To-Be-Documented-Label haben oder die ein ChangeLog-Label, müssen in dem Changelog beachtet werden.

Erkannte Probleme:

[2020-11-02]: Geringe-Entwickler-Performance: Es werden kaum Issues abgeschlossen
[2020-11-30]: Feldtest: Sammelbugs zum Testen von aufwendigen Problemfällen, die ‚nur‘ unter realen Bedingungen wirklich geprüft werden können.
[2021-07-12]: Auslastung durch MR: Die Menge der MergeRequests und die Kontrolle dieser lastet Andreas und Holger stark aus, so dass kaum produktive Arbeit getätigt werden kann. Darüber hinaus erzeugen Oberflächen-Issues häufig noch mehrere MRs, da das Ergebnis nicht den Vorstellungen des Issue-Erstellers wiederspiegeln.
[2022-11-01]: Hohe Auslastung von Frank Dühnelt. Gerade in der Saison ist es ein extrem schwere Aufgabe, den Überblick über die Einträge zu wahren, Entwickler-Anfragen und Kundenbeschwerden gerecht zu werden.
[2024-02-12]: Übersicht: Damit Frank Dühnelt die Aufgaben gegeneinander bewerten kann, soll es keine Issue geben, die keinem Meilenstein zugewiesen sind und bei den Entwicklern sollten nur wenige nicht-In-Bearbeitung-befindliche Issues liegen.