|
|
# Zusammenarbeit an den Dokumenten
|
|
|
|
|
|
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
|
|
|
|
|
|
## Issues erstellen
|
|
|
|
|
|
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.
|
|
|
|
|
|
3. Jedes Issue kann mit einem Kommentar versehen werden, und hier kann auch über die Issues diskutiert werden.
|
|
|
|
|
|
## Issues bearbeiten in den Projekten
|
|
|
|
|
|
1. Bevor eine inhaltliche Anpassung gemacht werden kann, MUSS immer ein entsprechendes Issue hierfür existieren. Ohne dieses werden keine Änderungen oder Überarbeitungen vorgenommen.
|
|
|
|
|
|
2. 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.
|
|
|
|
|
|
3. 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.
|
|
|
|
|
|
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*
|
|
|
|
|
|
|
|
|
|