Orga und Richtlinien [Deutsch] - GlancingMind/git-bug GitHub Wiki

Über dieses Dokument

Diese Dokument soll die allgemeinen Richtlinien und Festlegungen zum gemeinsamen Arbeiten an diesem Projekt (git-bug/webui) dokumentieren. Sollte es Unklarheiten oder Konflikte geben wird darum gebeten diese mitzuteilen.

Software vorraussetzungen für die Arbeit an diesem Projekt

  • Wichtig: git, Typescript, React und GitHub Account
  • evtl. GraphQL, Go

Fragen an Team

  • Bevorzugte Sprache der Kommunikation? -> Deutsch
  • Welches Betriebssystem nutzen Sie? -> Linux, Windows
  • Wenn das Resultat dieses Projektes dem upstream Repository genügt. Würden die Änderungen evtl. dort einfließen. Einverstanden? (Könnte Email und Namen von einem public machen. Daher, achte auf die in git/GitHub gewählten informationen.) -> Einverstanden, auf Email wurde hingewiesen.
  • Soll ich das Signieren von Commits voraussetzen? -> Nein.
  • Wie sind eure GitHub usernames/accounts. -> Bekannt, bis auf 1 Mitglied.
  • Welches Erfahrung haben Sie mit git?
    • commit, push, pull, rebase, branch, evtl. stash sollte ihnen was sagen.
    • Ist eine Einleitung notwendig?
  • Soll ich nochmal Git-Bug vorstellen in einer "Tele"-Konferenz?
    • Das könnte dann die TermUI, als auch die WebUI oder generelle Fragen dazu beinhalten.
    • Wenn ja, braucht ihr eine Anleitung? (Dann am besten über Tele-Konf.)
  • Wollen wir git-bug nutzen für die Bearbeitung von Issues oder GitHub-Issues?
  • Sollen Meetings und Telekonf. über Discord gehalten werden oder einer anderen Platform? Evtl. könnte bspw. BBB von der Fachschaft verwendet werden.

Generelle Information bzw. Voraussetzungen

  1. Es wird sich 1x die Woche (Donnerstags während den Blöcken von EWCSS) online zum Austausch getroffen. Der Austausch dürfte ca. 15 - 20 min. beanspruchen. Es wäre aber hilfreich 1h Zeit zu haben, falls Fragen bzw. Probleme geklärt werden sollen. Ich würde es begrüßen, wenn dies über Micro (statt schriftlich) gemacht wird. Da der Austausch dann schneller ist und Probleme leichter erklärt werden können.
  2. Wichtige Informationen sind über Discord oder dem TH-Mail-System mitzuteilen. Generell gilt, dass das TH-Mail-System der Ersatz für Discord ist. Ist also die Teilnahme an Discord technisch nicht möglich, ist der schriftliche Austausch zunächst darüber zu führen.
  3. Die wöchtenlichen Team-Meetings mit evtl. Screensharing wird sofern technisch Möglich über Discord gehalten.
  4. Spätestens alle 2 Tage mal in den Discord Channel, bzw. Postfach schauen, falls es wichtige Informationen gibt.
  5. Ist die Teilnahme an einen Meeting nicht möglich, sollte dies bei bekannt werden auf Discord, oder über das TH-Mail-System dem Team mitgeteilt werden. Das gilt auch, wenn man weiß das man eine längere Zeit nicht erreichbar sein könnte. Bspw. bei Internet Providerwechsel mit evtl. 1 Woche kein Internetzugriff.
  6. Desweiteren sollten Abwesenheitsbenachrichtigungen von den Abwesenden selbst mitgeteilt werden (sofern möglich).
  7. Organisatorisches oder anderweitige Fragen können über Discord geklärt werden. Betreffen die Fragen wichtige Informationen über die Implementierung einer Funktion, bzw. der zu erarbeitenden Aufgabe, ist der Diskurs auf GitHub zu verlagern oder die Informationen dort zu ergänzen. Dies dient dafür, dass die Entscheidungen über die Implementierungen für die Tutoren und das upstream Repository sicher dokumentiert sind.

Contribution Regeln

  1. Das Hauptrepository, wo die Issues und auch später die Pull-Request eingehen ist hier zu finden. Dies ist auch das Repository welches von allen Teammitgliedern geclont werden soll, um Konflikte mit dem upstream Repository zu vermeiden.
  2. Die bearbeitung der Aufgaben findet innerhalb des aus Punkt 1. genannten Repositories statt. Dafür wird für jedes bearbeitetes Issue ein Branch erstellen und innerhalb diesem programmiert. Der Name des Branches sollte mit der Issue ID beginnen.
  3. Die Issues sind Kategorisiert nach "Must have" und "Nice to have". Es müssen zuerst die "Must have" Issues bearbeitet werden. Diese sind auch zum Bestehen des Moduls voraussetzung.
  4. Welche Issues zuerst bearbeitet werden ist jedem selbst überlassen. Sofern Punkt 3. beachtet wird. Möchte man also eine bestimmte Aufgabe übernehmen, trägt man sich beim entsprechenden Issue als Bearbeiter ein. Es ist auch möglich gemeinsam an ein Issue zu arbeiten, dann muss sich ein Verantwortlicher für dieses Issue finden und sich dafür eintragen.
  5. Alles was zum Projekt-Repository auf GitHub beigetragen wird, ist in Englisch zu verfassen. Ausnahme bildet dieses Dokument. Achtet also darauf, dass eure Commit Messages korrektes Englisch sind. Es dürfte möglich sein, bei einen eigenen Fork andere Sprachen zu verwenden.
  6. Beachtet, die Lizenz von Git-Bug (GPLv3). Diese ist nicht immer mit anderer Software kompatibel. Solltet ihr also weitere Bibiliotheken nutzen wollen, müssen diese zur Lizenz passen.
  7. Es können im laufe der Zeit weitere Issues hinzukommen. Sollte es also weitere Verbesserungsvorschläge geben, können diese Kurz auf Discord vorgestellt und dann evtl. zur Bearbeitung auf GitHub als Issue hinzugefügt werden. Es dürfen auch Issues auf dem upstream Repository bearbeitet werden. Dann müssen wir aber darauf achten, dass dies dokumentiert wird. Daher am besten auch ein weiteres Issue anlegen.
  8. Hat man sein Issue bearbeitet wird dies am besten in Discord bekannt gegeben und auf GitHub ein Pull Request eröffnet. Es ist auch möglich ein Pull-Request schon vorher zu öffnen. In diesem Fall sollte der Titel mit "WIP:" beginnen. ACHTUNG, als Ziel des Pull Requests ist dieses Repository GlancingMind/git-bug auszuwählen!

Commit Stil

Das Upstream Repository legt keinen Commit-Stil fest. Der Übersichtshalber und zum leichteren Integrieren ins upstream Repository sind folgende Regeln zwingend zu beachten.

  1. Es gelten obige "Contribution Regeln".
  2. Desweiteren sollten diese 7 Regeln eingehalten werden. Besonders jene über Textlänge.
  3. Sind Commitnachrichten an einen bestimmtes Subsystem gebunden, sollte dieses als Prefix genannt werden. In den meisten Fällen wird dies für uns 'WebUI:' sein. Beispiele:
    • Command: Add ls command to list bugs
    • Command ls: Fix wrong encoding
    • Query: Add retrieval of labels
    • WebUI: Add Issue labeling. NOTE: Bei Unklarheiten gerne in Discord melden.