Arbeitsweise mit GitLab als Vereinsmitglied (Neuling bis Profi), "Spielifikation" von Aufgaben

Probleme:

• Verstreute Dokumentation bspw:
  • Willkommensseite im GitLab
  • Projektbeschreibungen im Wiki (nicht das GitLab-Wiki)
  • Notizen in Profilen der Benutzer
• Zurechtfinden im GitLab
• Zusammenarbeit mit anderen
• zu viele Issues ohne Thematische Hierarchie
  • keine Verschachtelung von Issues i.S.v. "Tasks" und "Subtasks" möglich
• Keine Übersicht, welche Issues am wichtigsten sind

Ideen und Umsetzung:

• konsequente Nutzung der README.md in Repositories und Gruppen
• allgemeine Informationen über Inhalt und Struktur des Repositories/der Gruppe in den Readmes dokumentieren
• tiefergehende Informationen in andere Markdown-Dateien auslagern auf die von der Readme aus verlinkt werden!
• Verlinkung von Issues in der Readme
  • Strukturierung der Issues, Priorisierung
• grundlegende Branching-Struktur für alle Projekte, egal welchen Typs festlegen
  • master-Branch auf dem getestete/überprüfte (Reviewed) und dokumentierte Beiträge freigegeben und mit einer Versionsnummer versehen werden
  • documentation-Branch auf dem sämtliche Beiträge vom testing-Branch überprüft werden ob Veränderungen dokumentationsrelevant sind und diese dokumentieren
  • testing-Branch auf dem alle Beiträge vom development-Branch getestet werden automatisch oder manuell, d.h. Automatisierte Tests entsprechend dem Entwicklungsfortschritt erstellen und anpassen und idealerweise per git-Hooks auch durchlaufen lassen
  • development-Branch auf dem "frei" entwickelt werden kann
• Repositories, welche rein zur Dokumentation gedacht sind, also nur Markdown-Dateien beinhalten können ggf. auf testing oder documentation verzichten
• strikte Arbeitsempfehlung die (Teil-)Ergebnisse der Issues in die Readme zu überführen
• um sich Stück für Stück besser zu Recht zu finden muss es möglich sein sich von Readme zu Readme zu klicken
• erstellen von "Quests" für verschiedene Mitgliedertypen ("Neuling", "Entwicklerin", "Redakteurin", ...), wie:
  • "Finde heraus wie man eine Änderung an unserer Webseite vornimmt und dokumentiere deine Erkenntnisse"
• --> Interne oder auch externe Seite mit den 10 wichtigsten aktuellen Aufgaben ("Quests") um Baustellen nach und nach abzuarbeiten
  • aktive Nutzung der Webseite um konkret für IT-Unterstützung zu werben oder Mitgliederpflege
• Nutzung von OpenProject als Frontend für Tasks und Export dieser als Commits in das betreffende Projekt-Repository (siehe dazu openproject-gitlab-integration). Eine entsprechend vorbereitete OpenProject-Instanz ist unter OpenProject (OSEG Testserver) erreichbar