Project-Board/Milestones/Tags/Labels

[AMatutat]

Für die Übersicht im Projekt sollten wir die verschiedenen GitHub Features nutzen.

Project-Board
Auf dem Board werden automatisch alle Issues und PRs angezeigt. Dort lässt sich auch der aktuelle Status ablesen.
Wichtig ist nur, dass die jeweiligen Issues/PRs auch dem Board hinzugefügt werden.

Unser aktuelles Board:
https://github.com/orgs/Programmiermethoden/projects/9

Tags
Tags sind Anhängsel vor den Ticket-Namen (siehe PM-Dungeon).
Im Framework haben wir die genutzt, um festzulegen auf welchen Bereich sich die Tickets beziehen.
Wir sollten uns passende Tags überlegen.
Die Tags können in GitHub hinterlegt werden und beim anlegen eines Issues genutzt werden.

Labels
Sollte bekannt sein.
Anzumerken ist, dass man im Board super nach Label filtern kann.
Brauchen wir noch weitere Label?

Milestones

Wir nutzen wir die am besten?

Vorschlag:
Nicht das ganze Projekt schon in Milestones aufteilen, sondern immer nur so 4-6 Wochen im Voraus Planen und daraus 2-3 Milestones machen.

Frage: Gibt es auch Repo übergreifende Milestones in GitHub?

[malt-r]

Das Projekt lässt sich ja ganz grob in 3 funktionale Bereiche unterteilen: "Backend" (alles was mit dem PMDungeon zu tun hat), "Frontend" (die Funktionen & Klassen, gegen die der DSL-Interpreter entwickelt wird) und alles was mit der DSL zu tun hat (Parser, Interpreter, etc.). Daneben gibt es dann sicherlich noch so übergreifende Kategorien wie Toolchain und Doku. Ich habe gesehen, dass im PMDungeon sowohl funktionale Komponenten (z.B. Controller), als auch übergreifende Kategorien (z.B. Dokumentation) als Tags verwendet werden. Ich finde das etwas unübersichtlich und nicht so gut getrennt. Da geht dann nicht so schnell hervor, auf welchen funktionalen Bereich sich bspw. ein mit [DOKUMENTATION] gekennzeichnetes Ticket bezieht. Ich würde vorschlagen, dass wir das klarer trennen und bspw. den Tag [BACKEND] (oder gerne auch feingranularer) für die funktionale Komponenten und als Label dann "Documentation" verwenden. Dann ist ein Ticket immer klar einer Komponente zugewiesen und über die Labels kann genauer angegeben werden, welche Tätigkeit mit dem Ticket verbunden sein soll. Ob das in allen Fällen gut so funktioniert kann ich allerdings nicht absehen, das wäre nur mein erster Vorschlag.

[cagix]

Das wäre dann eher ein Punkt für Labels, da können mehrere einem Ticket/PR zugeordnet werden.

Andererseits landen nachher im git log nur noch die Tags, die Label sieht man dann nur noch im Github.

[AMatutat]

Eben besprochen:
Tags:
[GAME]
[DSL]

Labels:

• wie bisher

Milestones:

• Roadmap mit großen Zielen im WIki
• Milestones als "erweiterte" Sprint-Planung 2-4 Wochen.

[malt-r]

Ergänzung zu Labels: Kennzeichnung für SHK-Arbeitsaufträge mit SHK Label

[malt-r]

Discussion zur Roadmap: #29