Jede_r muss sich zunächst registrieren oder anmelden. TUHH-Mitarbeitende müssen sich lediglich über ihr Kerberos-Account anmelden. Externe Mutgestaltende, müssen sich einmal registrieren.
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.
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
...
...
@@ -21,9 +21,11 @@ Für die Erweiterung im Rahmen von Hopon-Study, werden die Mitmachenden in die f
1. 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.
2.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.
2.Der Milestone ist über das Hauptmenü links oben (Sandwich-Menü) erreichbar. Nur so kommt man zu dem übergreifenden Milestone.
3. Jedes Issue kann mit einem Kommentar versehen werden, und hier kann auch über die Issues diskutiert werden.
3. 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.
4. Jedes Issue kann mit einem Kommentar versehen werden, und hier kann auch über die Issues diskutiert werden.
## Issues bearbeiten in den Projekten
...
...
@@ -36,4 +38,3 @@ Für die Erweiterung im Rahmen von Hopon-Study, werden die Mitmachenden in die f
4. 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.
5. 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**
