Es waren ca. 15 Leute vor Ort. Es waren sowohl Leute da, die erst seit wenigen Wochen mit FF zu tun haben, als auch alte Hasen, die schon 10 Jahre dabei sind. Wir hatten ein angenehmes Treffen mit Kleingruppenphase und produktivem Austausch.
Am Anfang haben wir kleine Punkte, bei denen wir schnell zu Entscheidungen kommen, gemeinsam abgearbeitet.
🚀 Wir wollen die branches in unseren Repositories von master auf main umbenennen, um eine inklusive Sprache zu nutzen. Zuvor muss einmal geprüft werden, an welchen Stellen Anpassungen nötig sind. Es soll eine Vorankündigung und Erklärung für die Änderungen am lokalen Repo geben. Zusätzlich soll bei der Umstellung eine jeweils passende branch-protection eingestellt werden.
✅ Branches umbenennen und protecten. (bbb-configs #646, hopglass.berlin.freifunk.net #18, config.berlin.freifunk.net #94, util.berlin.freifunk.net #21, falter-packages #423, falter-builter #152)
🚀 Es gibt mehrere Listen, die aktuell nicht mehr verwendet werden (Neukölln, Treptow-Köpenick und Spandau). Diese sollen abgeschaltet, aber archiviert werden.
✅ Perry schreibt Sven wegen des Abschaltens der Mailinglisten (meta #52)
✅ Auf der Hauptliste ist nach wie vor keine Registrierung wegen eines Bugs möglich. Rtznmpfl schreibt Nosy wegen eines Updates und schaut direkt, ob wir dem Menschen eine nette Aufmerksamkeit zukommen lassen (done)
Warnwesten im FF-Style sehen gut aus und machen es offizieller, wenn wir am Standort arbeiten. Die Community in Fürstenberg hat Material, um solche Westen drucken zu lassen. Dadurch könnte es auch einen Inter-Community Austausch geben.
🚀 Wir haben uns dazu entschieden, FF-Westen zusammen mit Fürstenberg zu drucken.
✅ Schmars stellt Kontakt her und Stadtfunk kümmert sich um alles Weitere (meta #53)
Waren beim Communitytag dabei und hätten Interesse an einer bbb-configs Schulung.
✅ Hener kommt mal einen Freitag vorbei (meta #54)
Das Single File Format soll irgendwann den gesamten Standort abbilden und auch für proprietäre Devices die config rauswerfen. Dazu gibt es das Issue #751.
🚀 Die Anwesenden beim Communitytag stimmen dem vorgestellten File Format zu. Es gab dazu noch den Hinweis, dass bei den SSIDs auf die Maximallänge von 32 Zeichen geachtet werden sollte.
Der Freifunk-Raum im Haus der Materialisierung freut sich darüber, wenn wir mal alte und defekte Hardware austauschen. Bei der Gelegenheit wollen wir auch mal eine grobe Inventarliste anlegen, die einfach den Status Quo abbildet.
✅ Rtznmpfl organisiert dafür einen Tag (meta #31)
Die aktuelle Raummiete endet mit diesem Jahr. Für die Zukunft bräuchten wir auf jeden Fall einen warmen Raum. Auch kam die Frage auf, wie gut wir in das Konzept reinpassen, weil die anderen Projekte eher einen 9-to-5-Modus haben und unsere Arbeit eher abends oder auswärts stattfindet. Allen gefällt die zentrale Lage.
🚀 Wir wollen schauen, ob wir für die nächsten Jahre Untermieter von Searchwing werden könnten, nachdem die innerhalb des HdMs umgezogen sind. Die Kooperation hat in der Vergangenheit auch gut funktioniert.
✅ Rtznmpfl spricht mit Phillip darüber (meta #55)
Wir haben etwa 1,5 Stunden in je einem Raum an den Themenfeldern Technik und Community gearbeitet. Danach wurden die Ergebnisse in der großen Runde diskutiert, um zu einer gemeinsamen Entscheidung zu kommen.
Etwa die Hälfte der Geräte sind nicht auf dem aktuellen Firmwarestand. Dies sind zum größten Teil Geräte, die nicht von der Kerncommunity betrieben werden. Wir sollten langsam nach und nach Leute direkt anschreiben. Das sollten wir direkt von der FF-Mailadresse aus machen. Dabei sollten wir den Leuten auch direkt Ersatzgeräte mit anbieten. Damit wollen wir unter anderem auch dem vorbeugen, dass irgendwo in der Stadt nicht mehr funktionierende Freifunk-SSIDs rumfunken.
Auch innerhalb des Backbones gibt es Aufgaben und Standorte, die liegen bleiben. Wir wollen deshalb Metaissues anlegen, um das zu tracken und nachvollziehen zu können, was passiert und was noch passieren muss. Das macht es auch anderen leichter zu unterstützen. Idealerweise muss auch nicht die Person, die den Standort gebaut hat, die Wartung durchführen.
Wir wollen außerdem historische Daten sammeln. Dies hilft beim Finden alter Standorte, die nicht mehr funktionieren, aber auch generell schön ein Archiv über unsere Arbeit zu haben.
🚀 In der großen Runde wurde der Vorschlag zum Kontaktieren/Updaten veralteter Nodes, dem Tracken von Maintenance-Aufgaben und dem Sammeln historischer Daten angenommen.
✅ Veraltete nicht Community-Standorte anschreiben
✅ Metaissues für Maintenance im Backbone anlegen (done, siehe maintenance issues)
✅ Historische Daten verschwundener Nodes sammeln
In der Gateway-Kleingruppe wurde vor allem versucht, das aktuelle Setup zu verstehen, um damit zu entwickeln, wo wir hin wollen. Hier die Mitschrift vom Rücktrag:
- Wir haben aktuell 5 Gateways bei uns im Netz. Diese leiten den Traffic aus dem Backbone-Netz aus und stellen über Wireguard Tunnelserver zur Verfügung. Nach dem letzten Communitytreffen sind doch noch viele Fragen übrig geblieben. Es braucht gerade ein bisschen Arbeit, damit alle verstehen, was der aktuelle Stand ist.
- Es gibt ein altes und ein neues IPv6-SetUp.
- Die Gateways sind aktuell über GRE-Tunnel verbunden. Das brauchen wir zum Synchronisieren, weil jedes Gateway unsere IP-Prefixe announced und der Internettraffic beim Verlassen und Zurückkommen verschiedene Wege und damit verschiedene Gateways nutzen könnte. Ein GRE-Tunnel ist universeller als ein VPN, was z.B. die Protokolle angeht. Es gibt bei manchen Gatewaystandorten die Möglichkeit, dass wir diese direkt per VLAN verbinden könnten. Da wir dadurch aber die Flexibilität verlieren würden, bei der Erschließung neuer Gateways, bleiben wir vorerst bei den GRE-Tunneln.
- Aktuell werden für die Tunnelexits Prefixes von Syseleven und Co. announced. Wir könnten einen der acht Prefixes vom Förderverein nutzen, wenn wer anderes als Who is eingetragen wird.
- CR1 im AK (Corerouter 1), es gibt CR2 als Backup.
- Neue Hardware für Ohlauer und Saarbrücker wäre gut. Bei Ohlauer haben wir 2 HE, bei Saarbrücker einen kleinen Metallkasten unbekannter Größe. Thinkcenter würde da wohl reinpassen.
- Für neue Gateways gibt es ggf. die Möglichkeit bei e-shelter/ntt. Jammingblub hat evtl. einen Kontakt, da wurden gerade ein paar Stellen neu besetzt.
🚀 Wir haben uns dazu entschieden, dass der IPv4-Block vom Förderverein von einer Community-Rechtsform übernommen werden soll, um darüber den Internet-Traffic auszuleiten. Gesponsorte Zugänge von Firmen oder anderen Communities können zusätzlich weiter existieren.
✅ Perry geht mit Förderverein in Kontakt wegen der IP-Blöcke (meta #58)
✅ Hardwareupdate auf den Gateways (meta #59, meta #60)
Keine Kleingruppe, aber ein Thema, das beim Rücktrag aufgekommen ist:
Wir haben das Problem, dass seit dem Umbau zu 60GHz das GBit-Lan zwischen Router und Switch zum Bottleneck wird. Eine Lösung könnte sein, ein zweites Kabel zwischen Router und Switch zu setzen und die VLANs entsprechend zu konfigurieren. Dies ergibt nur Sinn, wenn der Router zwei Netzwerkinterfacekarten besitzt.
🚀 Um das Router-Switch-Bottleneck zu lösen, soll eine zweite Kabelverbindung getestet werden.
✅ Der Belkin RT3200 auf der Zwingli erfüllt diese Eigenschaft. Hener wird in absehbarer Zeit als Test das zweite Kabel stecken, Noki konfiguriert den Switch. (meta #43)
Als lose Community können wir viele Dinge einfach direkt umsetzen. Aber einige Aufgaben stellen uns vor Schwierigkeiten, wenn wir diese basisdemokratisch lösen und Abhängigkeiten von Einzelpersonen vermeiden wollen. Vor allem sind das die Aufgaben, bei denen Verträge abgeschlossen werden und daher eine juristische Person gebraucht wird. Konkret sind das folgende Bereiche, die für uns spannend sind: Verträge für Server, IPs, Domains und Standorte, Versicherungen, Spenden annehmen und verwalten, Übungsleiterpauschale für einzelne Aufgaben. Aktuell werden einige dieser Aufgaben vom Förderverein Freie Netzwerke e.V. oder der Stadtfunk gGmbH getragen. Der Verein möchte die Verantwortlichkeiten abgeben, da diese nicht im Rahmen des Vereinszwecks liegen. Teilweise sind Verträge auch über Privatpersonen abgeschlossen. In der Kleingruppe wurde folgender Vorschlag für eine passende Rechtsform erarbeitet:
Es soll ein minimaler Verein mit folgenden Eigenschaften gegründet werden:
- Keine Repräsentation der Community
- Minimale Struktur (nur wenige Mitglieder)
- Minimale Bürokratie
- Dadurch ist es nicht im Sinne demokratisch, dass die Community auf offiziellem Weg mitentscheiden darf
- In der Selbstbeschreibung/Satzung wird Bezug auf Community Anbindung genommen
- Es wird festgelegt, dass der Verein die Community-Tage und Hackdays veranstaltet, um einen Austausch vorzuschreiben
- Die Geschäfte des Vereins werden auf der Website für alle transparent gemacht
- Auf den Community-Events gibt es eine Berichterstattung über Tätigkeiten des Vereins (kein Verwaltungskram)
- Neue Mitglieder werden aufgenommen nach Entscheidungen im Verein
- Verein soll sich auf Pico Peering und einen Code of Conduct beziehen, aber auch die Möglichkeit haben, Wartungsangebote zu geben
- Verein soll Gemeinnützigkeit haben
- Dritte sollen unter Vertrag genommen werden können, um bei FF Aufgaben zu unterstützen. Dabei soll es nicht um SLAs gehen, sondern um z.B. die Wartung von unserer Infrastruktur/wo Aufgaben liegen bleiben
- Liquid Feedback als Tool für ständige online Versammlung, um Verwaltung zu vereinfachen
- Die Selbstbeschreibung des Vereins soll sein: FreiFunktion Berlin e.V. dient als ein Kontaktpunkt für Freifunk Angelegenheiten in Berlin. Der Verein schließt Verträge für den Betrieb und die Wartung diverser Standorte und weiterer Infrastruktur ab. FreiFunktion Berlin e.V. ist ein funktionales Werkzeug für rechtliche Angelegenheiten und repräsentiert nicht die Freifunk Community in Berlin.
- Der Name soll "FreiFunktion Berlin e.V." sein
🚀 Die Anwesenden haben einer Gründung eines solchen Minimalvereins zugestimmt.
✅ Vereinsgründung vorbereiten (meta #8)
Die Community wird dominiert von (Cis-)männlichen Personen. Das bedeutet, dass FLINTA* (Frauen, Lesben, Non-binary, Trans und Agender Personen) kaum aktiv bzw. sichtbar sind. Unser Anspruch ist es, dass wir in der Community möglichst divers aufgestellt sind und offen für alle sind. In der Kleingruppe wurde folgendes Konzept erarbeitet, um darauf hinzuwirken:
- Ein Selbstverständnis in der Community erarbeiten und formulieren. Dies soll erklären, dass wir eine Community sein wollen, die offen für alle ist und die nicht andere ausschließt. Wir wollen bei unserem Zusammenkommen aktiv einen Raum schaffen, in dem sich alle wohl fühlen. Analog zum Pico Peering soll ein Code of Conduct / Selbstverständnis geschrieben werden. Dies kann dann auf alle FF Orte angewendet und referenziert werden. Der Text soll in einem offenen Prozess entstehen und beim nächsten Community Tag vorgestellt werden.
- Wir wollen die Community generell zugänglicher für Einsteiger*innen machen.
- In der Zukunft gehen wir aktiv aus unserer Bubble heraus, um auch mehr FLINTA* mit dem Projekt zu erreichen und dafür zu begeistern.
🚀 Der Vorschlag wurde in der großen Runde positiv aufgenommen und ein Code of conduct soll erarbeitet werden. Zusätzlich soll das Pico Peering Agreement sprachlich und technisch aktualisiert werden.
✅ Code of conduct schreiben (meta #57)
✅ Pico Peering sprachlich und technisch aktualisieren (meta #56)
Ideen zu Orten außerhalb unserer Bubble, die während dem Gespräch genannt wurden:
- Volkshoch-/Schule Kurs
- Star-Code (geht an Schulen mit Inhalten die man in AGs/Projekten vorschlagen kann, u.a. an der TU aktiv)
- Vereinen Hardware und Workshop anbieten
- Kleingartenanlagen
- Nachbarschaftsvernetzungen
Wir wollen uns das nächste Mal am Sonntag, den 21. April ab 11:00 zum Hackday treffen. Stadtfunk lädt zu dem Treffen ein. Bereits gesetzte Themen sind:
- Website mit Noki
- ggf. Vereinsgründung
- ggf. Code of conduct
- Perry hat für alle Interessierten zum Abschluss noch einen Crimpworkshop gehalten