<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2017-02-10 um 12:20 schrieb Wolfgang Nagele:<br>
</div>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Liebe Community,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
Mein herzliches Dankeschön für diese Initiative!<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Memorandum of Understanding</div>
<div>---</div>
<div>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.</div>
<div><br>
</div>
<div>- Jeder Service hat mindestens 2 aktive Maintainer</div>
</div>
</blockquote>
<br>
„Service“ wäre (für zukünftige Entwicklungen) allgemein genauer zu
definieren. (sonst ist etwa auch ein Node davon umfasst.)<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Jeder Service hat ein Mitglied im Vorstand als Sponsor</div>
<div> - Der Sponsor im Vorstand kommuniziert mit den
Maintainern um den Status vom Service zu evaluieren</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Jeder Service wird einmal pro Monat im Vorstandsmeeting
reviewed auf Status</div>
</div>
</blockquote>
+1<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> - Kümmern sich die Maintainer aktiv um den Service?</div>
</div>
</blockquote>
+1<br>
<br>
- Vorschlag zur Verwaltungsvereinfachung: Monthly report einfach auf
der Projektübersicht im Wiki eintragen?<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> - Werden Sicherheitsupdates aktiv bearbeitet?</div>
</div>
</blockquote>
<br>
Wer beurteilt, überprüft das? Sonst: +1<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Jeder Service verwendet die Vereinsinfrastruktur und
commited sich bei etwaigen Änderungen aktiv an der
Implementierung mitzuarbeiten (Compute, Network, Storage)</div>
</div>
</blockquote>
<br>
Der Satz ergibt keinen Sinn. Fehlt da ein „Maintainer“?<br>
Du meinst, dass, wenn etwa die VM umgestellt wird, Maintainer aktiv
mitwirken müssen?<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- 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</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> - 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.</div>
</div>
</blockquote>
<br>
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.<br>
Lösungsweg: dem Project Angel Verfügungsmacht erteilen, Dienste je
nach Wichtigkeit einstweilen abzuschalten oder sonst provisorisch
abzuschotten?<br>
<br>
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.<br>
<br>
<br>
<br>
- 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).<br>
<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Der Verein supported nur noch Core Services welche dem
Vereinszweck mittelbar dienen.</div>
</div>
</blockquote>
<br>
Mittelbar ist aber sehr weit gefasst...<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> 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.</div>
</div>
</blockquote>
<br>
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<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div>Services</div>
<div>---</div>
<div>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.</div>
<div><br>
</div>
<div>- Core Network (Config & Hardware, inkl. RIPE
Maintenance, Cacti, Flow Accounting)</div>
<div>- Core Compute & Storage Infra (inkl. Central Logging
& LDAP)</div>
<div>- Physical Housing Environment (Temperatur Sensoren,
Zutrittssystem, Kamera Ueberwachung, Luefer, Reinigung, Strom,
Power Leisten, etc.)</div>
<div>- Gallery</div>
<div>- Mailserver</div>
</div>
</blockquote>
Mailserver umfasst auch den Mailman und Listenmoderation?<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Wiki</div>
<div>- Dokumentations Wiki (v.a. Intern)</div>
<div>- Map</div>
</div>
</blockquote>
<br>
Ein weiteres Frontend für die Map ist bereits veröffentlicht -
(Danke an Clemens und David!)<br>
<a class="moz-txt-link-freetext" href="https://wiki.funkfeuer.at/wiki/Projekte/0xFF-NodeMap">https://wiki.funkfeuer.at/wiki/Projekte/0xFF-NodeMap</a><br>
<a class="moz-txt-link-freetext" href="https://map.funkfeuer.at/nodemap/">https://map.funkfeuer.at/nodemap/</a><br>
<br>
Bezüglich der Datenquelle (data.php) bin ich an der Co-Autorschaft
einer Nachfolgelösung interessiert, die in die NodeDB zu integrieren
ist.<br>
Es gibt auch zahlreiche Wünsche, wie etwa eine Anzeige einer
Statusänderung/eines Statusverlaufs eines Nodes auf der Map.<br>
<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Housing Billing</div>
<div>- Tunnelserver</div>
</div>
</blockquote>
Der Tunnelserver erfüllt einen Grundzugang zum laut Statut
betriebenen Netzwerk. Dieser Dienst ist in meinen Augen ebenso wie
der Roofnode „unveräußerbar“.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- SmokePing</div>
<div>- Redeemer (inkl. Datenbank) oder Successor davon</div>
</div>
</blockquote>
Wegen Map-Data-Plugin Co-Maintaining u.U. von Interesse für mich.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- DNS</div>
</div>
</blockquote>
Co-Maintaining könnte ich mir vorstellen, wenn Änderungen per
Auditlösung erfasst werden.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Social Media (Twitter, Facebook, etc.)</div>
<div>- Nagios</div>
</div>
</blockquote>
Wir verwenden Nagios?!<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Whois</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Shop</div>
<div>- Member Mailer</div>
<div>- <Fällt dir noch was ein?></div>
</div>
</blockquote>
<br>
Forum?<br>
Layar-Plugin by Wolfgang Nagele?<br>
<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Commons Services</div>
<div>---</div>
<div>Diese Services werden in Zukunft als Commons Services
weiter geführt.</div>
<div><br>
</div>
<div>- VoIP</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- <a moz-do-not-send="true"
href="http://download.funkfeuer.at">download.funkfeuer.at</a>
(-> <a moz-do-not-send="true"
href="http://mirror.funkfeuer.at">mirror.funkfeuer.at</a>)</div>
</div>
</blockquote>
<br>
DL von „texas“ mergen/syncen/verlinken?<br>
DL von “oe1xrw“ mergen/syncen/verlinken?<br>
DL von “srv1“ mergen/syncen/verlinken?<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>- Etherpad</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Sind „Common Services“ also: <u><i>„Hilfswerkzeuge, die der
besseren Selbstorganisation, Kommunikation und Sozialisierung
der Community dienen“</i></u>?<br>
Dann fiele etwa auch das Forum oder die Mailinglisten hierunter.
Eventuell auch Teile von Social Media - nicht hingegen etwa ein
Umfrage-Tool.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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).<br>
Am selben Ort kann auch ein „Call for Maintainers“ (=„offene
Stellen“) erfolgen.<br>
<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
Ansonsten: +1<br>
<blockquote
cite="mid:CAK6j62zTncATzR+9RoQfShUK6C0_WBgPqCYY7jD7B=jSAJR9yQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>lg</div>
<div>Wolfgang</div>
<div>für den FunkFeuer Wien Vorstand</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
LG<br>
Erich<br>
</body>
</html>