Demokratisches Gremium für nicht-technische Entscheidungen: Freifunk Community Directory Council

[christian-weiss]

Freifunk liebt Dezentralität, trotzdem haben wir einige zentralisierte Dienste. Das Freifunk Community Directory ist eines dieser zentralisierten Dienste.

Das Freifunk Community Directory Team möchte nur technischer Dienstleister sein - Entscheidungen, ob z.B. ein Community Eintrag gelöscht wird (z.B. prüfen, ob eine Community der Freifunk Vision und dem Freifunk Memorandum of Understanding folgt), möchten dieses Team nicht treffen. Es will Beschlüsse nur technisch umsetzen.

Da es derzeit kein Gremium in der Freifunk Initiative gibt, dass sich für Entscheidungen bzgl. des Freifunk Community Directory zuständig fühlt, muß ein solches Gremium gegründet werden.

Das Freifunk Community Council ist leider nie vollständig mit Repräsentanten aus allen Bundesländern besetzt worden und scheint seit 2016 nicht mehr nennenswert aktiv zu sein. Zudem ist fraglich, ob eine Abstraktion mit 1-2 Repräsentanten je Bundesland geeignet ist. Jeder Freifunk Community eine Stimme zu geben wäre näher an unserem Autakiegedanken.

Aus diesem Grund wird jetzt das Freifunk Community Directory Council (FreifunkCDC) gegründet, welches ausschließlich für Entscheidungen mit Bezug zum Freifunk Community Directory zuständig ist. Es besteht aus allen aktuell im Freifunk Community Directory gelisteten Freifunk Communities. Jede Community (jeder Freifunk Community Directory Eintrag) hat exakt eine Stimme. Metacommunities haben keine Stimme, den sie sind über die Einträge der API-Dateien entsprechend oft vertreten. Freifunk Communities die bisher nicht gelistet sind können durch einen PR ohne Vorabprüfung (nur technische Qualität muss stimmen) in das Freifunk Community Directory und somit in das FreifunkCDC aufgenommen werden. Damit ist keine Freifunk Community ausgeschlossen. Keine Freifunk Community ist zur aktiven Beteiligung verpflichtet, weder an der Diskussion noch an den Abstimmungen.

Eine Plattform auf der alle Freifunk Communies vertreten und aktiv sind gibt es derzeit leider nicht - selbst das Freifunk Forum deckt nicht alle Ansprechpartner ab. Da jede Community in das Github Repo eingetragen wurde, wird Github zunächst die Plattform für Diskussion und Abstimmung des FreifunkCDC - bis das Freifunk CDC sich selbst eine andere Platform wählt.

Da man nie weiß wie viele Communities sich am FreifunkCDC beteiligen werden, gilt das FreifunkCDC mit verstreichen des 30.04.2020 als beschlussfähig. Zunächst mit einfacher Mehrheit, egal wie viele Personen sich bis dahin gemeldet haben. Mit weniger als 3 Personen gilt der Freifunk CDC als nicht beschlussfähig, die Frist verlängert sich bis mind. 3 Personen gefunden wurden.

Langfristige Aufgaben des FreifunkCDC:

• Entscheiden, ob ein Eintrag aus dem Freifunk Community Directory gelöscht werden soll, wenn es zwar den technischen Qualitätskriterien entspricht aber andere Gründe gegen eine Listung sprechen.
• (gerne weitere Aufgaben vorschlagen)

Erstes Arbeitspaket des FreifunkCDC:

• Wie soll der Einscheidungsprozess /-modus aussehen (Ablauf: Diskussion+Abstimmung aufeinanderfolgend oder gleichzeitig? Fristen?)
• Entscheidungsprozess dokumentieren und auf Github veröffentlichen.
• Wie sollen getroffene Entscheidungen transparent gemacht werden (z.B. Diskussion bzw. Argumente und Pro/Contra-Stimmenverteilung im Github Issue dokumentieren)?
• Wie sollten die FreifunkCDC Mitglieder über ein neues Github Issue informiert werden? (E-Mail gemäß API Datei der eigenen Community inkl. Facebook, Twitter, etc., per Mailing listen (welche?), per Freifunk Forum?)
• Wie ist zu verfahren, wenn die jeweilige Freifunk Community über einen "Geburtshelfer" eingetragen würde, also sich nicht selbst ins Freifunk Community Directory eigetragen hat?
• Wie soll sichergestellt werden, dass nur stimmberechtigt Repräsentanten der jeweiligen Freifunk Community an der Abstimmung eine Stimme abgeben? (keine Trolle, keine unberechtigten, keine "Mehrfach-Stimmen") - zur Transparenz: Kriterien dokumentieren
• Sollen Personen außerhalb des FreifunkCDC über die anstehende Abstimmung und/oder deren Entscheidung informiert werden? Wenn ja: wie? Freifunk Forum? Mailing-Listen? Beides?
• Wann soll das Github Issue ohne Abstimmung geschlossen werden? (Issue durch Troll erstellt, oder von einer Person, die keiner gelisteten Freifunk Community zugeordnet werden kann bzw. nicht als Repräsentant einer Community bekannt ist?)
• Einfache Mehrheit? Wie Enthaltungen werten? Mindestbeteiligung oder egal wie viele?
• Wie macht jede Freifunk Community Ihrem Representanten bekannt? Website Impressum? API Datei Feld? Eindeutiger Name (Github-Account-Name, Forum-Name)? E-Mail-Absender können leicht gefälscht werden.
• Wie das Freifunk Community Directory Team informieren? @-mention im Github Issue? Issue mit einem TAG versehen?
• Github Issue: Definition of Ready / Definition of Done?

DRAFT: Prozess:
siehe QUALITY.md: Nachprüfung / Anlassbezogene Prüfung / Löschen von Einträgen

Start:
@andibraeu @OLeier fehlt Euch im ersten Arbeitspaket noch was oder könnten wir jetzt "Marketing für das Ticket" machen? Wie und wen machen wir auf dieses Ticket aufmerksam?

[mathiashro]

Hallo, ich würde mich wieder beteiligen (für Freifunk Rostock). Wichtig wäre es keine neuen parallelen Kommunikationskanäle aufzubauen - wie etwa die Notwendigkeit von Foren & Co. Auch sehe ich den Begriff "Council" für zu möglicherweise schwerfällig. Im Grundsatz sollte jeder sich bei Freifunk entfalten können, neue Dinge ausprobieren oder eben auch "anders" sein dürfen.
Wichtig ist es insbesondere allg. Dinge wie das Pico Peering Agreement und den Konsens was Freifunk ist / oder eben nicht, zu hinterfragen und zu leben.
Dabei ist es ratsam mit etwas Fingerspitzengefühl, weniger aber als "Council" aufzutreten. Je zentralisierter und formeller Entscheidungswege werden, desto schwerfälliger können sich die lokalen Bewegungen "entfalten" bzw. es entsteht Aufwand, der auf lange Sicht nicht durch getragen wird.

[christian-weiss]

99,9% Zustimmung.

Vorschläge für einen anderen Namen sind sehr willkommen.
"Freifunk Community Directory Council", oder kurz "FreifunkCDC" ist nur ein erster Entwurf, um Ihn vom "Freifunk Community Directory Team" abzugrenzen.

Ein Council (Rat) hat eine Entscheidungsgewallt, das technische Team hingegen nicht (zumindest nicht für die nicht-technischen Dinge). Das ist der Grundgedanke.

Bisher konnte man z.B. im Forum lesen, dass die Arbeit des Team, dass sich mit diesem Github Repo beschäftigt zu intransparente Entscheidungswege hat. Genau dieses wollen wir nun transparenter machen. Das Team möchte ausschließlich ein technischer "Dienstleister" sein.

Entscheidungen (die nicht technischer Natur sind) - soll die Freifunk Initiative (also alle Freifunk Communities gemeinsam) treffen - im FreifunkCDC. Demokratisch, transparent und gut dokumentiert - ein Mindestmaß an Formalie ist da leider notwendig - ansonsten kann man den Wunsch nach Transparenz kaum erfüllen.

[christian-weiss]

Das FreifunkCDC soll nur Entscheiden bzgl. dieses Github Repos treffen. Für alle anderen "globalen Themen", die für dieses Github Repo nicht zwingend nötig sind (z.B. Peco Peering Agreement) wäre m.E. eher das Freifunk Advisory Council zuständig (kurz FreifunkAC). Wer mag kann das FreifunkAC wieder "ans Fliegen bringen". Das ist aber out of scope von diesem Github Issue hier.

[OLeier]

Hallo, da es um nicht-technische Entscheidungen geht, ist mein Monitoring nicht (direkt) betroffen.
Was ich mir wünschen würde, ist eine zuverlässige Kommunikation untereinander. In der API sind 3 Email Adressen möglich - wenn es darauf an kommt, funktioniert Keine. Im Forum habe ich gelesen: "Wir sind normal nicht hier. Wir haben was Eigenenes ...". Auf Github sind zwar alle Communities gelistet, aber nicht jeder hat das selbst getan, ist also mit einem Account vertreten. Sollte auf allen Kontakten informiert werden - auch auf facebook und Co?

[christian-weiss]

Gute Punkte.

Ja sowohl das "FreifunkCDC" als auch das "FreifunkCDTeam" möchte die jeweiligen Freifunk Communities zuverlässig erreichen können. Das FreifunkCDTeam kann dabei selbst entscheiden, wie viel Aufwand es betreibt, wenn auf E-Mails nicht geantwortet wird (E-Mail-Adressen die in der jeweiligen API Datei genannt werden), also ob Facebook und Twitter sowie andere Kanäle inkl. Brieftauben versucht werden, um jemanden zu erreichen - vor allem muss der manuelle Aufwand überschaubar sein (denke ich).
Das FreifunkCDC kann sich unabhängig von dem FreifunkCDTeam entscheiden, wie viel Aufwand es betreiben möchte, um seine Mitglieder zu informieren. Initial vermutlich über nahezu alle Kanäle. Sobald das FreifunkCDC voll gegründet ist, wird es vermutlich eine weniger Aufwändigen Kanal wählen (vereinheitlichen).

Dazu habe ich o.g. Bescheibung in 2 Punkten angepasst:

• Wie sollten die FreifunkCDC Mitglieder über ein neues Github Issue informiert werden? (E-Mail gemäß API Datei der eigenen Community inkl. Facebook, Twitter, etc., per Mailing listen (welche?), per Freifunk Forum?)
• Wie ist zu verfahren, wenn die jeweilige Freifunk Community über einen "Geburtshelfer" eingetragen würde, also sich nicht selbst ins Freifunk Community Directory eigetragen hat?

Wir könnten alle Committer fragen, ob Sie weiterhin menschlicher Proxy sein möchten, oder ob Sie Ansprechpartner in den Freifunk Communities zumindest benennen können. Einbeziehen können wir die Committer über Github At-Mentions.

[Adorfer]

Auf Github sind zwar alle Communities gelistet

Das ist ja eben seit des Umzugs vom Wiki zu Github mit der dadurch eingeführten Gatekeeper-Funktion der GitMaintainer eben nicht mehr der Fall.
Natürlich nur aufgrund des spezifischen Auslegung, was eine Community ist und was nicht.

[awlx]

Wäre nicht ein Council genau dafür da auch darüber abzustimmen was eine Community ist und was nicht?

[meyerjom]

Hallo Zusammen,
vielen Dank für die viele Arbeit die ihr euch gemacht habt!
Geht es bei dem Vorschlag eigentlich um ein aktuelles Problem (wenn ja, welches?), oder eher um eine strategische Ausrichtung?
Vielen Dank!
jom

[christian-weiss]

Das aktuelle "Problem" zu o.g. Lösungsvorschlag ist:

• einige Freifunker empfinden das "Freifunk API Directory" als zu undemokratisch (dieses wurde über die Jahre, immer wieder geäußert)
• die Einträge überaltern und Ansprechpartner (API-Datei-Pfleger) sind nicht bekannt oder reagieren häufig nicht bzw. sehr-sehr träge
• ein Gremium wie das Freifunk Council existiert nur auf dem Papier (und würde sich vermutlich auch nicht für die API zuständig fühlen)
• die Kommunikation mit den "Ansprechpartnern" ist zu manuell und damit zu zeitraubend

Erwartungsmangement soll verbessert werden. Das technische Team soll bei Inaktivität von "Ansprechpartnern" auch "veraltete" API-Einträge entfernen (nachdem das FreifunkCDC das so beschlossen hat) dürfen (ohne Aufschrei), weil das Vorgehen demokratisch abgestimmt und transparent kommuniziert wurde.

Dieses Ticket stellt eine Einladung an alle dar, die bei diesem Thema helfen wollen eine Lösung zu erdenken zu etablieren.