Zusammenarbeit an den Dokumenten
Überblick über die Projekte
Die Zusammenarbeit an den Dokumenten findet in den einzelnen Projekten statt. Sämtliche Projekte sind öffentlich einsehbar. Wer mitmachen möchte, nimmt z.B. Kontakt zum Hop-on-Team auf: https://hopon-newcomers.com/de/contact/ und kann dann als Developer an den Inhalten mitarbeiten.
Eine Übersicht über alle Hopon-Projekte findet sich hier: https://collaborating.tuhh.de/itbh/hopon-fahrplan/wikis/uebersicht-hopon-projekte
Registrierung / Anmeldung
Jede_r muss sich zunächst registrieren oder anmelden. TUHH-Mitarbeitende müssen sich lediglich über ihr Kerberos-Account anmelden. Externe Mitgestaltende, müssen sich einmal registrieren.
Sollte jemand nicht seinen Klarnamen nutzen, dann benötigt das Hop-on-Team einmal den Benutzernamen, um die Mitgestaltenden in die jeweiligen Projekte aufzunehmen. Grundsätzlich muss dem Hopon-Team einmal mitgeteilt werden, dass man sich registriert hat. Deshalb also kurz eine Mail schreiben, oder um Access bei den Projekten selber bitten.
Für die Erweiterung im Rahmen von Hopon-Study, werden die Mitmachenden in die folgenden Projekte als Developer aufgenommen:
- Hopon-Fahrplan
- Hopon-Ergebnisse
- Hopon-Studybuch
- Hopon-Studyleitfaden
Issues erstellen
-
Zunächst werden ToDos als Issues in dem jeweiligen Projekt angelegt und mit dem Milestone [Hopon]Backlog versehen. Dieser Milestone sammelt alle offenen Issues in sämtlichen Hopon-Projekten.
-
Der Milestone ist über das Hauptmenü links oben (Sandwich-Menü) erreichbar. Nur so kommt man zu dem übergreifenden Milestone.
-
Wir arbeiten immer in einem zwei-Wochen-Rythmus, dem sogenannten Sprint-Planning. Jeder Sprint bekommt realistisch für diesen Zeitraum abzuarbeitenden Issues. Nach den Zwei Wochen werden wiederum neue Issues aus dem [Hopon]Backlog für den nächsten Sprint im Team ausgehandelt.
-
Jedes Issue kann mit einem Kommentar versehen werden, und hier kann auch über die Issues diskutiert werden.
Issues bearbeiten in den Projekten
-
Bevor eine inhaltliche Anpassung gemacht werden kann, MUSS immer ein entsprechendes Issue hierfür existieren. Ohne dieses werden keine Änderungen oder Überarbeitungen vorgenommen.
-
Ein Issue wird wie gesagt immer in dem jeweiligen Projekt erstellt, erhält den Milestone [Hopon]Backlog wenn es erst einmal gesammelt wird, oder den Milestone des aktuellen Sprints.
-
Wenn ein Issue existiert, kann in das jeweiligen Issue hineingegangen werden. Hier findet sich dann die Option New Branch. Ein Branch ist eine 1:1 Kopie des aktuellen Standes des Projektes, dem sogenannten Master. In diesem Branch können alle Änderungen vorgenommen werden und mit entsprechenden Commit messages versehen werden. Damit wird deutlich, was man hier geändert hat.
-
Hat man ein Issue abgearbeitet, stellt man einen Merge request. Das bedeutet, man bietet seine Änderungen einer konkreten Person mit Masterrechten an, um sie in den Master und damit in die Produktivumgebung aufzunehmen.
-
Während des Prozesses kann man sich den Stand der Änderungen in einer Art "Simulationsumgebung" anschauen. Hierfür sind die sogenannten Review Apps gedacht. Diese finden sich in den Projekten jeweils unter Pipelines --> Environments --> reviews