[Wien] [Discuss] WICHTIG: Vereins Services - ein neuer Ansatz

[Erich N. Pekarek]

Hallo!

Am 2017-02-10 um 12:20 schrieb Wolfgang Nagele:
> Liebe Community,
>
> Als Follow-up zu meinen Marvin Emails und vielen Konversationen über 
> die letzten Monate, hier ein initialer Vorschlag für unseren Umgang 
> mit Vereins Services in Zukunft.
>
> Alles hier ist im Moment ein Vorschlag - der Vorstand möchte dies aber 
> definitiv voran treiben und eine neue Basis für unseren Betrieb 
> schaffen. Daher ist nun die Zeit hier konstruktiv mitzuarbeiten und 
> diesen Ansatz zu formen.
>

Ich bin sicher, dass mehr Struktur und bessere Kommunikation wichtig für 
den Fortbestand und die Weiterentwicklung nicht nur der Services, 
sondern ganz allgemein für den Verein sind.

Mein herzliches Dankeschön für diese Initiative!

>
> Memorandum of Understanding
> ---
> Das wird un Zukunft unser gemeinsames Verständnis von Beteiligten die 
> Services für den Verein und die Community betreiben. Wer einen Service 
> für uns betreibt muss sich daran halten.
>
> - Jeder Service hat mindestens 2 aktive Maintainer

„Service“ wäre (für zukünftige Entwicklungen) allgemein genauer zu 
definieren. (sonst ist etwa auch ein Node davon umfasst.)

> - Jeder Service hat ein Mitglied im Vorstand als Sponsor
>   - Der Sponsor im Vorstand kommuniziert mit den Maintainern um den 
> Status vom Service zu evaluieren

Nennen wir den „Sponsor“ lieber „Project Angel“: Seine Aufgabe ist es 
ja, Schnittstelle zwischen „Maintainern“ und Vorstand zu sein. 
Einerseits wirbt er beim Vorstand um Unterstützung für die Tasks der 
Maintainer (VM, ML, Subdomain, Events, ...) und andererseits sorgt er 
dafür, dass der Vorstand über die aktuellen Entwicklungen Bescheid weiß, 
sodass der Vorstand von Nebenaufgaben entlastet wird. So kann der 
Vorstand sich voll auf seine Leitungsaufgabe konzentrieren.

> - Jeder Service wird einmal pro Monat im Vorstandsmeeting reviewed auf 
> Status
+1
>   - Kümmern sich die Maintainer aktiv um den Service?
+1

- Vorschlag zur Verwaltungsvereinfachung: Monthly report einfach auf der 
Projektübersicht im Wiki eintragen?

>   - Werden Sicherheitsupdates aktiv bearbeitet?

Wer beurteilt, überprüft das? Sonst: +1

> - Jeder Service verwendet die Vereinsinfrastruktur und commited sich 
> bei etwaigen Änderungen aktiv an der Implementierung mitzuarbeiten 
> (Compute, Network, Storage)

Der Satz ergibt keinen Sinn. Fehlt da ein „Maintainer“?
Du meinst, dass, wenn etwa die VM umgestellt wird, Maintainer aktiv 
mitwirken müssen?

> - Jeder Service Maintainer commited sich einen Übergang innerhalb von 
> 3 Monaten zu einem anderen Maintainer durchzuführen und dabei zu 
> helfen, sollte er/sie sich selbst nicht mehr darum kümmern können oder 
> wollen

Eventuell sollte in der Übergangszeit der Projekt Angel 
Maintaineraufgaben mitübernehmen. Wenn nämlich nur zwei Maintainer 
vorhanden sind, und einer  wegen Krankheit und ein zweiter wegen 
Auslandsaufenthalt ausfällt, wird die Frist nicht immer zu halten sein.

>   - Wenn innerhalb dieser Periode kein Nachfolger gefunden werden kann 
> wird der Service für 3 Monate als dormant geführt. Nach dieser Zeit 
> wird der Service eingestellt oder auf einen Commons Service migriert 
> welcher nicht mehr auf der Vereins Infrastruktur selbst zu finden ist 
> und nicht direkt vom Verein betrieben wird.

Binnen drei Monaten kann viel passieren - der Mechanismus des 
„Totmannschalters“ sollte unmittelbar wirken. Wenn ein Status-Review 
monatlich erfolgt, dann ist diese Frist wohl auch auf Security-Aspekte 
zurückzuführen. Drei Monate lang unbetreute Dienste könnten dann aber 
ein Problem darstellen.
Lösungsweg: dem Project Angel Verfügungsmacht erteilen, Dienste je nach 
Wichtigkeit einstweilen abzuschalten oder sonst provisorisch abzuschotten?

Durch eine (Teil-) Abschaltung, so unangenehm und unpopulär diese auch 
sein mag, würde auch die Wahrnehmungsschwelle für den zuvor 
kommunzierten Handlungs- und Mitwirkungsbedarf erhöht.



- Vorschlag: Zur Wahrung der Gleichberechtigung von Interessen sollten 
auch Maintainer eine Mitsprachemöglichkeit/Vorsprachemöglichkeit beim 
Vorstand haben, wenn der Project Angel oder Sponsor untätig bleibt. 
(quasi: Vier-Augen-Prinzip).


> - Der Verein supported nur noch Core Services welche dem Vereinszweck 
> mittelbar dienen.

Mittelbar ist aber sehr weit gefasst...

> Andere Services können ggf. durch zur Verfügungstellung von Resourcen 
> (sprich - Housing von Hardware) supported werden. Dabei handelt es 
> sich um Commons Services. Beispiele hierfür könnten z.B. Mirrors von 
> OpenSource Projekten o.ä. sein. Solche Projekte werden nur supported 
> wenn es keine bereits bestehenden guten Alternativen gibt. Genauso 
> werden diese wieder entfernt, sollten sich neue gute Alternativen 
> entwickeln.

Das bitte noch besser ausformulieren. Die Begriffe „Core Services“ und 
„Common Services“ sollten klar umrissen sein oder „Core Services“ 
abschließend aufgezählt werden. Dann: +1

>
>
> Services
> ---
> Hier ist eine Liste mit dzt. identifizierten Services - bitte um 
> Erweiterung falls euch noch was einfällt. Auch, bitte um Info wenn ihr 
> euch um einen dieser Services nach dem oben stehenden MoU kümmern 
> würdet wollen.
>
> - Core Network (Config & Hardware, inkl. RIPE Maintenance, Cacti, Flow 
> Accounting)
> - Core Compute & Storage Infra (inkl. Central Logging & LDAP)
> - Physical Housing Environment (Temperatur Sensoren, Zutrittssystem, 
> Kamera Ueberwachung, Luefer, Reinigung, Strom, Power Leisten, etc.)
> - Gallery
> - Mailserver
Mailserver umfasst auch den Mailman und Listenmoderation?
> - Wiki
> - Dokumentations Wiki (v.a. Intern)
> - Map

Ein weiteres Frontend für die Map ist bereits veröffentlicht - (Danke an 
Clemens und David!)
https://wiki.funkfeuer.at/wiki/Projekte/0xFF-NodeMap
https://map.funkfeuer.at/nodemap/

Bezüglich der Datenquelle (data.php) bin ich an der Co-Autorschaft einer 
Nachfolgelösung interessiert, die in die NodeDB zu integrieren ist.
Es gibt auch zahlreiche Wünsche, wie etwa eine Anzeige einer 
Statusänderung/eines Statusverlaufs eines Nodes auf der Map.


> - Housing Billing
> - Tunnelserver
Der Tunnelserver erfüllt einen Grundzugang zum laut Statut betriebenen 
Netzwerk. Dieser Dienst ist in meinen Augen ebenso wie der Roofnode 
„unveräußerbar“.

> - SmokePing
> - Redeemer (inkl. Datenbank) oder Successor davon
Wegen Map-Data-Plugin Co-Maintaining u.U. von Interesse für mich.

> - DNS
Co-Maintaining könnte ich mir vorstellen, wenn Änderungen per 
Auditlösung erfasst werden.

> - Social Media (Twitter, Facebook, etc.)
> - Nagios
Wir verwenden Nagios?!

> - Whois
gehört mE mit DNS und RIPE-Management zusammengefasst, um Konsistent zu 
bleiben. Eventuell als „inner layer“ (nicht-öffentliche Daten) und 
„outer layer“ (öffentliche Daten) organisieren - aber die 
Kompetenzanforderung bleibt ident.

> - Shop
> - Member Mailer
> - <Fällt dir noch was ein?>

Forum?
Layar-Plugin by Wolfgang Nagele?


>
> Commons Services
> ---
> Diese Services werden in Zukunft als Commons Services weiter geführt.
>
> - VoIP

Habe mich als Co-Maintainer für Letsencrypt und Co auf diesem Dienst 
bereits angeboten; Ich hinterfrage aber die generelle Notwendigkeit des 
konkreten VoIP-Dienstes außer zur vereinsinternen Weiterbildung. Zur 
faktischen Kommunikation gibt es andere, bessere Möglichkeiten.

> - download.funkfeuer.at <http://download.funkfeuer.at> (-> 
> mirror.funkfeuer.at <http://mirror.funkfeuer.at>)

DL von „texas“ mergen/syncen/verlinken?
DL von “oe1xrw“ mergen/syncen/verlinken?
DL von “srv1“ mergen/syncen/verlinken?

> - Etherpad
>

Sind „Common Services“ also: _/„Hilfswerkzeuge, die der besseren 
Selbstorganisation, Kommunikation und Sozialisierung der Community 
dienen“/_?
Dann fiele etwa auch das Forum oder die Mailinglisten hierunter. 
Eventuell auch Teile von Social Media - nicht hingegen etwa ein 
Umfrage-Tool.

>
> Nun, wie gehen wir hier weiter vor? Zuerst wollen wir euch die 
> Möglichkeit geben euren Input zu liefern und zu sagen wo ihr euch 
> beteiligen würdet. Wir brauchen v.a. Maintainer die sich an oben 
> genanntes MoU binden werden.

Ich würde die künftigen Sposoren oder Project Angel ersuchen, im Wiki 
bei den Projektseiten den Umfang der obgenannten Dienste 
zusammenzufassen, eine Kurzbeschreibung zu erstellen, die Reichweite 
dieser Dienste abzuschätzen und gegebenenfalls die erforderlichen 
„Skills“, die von Maintainern verlangt werden, zu skizzieren -auch, wenn 
uns das selbstverständlich erscheint (für die Nachwuchspflege ist das 
eine gute Orientierungshilfe).
Am selben Ort kann auch ein „Call for Maintainers“ (=„offene Stellen“) 
erfolgen.

>
> Danach werden wir die Services evaluieren und eine gemeinsame Basis 
> für den Betrieb finden. Wenn das geschafft ist gehen wir zum 
> Tagesbetrieb über wo wir euch viel Freiraum geben wollen und nur wie 
> oben beschrieben sicherstellen das der Service noch aktiv maintained 
> wird und eine gemeinsame Infrastruktur genutzt wird.

Mir fehlt ein wichtiger Punkt: Die unmittelbare Beteiligung der 
Community als Nutzer dieser Dienste. Nur, weil eine Gruppe Dienste 
übernimmt, bedeutet das nicht, dass sie auch den Wünschen und 
Anforderungen allgemein gerecht wird. Hier muss ein Feedback-Mechanismus 
und vorsorglich auch eine Streitschlichtung her.


Ansonsten: +1
>
> lg
> Wolfgang
> für den FunkFeuer Wien Vorstand
>
>

LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20170210/ea968673/attachment.htm>