-
Notifications
You must be signed in to change notification settings - Fork 21
Projekt Management
Seit Beginn der Entwicklung beim KOBV wurde intern JIRA für die Verwaltung der Aufgaben und Releases genutzt. Zu diesem Zeitpunkt (Dez 2021) gibt es in JIRA immer noch ca. 650 offene Tickets für OPUS 4. Neue Aufgaben werden nur noch als Issues auf GitHub angelegt. Die existierenden internen Tickets werden schrittweise migriert, wenn es Anknüpfungspunkte zu aktiven Entwicklungsarbeiten gibt bzw. es wichtig ist mehr Feedback von der OPUS 4 Community einzuholen.
Migrierte Issues enthalten in der Regel einen Link zum ursprünglichen JIRA-Ticket. Das Ticket wird intern mit einem Link zum GitHub-Issue als Duplikat geschlossen.
Die Möglichkeiten des Projekt-Managements auf GitHub und ihre Nutzung entwickeln sich weiter, so dass die folgenden Ausführungen nur den bisherigen Entwicklungstand beschreiben.
Die Begriffe Issue und Ticket verwenden wir äquivalent.
Nutzer sollten Vorschläge, Anforderungen oder Probleme als Issues für das application Git-Repository melden. Dieses Repository wird auch für die Installation von OPUS 4 genutzt und stellt daher einen guten Anlaufpunkt dar.
https://github.com/OPUS4/application/issues
Die Entwickler werden Issues auch für andere OPUS 4 Git-Repositorien, wie opus4-search, anlegen, wenn die notwendigen Arbeiten in dem entsprechenden Paket ausgeführt werden müssen. Generell spricht nichts dagegen, dass Nutzer dort direkt passende Issues anlegen, aber im Zweifelsfall ist application immer der richtige Anlaufpunkt.
Projekte werden in der Regel durch Entwickler angelegt. Wenn ein Issue durch einen Nutzer angelegt wurde, könnte ein Entwickler ein entsprechendes Projekt angelegen, um die notwendigen Teilaufgaben auf weitere Issues zu verteilen und in dem Projekt zusammen zu fassen.
https://github.com/OPUS4/application/projects
Sollten für ein Vorhaben Arbeiten an mehreren OPUS 4 Komponenten notwendig sein, z.B. im framework und in der application, dann sollte ein Projekt für die gesamte OPUS 4-Organisation, angelegt werden. Diesem können dann Issues von verschiedenen Git-Repositorien zugewiesen werden.
https://github.com/orgs/OPUS4/projects?type=beta
Im Zweifelsfall wird das von den Entwicklern entschieden. Es ist kein Problem, wenn vorher schon ein Projekt für ein konkretes Git-Repository, also in der Regel für application, angelegt wurde. Issues können zu mehreren Projekten gehören.
Momentan gibt es zwei Typen von Projekten auf der Organisationsebene. Im Prinzip ist es egal welcher Typ verwendet wird. Die Beta-Projekte erlauben bisher noch keine Beschreibung des Projekts. Wir verwenden beide Typen, vor allem auch, um die neuen Projekte zu testen.
Wenn der Beta-Typ ohne Beschreibung verwendet wird, sollte es ein Issue geben, dass das Gesamtziel des Projektes beschreibt. Dieses Ticket sollte in der Regel in application liegen, um es für die OPUS 4 Community sichtbarer zu machen.
Wir verwenden Milestones, um Releases zu planen. Nur Issues, keine Projekte, können Milestones zugeordnet werden, wenn klar ist, dass sie für den Release notwendig sind. Die Milestones dienen als grobe Roadmap. Die Entscheidung, ob ein Issue zu einem Milestone gehört wird in der Regel durch einen Entwickler getroffen.
https://github.com/OPUS4/application/milestones
Da viele Arbeiten in anderen Repositories stattfinden gibt die Progress-Anzeige bei den Milestones momentan keinen guten Überblick über den Umfang der notwendigen Arbeiten. Es macht Sinn ein zusätzliches Issue in application anzulegen, auch wenn die eigentlichen Arbeiten in einer anderen Komponente stattfinden, damit die Aufgabe mit einem Milestone verknüpft werden kann und dort sichtbar ist.