Zur Koordination der Arbeit an diesem gemeinsamen Projekt wird die Arbeit in viele kleine Arbeitspakete aufgeteilt. Die Arbeitspakete sind zu Übungszwecken erheblich kleiner als bei realen Softwareprojekten zu erwarten wäre, da die Teamarbeit der Hauptzweck des Projektes ist und nicht die schnellstmögliche oder effiziente Umsetzung des Projekts.

Die einzelnen Arbeitspakete werden in der Planungsphase mit Hilfe von GitHub:issues organisiert. Bei der Abarbeitung eines Arbeitspakets sollte darauf geachtet werden, dass die gegebene Aufgabe so präzise wie möglich umgesetzt wird und der gestellte Aufgabenrahmen nicht überschritten wird, um nicht Aufgaben eines anderen Arbeitspakets gleich mit zu erledigen.

Der GitHub Flow beschreibt den Grundgedanken von Git/GitHub, dass Arbeiten und Änderungen nie direkt auf dem main Branch erfolgen sollten. Diesem Grundgedanken möchte ich hier folgen, die genauen Arbeitsschritte sind unter "detaillierte Vorgehensweise" beschrieben.

Im Normalfall hat niemand direkte Schreibberechtigung auf dem main Branch, es muss zwingend ein pull request erstellt werden, dieser muss von 2 Personen reviewed werden (Die Anzahl von 2 Personen ist dabei erstmal willkürlich gewählt und hängt von der Anzahl der Personen ab die sich aktiv am Projekt beteiligen).

Diese Vorgehensweise ist eine Empfehlung und "Work in Progress", sie kann als Checkliste zum abarbeiten von Issues / Arbeitsaufträgen genutzt werden.

• Auswahl des Arbeitspakets
  klicken für mehr Infos:

  Eine Auflistung der zur Bearbeitung zur Verfügung stehenden Arbeitspakete / Issues findet sich z.B.
  im Project Board "Planung" unter ToDo oder
  in einer gefilterten Issue Liste

• in dem Issue zum Arbeitspaket einen Kommentar hinterlassen, dass Ihr das Issue/Arbeitspaket gerne bearbeiten wollt. Wenn Euch das Issue dann zugewiesen wurde, weiter zum nächsten Schritt.
  klicken für mehr Infos: Thema Assignees

  Bezüglich der Zuweisung von issues und pull requests wartet bitte bis Euch issues/PRs zugewiesen werden. Es ist hier technisch möglich dass Ihr Euch selbst zuweist, vermeidet dieses bitte bzw. macht das nur nach Absprache.

• Dem Issue das Label "In Bearbeitung" hinzufügen, siehe auch GitHub Hilfe zu Labels

• Einen neuen Branch erstellen, Namenskonvention: <author>-<branch-type>-<issue#>-<summary>

  klicken für mehr Infos:

  branch-type ist hier im Normalfall (für die Abarbeitung von Arbeitspaketen) "feature", weitere Möglichkeiten wären z.B. "bug" oder "testing"
  Alle Arbeiten am Code geschehen zunächst auf diesem neuen feature Branch ("feature" weil hier neue Features entwickelt werden). Der Branch sollte vorzugsweise innerhalb dieses Repositories erstellt werden, nicht in einem Fork - zwecks Übersichtlichkeit und Automatisierung). Der Name des Branches sollte sich an folgendem Schema orientieren:
  <author>-<branch-type>-<issue#>-<summary>, also z.B.
  HolgerSin-feature-11-button_einfuegen.
  Hierbei sollte summary ein kurzes und prägnantes Stichwort sein, kein langer Text.

• Einen Draft Pull Request stellen, dabei den bearbeiteten Issue verlinken,
  Namenskonvention "PR for issue #"-<issue#>-<summary>
  klicken für mehr Infos:

  Der Pull Request dient dazu, den neu geschaffene (feature) Branch später auf den main Branch zu mergen. Die Bezeichnung Draft bedeutet, dass der Pull Request und die Arbeiten am Code noch im Anfangsstadium und nicht "ready for review" sind. Der Draft Pull Request sollte bitte so früh wie möglich gestellt werden. Dadurch wird für jedermann in der Projektübersicht deutlich, dass die Arbeit tatsächlich begonnen hat.
  Tragt Euch selbst dann am besten auch als Assignee ein.
  Folgendes geschieht bei der Erstellung eines Pull Requests automatisch: Der Pull Request erhält ein Label "++Draft PR++" und er wird zum Project Board hinzugefügt (ggf. auch zu mehreren)

• Code bearbeiten und auf den feature Branch comitten. Dabei die gegebene Aufgabe so präzise wie möglich umsetzen und den gestellten Aufgabenrahmen nicht überschreiten.

• Wenn der bearbeitete Branch bereit zum Review ist, den Pull Request als "ready for review" markieren

• Andere Teammitglieder zum Review markieren - Stand 03.09.21: 4 Reviewer required, am besten alle (aktiven) Teammitglieder zum Review markieren

Damit der Gesamtprozess funktioniert, ist es nötig sich auch am Reviewprozess zu beteiligen. Der Reviewprozess dient im produktiven Einsatz insbesondere der Sicherstellung der Qualität des Codes, in unserem Repository wäre es auch eine gute Möglichkeit, die Grundkenntnisse in Javascript zu festigen indem man die Pull Requests der Kollegen reviewt. Wenn Ihr zum Review eingeladen wurdet, wäre es Begrüßenswert wenn Ihr nach Ansicht der im Code vorgenommenen Änderungen einen Review hinterlasst. Ein Review kann 3 Zustände haben:

• Approving
• Comment only
• Changes requested

Weitere Infos zum Reviewprozess bei GitHub