foss-ag / orga_guidelines

Guidelines für die Strukturen innerhalb der FOSS-AG und Nutzung verschiedener Dienste.

FOSS-AG Guidelines

• Format Protokoll/Sitzungen

• Guidelines FOSS-AG

• Guidelines Matrix Chaträume

• Guidelines GitHub/Gitea/Nextcloud

orga_guidelines's Issues

Vorschlag: Kalender, in dem unsere Treffen eingetragen sind, zur Fachschaft migrieren

Mein Zwischenvorschlag: den Kalender, in dem unsere Treffen eingetragen sind, können wir zur Fachschaft migrieren. Die Daten, die privat sind, können wir dann weiter selbst verwalten.

Originally posted by @fes0j in #45 (comment)

Rechte von „aktiven Mitgliedern“

Die Rechte von „aktiven Mitgliedern“ sind momentan wie folgt definiert:

Ist Member in der GitHub-Organisation. (kann also insbesondere neue Repos erzeugen)

Bekommt Zugriff auf weitere Dienste der FOSS-AG.

Wird Mitgliedschaft im Orga-Chat angeboten.

Wollen wir dies irgendwie ändern?

Blocked by #37 #38

Zweiwöchige Orga

Falls wir uns dauerhaft auf einen Wechsel zwischen Orga und Nicht-Orga für die Treffen entscheiden, sollten wir dies hier notieren.

Auch jeder nicht-Member kann ein vollwertiger Contributer sein

Wir machen uns teilweise Sorgen, dass Leute nicht vernünftig daran arbeiten können weil PRs nutzen müssen. Das stimmt aber nicht. Jeder kann vom Repo-Admin zu einem vollwertigen Contributer gemacht werden, selbst externe. Dann kann man ganz normal mergen.

Evtl. könnte man das irgendwie auch mit in den Text packen. :-)

Gitea Nutzung für nicht-aktive

Hallo zusammen,

es ist mir auch aufgefallen, dass es eigentlich dämlich ist, wenn Leute das Gitea nicht nutzen können für private Projekte. Finde ich nicht unbedingt sehr FOSSig so zu denken. o.o

Da der Server ja bei der Fachschaft steht und nicht mehr auf meinen Namen läuft, ist das rechtlich auch viel entspannter. Mein Vorschlag wäre also: Gitea offen für jeden der min. einmal bei einer Sitzung war? :)

Nextcloud zur Fachschaft migrieren

Wir haben überlegt, die NC aufzulösen und stattdessen die NC der Fachschaft zu nutzen.
Dafür spricht, dass wir leine Dopplung der Infra habe und diese nicht selbst Maintainen müssen.

Ich sehe allerdings auch Probleme: Die Admins müssten uns explizit cloud.foss-ag.de mit in die NC-Domains Eintragen. Wenn nicht, dann hätten wir nur HTTP-Weiterleitungen - wenn man selbst Resourcen Teilt, hätten die dann den 'falschen' Link.

Dazu kommt, dass Fachschafts-Accounts notwendig sind. Wir haben aktuell beide Admins in der FOSS-AG und die sind auch super toll, aber wir sind trotzdem abhängig von Ihnen die Accounts anzulegen. Und bekommt dann wirklich jeder der möchte einen Account? So sehen unsere Guidelines das aktuell vor.

Ich bin super froh, dass die Fachschaft existiert und David als Admin rockt… aber generell empfinde ich es als besser ein wenig Unabhängigkeit zu bewahren. Die Uni als solche hat uns bis jetzt wenig unterstützt. Mir wäre es lieber, wenn wir unabhängiger bleiben (was vor allem die öffentlichen Dinge angeht).

Wäre gegen eine Migration.

FOSS-AG Dortmund Matrix Raum auf neuen v6 Raum migrieren.

Hier sollen alle offene Punkte gesammelt werden die wir geklärt/gelöst haben wollen, um den Raum auf Matrix Raum v6 zu migrieren.

Ebenfalls wollen wir hier Erfahrungen sammeln.

Ein Upgrade funktioniert mittels eine Tombstones mit einem Link zur neuen Raumversion.

Version 2 erstellen

Hallo zusammen,

dieses Issue wird am Mittwoch, den 29.11.2017 ggn. 20 Uhr geschlossen und Version 2 der Guidelines released. Mit dem Release werden die Guidelines auf das GitHub und neue Kanäle angewandt.

Bis zu diesem Zeitpunkt können noch Issues eröffnet und diskutiert werden, die nachfolgenden generieren Version 3.

Issues erst schließen, wenn es eine Mehrheit gibt oder es umgesetzt wurde

Ich rege hiermit an einen Issue erst zu schließen, wenn wir einen Beschluss gefasst haben.
Sollte es einen Gleichstand geben wie in Issue #45 gesehen, sollte er meiner Meinung nach offen bleiben, da das Problem offensichtlich nicht gelößt wurde.
Also Issues sollten geschlossen werden, wenn sie obsolet sind.
Dazu gehört es, wenn eine Entscheidung gefällt wurde (durch eine Mehrheit) oder die Maßnahme umgesetzt wurde.
Falls dann neue Zweifel aufkommen, kann ja trotzdem weiterdiskutiert werden. Dies sollte natürlich nur mit neuen Argumenten geschehen und nicht um die eigene Meinung durchzudrücken.

Diskussion - GitHub Owner

• Struktur für GitHub (Draft):
  • Siehe auch Guidlines FOSS-AG.
  • Alternative 1: Es gibt einen Owner-Account der keine natürlichen Person direkt zugeordnet ist. 3 Personen die darauf Zugriff haben (oder mit geteilter 2FA).
  • Alternative 2: Es gib 3 Owner.
    • Owner halten sich an die Konventionen der Teams (z.B. Commits per PR)

Ich persönlich würde die Variante mit 3 natürlichen Accounts als Owner der Orga bevorzugen.
Als ursprüngliche Personen für diese Rollen schlage ich @dragetd @ThiefOfTime und @Lazalatin vor. Über spätere Änderungen dieser Rollenzuweisungen sollte auch mal gesprochen werden, aber nicht unbedingt zu diesem Zeitpunkt.

So far
~laz

Lizenz: Non Commercial und Open Source

Mir ist gerade aufgefallen, dass der Non-Commercial Teil der CC-Lizenz die wir aktuell nutzen dem Open Source Gedanken widerspricht. Deshalb wird die NC-Lizenz auch von folgenden Stellen nicht empfohlen:

• https://choosealicense.com/non-software/
• https://www.oshwa.org/2014/05/21/cc-oshw/

Auch https://creativecommons.org/licenses/?lang=de nennt die BY-SA Lizenz als Entsprechung für „normale“ Open Source Lizenzen.

Ich schlage daher vor, die Lizenz auf CC-BY-SA 4.0 zu ändern. Hat den netten Vorteil, dass GitHub sie kennt und oben im Repo anzeigt (https://help.github.com/articles/licensing-a-repository/)

Format der Lizenz - so viel Freizeilen nötig?

In der LICENSE sind sehr viele Freizeilen, selbst zwischen Aufzählungspunkten. Muss das so? :-P

Bezeichnung von „aktiven Mitgliedern“

Wollen wir die Bezeichnung „aktives Mitglied“ ändern?

Vorschläge sind z.B.: stimmberechtigtes Mitglied, Jünger, Genosse

Blocked by #37

Weniger Sitzungen

Es gibt einige, die sich mehr Zeit in Gruppen wünschen und weniger Orgadiskussion bzw. im ganzen Sitzungen in dem Sinne.

Guidelines für AG Treffen.

Mit zunehmender Beteiligung haben wir auch unsere Treffen immer mehr strukturiert.

Vielleicht ist es sinnvoll Ideen aus der Sitzung Nr. 72 und aktuelle Abläufe aufzuschreiben.

Bisher wurde in Organisations- (orga) und Stammtischthemen unterschieden. Zusätzlich wollen wir eine Phase für "Hackgruppen" (oder ein anderer Name?) einführen, in der dann spezielle Diskussionen oder konkrete Arbeit und Absprache für laufende Projekte stattfinden.

Timeboxing von Orga-Themen

Pro Thema auf der Themenliste gibt es 10min mit Timer. Verlängerung um weitere 10min nur, wenn alle zustimmen.

Wenn nicht, wird vertagt. RFC!

Notwendige Bedingungen für „aktive Mitglieder“

Aktuell ist Bedingung um „aktives Mitglied“ zu werden das Folgende:

Beteiligt oder Beteiligte sich in den letzten Monaten aktiv an min. einem Projekt und nimmt regelmäßig an Sitzungen teil.

Wollen wir das in irgendeiner Weise ändern?

Dokumentation "Handzeichen"

In der Datei meetings.md wird die Benutzung von Handzeichen bei größeren Gruppen erwähnt:

Bei größeren Runden: Handzeichen nutzen!

Möchten wir die Handzeichen, die wir bei Treffen verwenden mal offiziel irgendwo (z.B. direkt in diesem Repo) festhalten?

Wir benutzen ja ein paar 'akzeptierte Standardzeichen,' die andere Gruppen auch nutzen . Aber mittlerweile haben wir ja zusätzlich einige eigene. :3

Ich würde mich auch erklären, hierfür, zusammen mit dem @foss-ag/graphics team, ein paar Zeichnungen oder gar Animationen anzufertigen — wenn wir wirklich so fancy sein möchten.

Einfachere Lösungen, wie Zeichnungen oder Fotos für die Handzeichen von "lizenzfreien" Bildquellen zu organisieren, sind aber natürlich auch okay. Vielleicht auch erst einmal besser, damit wir schonmal etwas dafür dokumentiert haben.

Definition von "aktiven Mitgliedern" oder "Mitgliedern" im Allgemeinen

Wie schon in der Sitzung besprochen, kann jetzt hier über aktive Mitglieder bzw. Mitglieder im Allgemeinen diskutiert werden.

Meine Meinung folgt auch noch...

Creation of a seperate file concerning the "sponsoring guidelines"

As discussed at the FOSS-AG meeting on 2017-11-30, it may be required to create a seperate guideline file regarding the general opinion on sponsoring of AG projects or the AG itself by, possibly non-FOSS, companies.

Issues Deutsch oder Englisch? Hmm, hier noch mal auf Deutsch:

Wie wir bereits bei der Sitzung am 30.11.2017 diskutiert haben, wäre es möglicherweise vonnöten, eine weitere Datei anzulegen und somit Guidelines für das Sponsoring von AG Projekten oder der AG selber aufzustellen.

Öffentlich Kalender

Wir haben letzte Sitzung festgestellt, dass unser Kalender nicht von jedem einsehbar ist. Da wir keine geheimen(?) Termine haben, sollte man den öffentlich machen.

Branch request

Erstelle separate Branches für jedes File in /doc. Somit können Änderungen für einzelne Dateien besser verfolgt werden.

FOSS-AG Dortmund Matrix Raum auf neuen E2E Raum migrieren.

Vorsclag:
Der #foss_ag:matrix.org/fachschaften (FOSS-AG Dortmund) Raum bekommt einen neuen Namen/Alias mit einem '_legacy' Suffix. Er bleibt vorerst bestehen. Wir erstellen einen neuen Raum mit dem alten Namen/Alias. Die selben Leute bekommen die selben Rechte. Dafür wird der Raum aber E2E Crypto aktiviert. Der alte Raum bekommt eine Info, wird aber noch min. 3-6 Monate weiter betrieben, bevor er den Tombstone bekommt.

Hintergrund: Ich bin davon überzeugt, dass die Usability von Matrix mit E2E sehr schlecht war, als das wir das hätten früher machen können. Es war richtig, das noch nicht genutzt zu haben.

Aber ich habe auch das Prinzip 'Encrypt everything'. Und Element ist weit gekommen. Ich wäre es bereit, es auszuprobieren. Wir würden auch viele der 'Leichen' in unserem Raum los werden.

v3 Release

Gibt es noch irgendwo Bedenken? Bitte äußern! Ich würde gerne vor nächster Sitzung dann einmal das v3 Release schnüren. :)

Notwendigkeit der Rolle des "aktiven Mitgliedes"

Nach der Öffnung des Orga Kanales hat die Rolle des aktiven Mitgliedes seine Relevanz verloren. Die Einzigen Verantwortungen, die ein "aktives" Mitglied noch hat, sind ein Veto-Recht (kein Mitbestimmungsrecht). Das Mitbestimmungsrecht gab es so nur in der Kombination mit der Orga Gruppe. Durch Öffnen dieser, haben alle, die Mitglied der Orga Gruppe sind, dort auch ein Stimmrecht. Da der Private Kanal nur für Private Dinge gedacht ist, wie Bilder o.ä., kann eine Person nur in diese Gruppe eingeladen werden, wenn alle damit einverstanden sind, da es sich um persönliche Daten handelt. Dies ist weder ein Privileg noch eine explizite Verantwortung. Eine Einladung in diese Gruppe mit dem aktiven Mitglied zu verbinden geht meiner Ansicht nach an dem Sinn der privaten Gruppe vorbei und führt uns nur wieder an die Anfangsproblematik.
Bleibt das Veto-Recht. Für dieses Person lässt sich immernoch eine Bezeichnung finden. Das einfachste ist, dass die Personen, die in einem Channel ein Veto recht haben, die sind, die diesen Channel Maintainen, so wie in jedem Channel. Meiner Ansicht nach ist die Rolle des aktiven Mitgliedes überflüssig und ich möche darüber abstimmen ob diese Rolle weiterhin verwendet/angepasst werden soll.

GitHub Teams sollten auch nicht-Member einladen können

Okay … das hier war das konkrete Problem, welches ich mit den aktuellen Regelungen habe und am Donnerstag in der Sitzung äußerte.

Es muss sich wirklich nur eine Sache ändern, finde ich … nämlich, das Maintainer von GitHub Teams auch GitHub Nutzer einladen können, die eben nicht in unserer FOSS-AG Organisation sind.

Das würde auch nichts an unserer "Qualitätskontrolle" / "Ist das FOSS-AG relevant und approved?" Frage kaputt machen. Es muss ja noch immer ein GitHub-Organisationsmitglied das Team erstellen. Das Recht, Repos und Teams im Namen der FOSS-AG zu erstellen, sollte nach wie vor bei aktiven Mitgliedern bleiben.

Was aber meiner Meinung nach auf jeden Fall für die produktive Nutzung unserer Präsens auf GitHub geändert werden sollte, ist, wie oben gesagt, dass sobald ein Team von einem Mitglied erstellt ist, dieses Mitglied auch eben Menschen einladen kann, die nicht in der GitHub-Organisation sind.

Das ist wichtig, weil die GitHub Teams Funktion sonst nur sehr eingeschränkt von uns nützlich verwendet wird.

Es gibt halt Projekte, wo es Sinn ergibt, mehr Rechte auf einmal, auf mehrere Menschen zu erteilen, als nur PRs. Und das auch gleichzeitig über mehr als ein Repo. Für solche Fälle ist es nicht sinnvoll, GitHub-Team-Mitglieder meiner Meinung nach ar­bi­t­rär auf GitHub-Organisations-Member zu beschränken.

Diese Möglichkeit sollte Maintainern offen bleiben.

Umstruktirierung der Matrix-Kanäle

Hallo zusammen,

ich wollte mal hier einen Vorschlag zur Neustrukturierung unserer Matrix-Kanäle unterbreiten, damit dieser schon vor Donnerstag ein wenig diskutiert werden kann.

Im Moment sagen unsere Guidelines, dass der Orga-Kanal nur für Aktive ist.
Wir müssten eigentlich viel mehr Leute als Aktive aufnehmen, da wir ansonsten Leute ausschließen, die nicht im Kanal sind und evtl. etwas von der Planung mitbekommen wollen. Gleichzeitig wollen wir auch interne Dinge privat besprechen können die nur Leute betreffen, die auch wirklich aktiv die Aktionen machen.
Damit einher geht ja auch z.B. NextCloud Zugriff, was datenschutzrechtlich relevant ist. IMHO: Mit sehr vielen Leuten erhöht sich die Wahrscheinlichkeit von Problemen und verringert sich die Produktivität.

Folgender Vorschlag:

Geschlossene Kanäle (für private Dinge)

• 'FOSS-AG Privat' (Umbenennung von 'FOSS-AG Orga' oder Neuerstellung)

Offene Kanäle (für jeden):

• FOSS-AG Dortmund (Bleibt)
• FOSS-AG Organisation (neu erstellt)

Die Semantik des 'Aktive' Kanal wäre die vom aktuellen 'Orga' Kanal: Private Themen, datenschutzrechtliche Inhalte oder sonstige interne Themen die nicht direkt öffentlich sein sollen.

RFC! :-)