Seafair

Ein Wiki für das aus dem 2023er Bachelor Projekt Ai x City hervorgegangene Projekt Seafair Bremen

Dieses Wiki informiert über Kommunikationskanäle, Arbeitsweisen, Aufgaben, Ergebnis, Meilensteinen, Querverbindungen, Entwicklungstagebuch und konkrete Ziele. Wahrscheinlich wird sich die Indexpage durch stetig wachsenden Content durch gehend verändern. Das momentane Aussehen ist also work in progress.

Teilnehmerinnen

Eine Liste aller Teilnehmenden findet sich hier. Hauptansprechpatner von Dozentenseite ist für uns Gerhard. Zur Vollständigkeit noch die Kontakte zu Luca und Björn.

Kommunikationskanal

Als Kommunikationskanal ist stand heute (2023-11-23) Discord verabredet. Die Serverstruktur ist momentan noch etwas 'flach'. Hier mögliche Channel:

  • Orga Meta
    • Team
    • Projekt
  • Daily Bussiness
    • Daten
    • Hardware
    • Software
    • Betrieb
    • Kooperationen
  • Outgoing Comunication

Um unnötiges Notification Gewitter auf diversen Endgeräten zu vermeiden schlage ich vor Notifications auf @ Markierungen zu beschränken. Das kann natürlich jeder handhaben wie er will. Mit der @ Markierungen ist es dann natürlich wahrscheinlicher, dass die Nachricht von der Person gelesen wird für den diese auch relevant ist.

Außerdem sollte jeder sichergehen regelmäßig auf dem Server vorbeizuschauen. Ich denke die Eigenverantwortlichkeit sich zu informieren ist klar.

Arbeitsumgebung

Als zentrale Arbeitsumgebung nutzen wir das GitLab vom FB03. Name des Repositroy ist ai_x_city_seafair_bremen ai_x_city_seafair_bremen. Dies hat folgende Vorteile:

  • hoher Datenschutz, da Uniinterne Server.
  • alle Teilnehmenden haben Zugang
  • gutes Tool um Aufgaben zuzuteilen (Issues)
  • Pages (um dieses Wiki zu hosten, und wer weiss was noch... )
  • Sourcecode

Wir haben also alles unter einem Dach und vermeiden unnötiges Software Hopping und können uns auf Inhalte konzentrieren.

Arbeitsweise

Zufriedenheit und Fortschritt in so Projekten stehen und fallen mit guter Kommunikation und strukturierter Arbeitsweise. Damit aus diesen Buzzwords auch etwas inhaltlich greifbares wird bedarf es ein paar Formen und "Regeln".

  • Die aufkommenden Arbeitspakete im Projekt werden an konkrete Teilnehmende adressiert und wabern nicht schwerelos durch den Raum.
  • Dazu eignen sich hervorragend GitLab Issues
  • Neben der Bearbeitung der eigentlichen Aufgabe gehört auch das festhalten von Ergebnissen dazu. Gute Dokumentation ist zweifelsfrei so nervig, wie essenziell um unnötige Arbeit zu verhindern und Ergebnisse transparent zu machen. Je mehr und je genauer dokumentiert wird desto besser für alle. Keiner hat Bock drauf festzustellen, dass das Problem an dem man sich die letzten Tage abgerackert hat entweder schon von jemanden gelöst wurde oder vllt obsolet ist. Mein vorschlag ich das man die Dokumentation zu den einzelnen Issues hier im Wiki pflegt. Dazu schlage ich vor:
    • Zu jedem Issue wird ein Eintrag auf der Task Page erstellt in der die Dokumentation stattfindet. Der Eintrag hat die Form: #ID_NAME_DATE
    • Beispiel Issues finden sich auf der Task Seite und im GitLab Die Verlinkung von der Task Seite aus funktioniert noch nicht, warum auch immer

      Jour Fix

Ein Jour Fix ist eine wöchentlich fester Termin an dem wir uns (remote oder real) zusammensetzen und uns gegenseitig informieren über die letzte Woche, Arbeitsergebnisse, Schwierigkeiten oder Erfolge besprechen, die Woche planen etc. Zeitlich soll das natürlich nicht Ausufern, die Sitzungen sollten viel mehr knapp gehalten werden (15min - 30min). Hinter dem Jour Fix stehen zwei zentrale Konzepte. Neben dem Austausch und dem gegenseitig auf den Stand bringen, stärkt ein fester Termin in der Woche die Bande innerhalb des Projektes und kann verhindern, dass eine Gruppe auseinander gleitet, sich einzelne abgehängt fühlen und reduziert die Wahrscheinlichkeit das Unzufriedenheiten sich zu Problemen entwickeln.

Ich bin von dem Konzept überzeugt und würde gerne so einen Jour Fix für Seafair einführen. Eventuell bietet sich der Mittwoch dafür an. Ich würde Protokoll über die Sitzungen führen.

über dieses Wiki

Wie oben schon beschrieben, soll dieses Wiki als zentraler knowledge space für Seafair dienen. Warum ein Wiki? Nach meiner Erfahrung, hat sich das hierarchielose, verlinkungsbasierte organisieren von Notizen als sehr praktisch herausgestellt (siehe Zettelkasten).

Das Wiki wird mittels GitLabPages und ikiwiki (aus der Seite scheint es wohl einen CSS Fehler zu geben, lol) auf dem Uni-Gitlab Server gehostet. Der Content im Wiki ist in einzelnen Markdown Dateien organisiert (an dieser Stelle Achtung, die Dateiendung muss zwingend .mdwn sein, und nicht etwa .md)

Warum ist das eine gute Sache? Hier ein paar Gründe:
  • die Meisten werden schon mal mit Markdown in Berührung gekommen sein.
  • Markdown ist Plain Text jeder kann seinen lieblings Editor benutzen man braucht keine zusätzliche Software.
  • Der Nutzung der ist nicht auf das Wiki beschränkt.
  • Wir haben alle Vorteile der Versionierung von GitLab
  • falls nötig lassen sich die Daten schnell auf ein anderes System migrieren
  • der Content lässt sich schnell und problemlos pushen und damit veröffentlichen
Wie genau füge ich dem Wiki Content hinzu?

Der Inhalt des Wikis liegt im Verzeichnis content. Die entsprechenden Seiten des Wikis sind die einzelne Markdown Dateien. Diese Seite ist sowas wie die Wurzel und basiert auf der Datei index.mdwn.

Will man dem Wiki nun eine Seite hinzufügen erstellt mein einen neue Datei, zB. newWikiSite.mdwn und befüllt diese mit Inhalt. Um auf diese zu verlinken erstellt man auf einer belibigen andern Seite einen wiki_link. Ich benutze zB. immer diese Syntax : [text_fuer_verlinkung](newWikiSite)

Wie mache ich meine Änderungen auf der Webseite sichtbar?

Durch ganz normales pushen ins Repository. Mit git add die entsprechenden Datein hinzufügen, mit git commit die Änderugen commiten und dann mit git push diese pushen. Durch das pushen wir in GitLab eine CI/CD Pipeline gestartet, wenn diese druchgelaufen ist (ca 30 sek.) sollten die Änderungen sichbar sein