Umgang mir der Veröffentlichung von Sitzungsprotokollen

Protokolle veröffentlichen, bevor sie genehmigt wurden

Wenn wir mit der Veröffentlichung bis zur nächten Sitzung warten, sind die Protokolle quasi nicht mehr relevant. Die Protokolle solange "nur" als MR auf GitLab zu haben ist halt nicht sehr weitreichend.

Deswegen sollten wir vielleicht schon vorläufige Protokolle "freigeben", damit Leute die tatsächlich sehen können. Natürlich sollte dabei immer angemerkt werden, dass es nur Entwürfe sind. Änderungen können immernoch auf der Sitzung danach eingebracht werden.

Umsetzung auf GitLab

Wie können wir veröffentlichbare Protokolle auf GitLab markieren? Der Hintergedanke ist, dass man Veröffentlichung von Protokollen auf der Website möglichst ✨ automatisieren ✨ sollte. Welche Variante praktischer umzusetzen ist, merkt man wahrscheinlich erst wenn man es versucht.

Vorschlag: Wir machen weiter wie bisher, das @fs-informatik/webteam versucht das gemütlich umzusetzen und gibt Rückmeldung. Bevorzugt ist aber Möglichkeit b).

Umsetzungsmöglichkeiten

a) Vorläufige Protokolle werden gemerget

Protokolle werden bei einer gewissen Anzahl von MR-approvals sofort gemerget. Man könnte ein approved: false in die meeting.yml einfügen, um zu markieren, dass das Protokoll noch nicht auf einer Sitzung bestätigt wurde. Nach der Bestätigung wird es dann durch ein approved: true ersetzt.

Vorteile	Nachteile
Alle "veröffentlichbaren" Protokolle sind in der main-Branch, was die ✨ Automatisierung ✨ vereinfacht. Leute die in der Repo nach Protokollen suchen, finden die vielleicht einfacher (schwaches Argument, niemand sollte das tun müssen)	Mindestens doppelt so viele MRs sind nötig (einer für das Erstellen, einer für das Genehmigen) Nach dem Mergen gibt es keine klare stelle, um Kommentare zu einem Protokoll zu schreiben

b) Vorläufige Protokolle bleiben MR, ✨ Automatisierung ✨ versucht die aus den MRs zu lesen

Eigentlich so wie bis jetzt. Interessant wird nur die Umsetzung der ✨ Automatisierung ✨, dafür ist es nötig, die GitLab-API zu nutzen.

Was ist das Kriterium für die ✨ Automatisierung ✨? Reicht ein Approve oder sollen wir ein Label dafür einführen?

Vorteile	Nachteile
Ein Protokoll ist bis zur Genehmigung ein MR, der Zustand des MRs spiegelt also den Zustand des Protokolls Es gibt eine klare stelle für Kommentare zum Protokoll (den MR) Beim übernehmen von Änderungen können Autoren die Commits im MR bearbeiten, das gibt weniger Chaos im Git-Verlauf	Komplexität für die Umsetzung der ✨ Automatisierung ✨ (Nutzung der GitLab-API, Scheduling von CI/CD ist von Approves und Labels abhängig)

Wie veröffentlichen?

Die BSc-Informatik-Liste würde ich ungerne damit "vollspammen", dann würden einige vielleicht die Liste verlassen oder wichtigeres (gibt's das überhaupt?) übersehen.

• Website (sobald möglich, Hauptmedium)
• Discord-Kanal: Nachricht mit Link zum Protokoll (ließe sich sogar ✨ automatisieren ✨)
• Eigene Mailing-Liste dafür? (geringe Notwendigkeit, vielleicht ✨ automatisiert ✨ wenn es ein geringer Aufwand ist)