[Wien] WICHTIG: Vereins Services - ein neuer Ansatz

[Wolfgang Nagele]

Hallo nochmals,

Wie bereits erwähnt würden wir nun gerne ein Kick-off Meeting für alle
Services machen. In diesem Treffen soll es darum gehen das sich alle
Beteiligten kennen lernen können und wir umreisen welchen Umfang jeder
Service in Zukunft haben wird und wie eine etwaige Übergabe ausschauen
könnte.

Termin: 05.04.2017 um 19:00
Wo: Brandauer im Gerngross oben

Bitte mir direkt schicken ob ihr teilnehmen werdet. Wenn nicht in
Person vor Ort werde ich versuchen virtuell via Google Hangouts o.ä.
zu ermöglichen. Es wäre aber *sehr* wichtig und toll wenn wir für
dieses erste Meeting so viel als möglich in Person anwesend sind.

lg

2017-03-19 18:51 GMT+01:00 Wolfgang Nagele <(spam-protected)>:
> Liebe Community,
>
> Habe nun den dzt. Draft nochmals mit eurem Feedback und euren
> möglichen Beteiligungen als Maintainer upgedated. Wie ihr seht gibt es
> nun eine bessere Abdeckung aber wir haben immer noch einige Bereiche
> die Aufmerksamkeit brauchen. Also, wenn du dich dort beteiligen willst
> und kannst bitte entsprechend anzubringen.
>
> Eine Kritik wurde auch laut das hier bestehende Maintainer nicht
> aufgeführt wurden. Es liegt nichts ferner als das wir bestehende
> Maintainer hier ausschliessen wollten. Es ist aber notwendig das auch
> diese sich diesem MoU anschliessen und ich bitte hiermit um Info wer
> sich noch wo einbringen wird wollen. Wie ihr auch seht sind viele
> Services auch mit bestehenden Maintainern hinterlegt - das sind alles
> Leute die sich entsprechend gemeldet haben.
>
>
> Memorandum of Understanding (MoU)
> ---
> Jeder Service ...
> - hat mindestens 2 aktive Maintainer
> - dokumentiert im Wiki die prinzipiellen Skills um den Service zu betreiben
> - nimmt die Erfordernisse der Community an und richtet sich nach deren
> Bedürfnissen
> - hat ein Mitglied im Vorstand als Project Angel, dieser kommuniziert
> mit den Maintainern um den Status des Services zu evaluieren
> - wird einmal pro Monat im Vorstandsmeeting auf dessen Status reviewed.
>   Die Hauptfaktoren hierbei sind:
>   - Entspricht der Servie den Wünschen/Erfordernissen der Community?
>   - Kümmern sich die Maintainer aktiv um den Service?
>   - Werden Sicherheitsupdates aktiv bearbeitet?
> - verwendet die Vereinsinfrastruktur und commited sich bei etwaigen
> Änderungen aktiv an der Implementierung mitzuarbeiten (Compute,
> Network, Storage)
> - 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
>   - 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.
>   - Wenn ein Service Security Mängel aufweist kann diese Frist auch im
> ermessen des Vorstandes verringert werden oder ggf. der Service
> offline genommen werden bis der Übergang und die Mängel behoben werden
> konnten.
> - Der Verein supported nur noch Core Services welche dem Vereinszweck
> mittelbar dienen. Andere Services können ggf. durch zur
> Verfügungstellung von Resourcen (sprich - Housing von Hardware und
> evt. Kauf dieser) 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.
>
>
> Services
> ---
> - Backbone Network (Router, Switches, Anbindung, RIPE Database, Whois,
> Bandwidth Monitoring & Accounting dzt. Flow & Cacti) -> Stefan
> Schultheis, Wolfgang Nagele,
> - Roof Nodes (Zutrittsverwaltung, Physische Installation und Standard
> Konfigurationen) -> Bernhard Marker, <DU?>
> - Core Compute & Storage Infra (inkl. Central Logging, Authentication
> & Monitoring) -> Adi Kriegisch, <DU?>
> - Housing Environment (Temperatur Monitoring und Lüftung,
> Zutrittssystem, Kamera Überwachung, Reinigung, Strom, Power Leisten,
> etc.) -> Michael Med, Gerhard Steinbeis
> - DNS (Reverse, Domains & Provisioning von diesen Zonen, Betrieb von
> zumindest einem Recursive Resolver) -> Peter Schwindt, <DU?>
> - DNS Recursor -> Adi Kriegisch, Aaron Kaplan
> - Mailserver & Mailing Listen -> Adi Kriegisch, Markus Gschwendt
> - Tunnels (Anbindung von Inselknoten) -> Erich N. Pekarek, Bernhard Marker
> - Housing Verwaltung (Billing, Verträge, etc.) -> Clemens Hopfer, <DU?>
> - Node Map -> Erich N. Pekarek, Alexander Biringer
> - Node Monitoring (SmokePing) -> Clemens Hopfer, Adi Kriegisch
> - Node Datenbank (Nachfolger für dzt. Redeemer) -> Maurice Wohlkönig, <DU?>
> - Website -> Maurice Wohlkönig, Felix Schneider
> - Gallery -> <DU?>
> - Wiki (inkl. internem Dokumentations Bereich) -> David Hopfmüller,
> Matthias Subik
> - Social Media (Twitter, Facebook, etc.) -> Peter Schwindt, <DU?>
>
>
> Commons Services
> ---
> - VoIP -> Christoph Loesch, Franz Lax
> - download.funkfeuer.at (-> mirror.funkfeuer.at) -> <DU?>
> - Etherpad -> <DU?>
>
>
> Auflassen/Umstellen
> ---
> - Member Mailer -> Soll in eine Standard Mailingliste integriert werden
> - Shop -> Auflassen/Aufgelassen
>
>
>
> lg
>
> 2017-03-12 11:09 GMT+01:00 Wolfgang Nagele <(spam-protected)>:
>> Liebe Community,
>>
>> Ich habe nun versucht das Feedback von euch in den nächsten Entwurf
>> einzuarbeiten. Das ist immer noch ein Draft und euer konstruktives Feedback
>> ist herzlich willkommen. V.a. bitte direkt Vorschläge für ggf. andere
>> Formulierungen machen.
>>
>> WICHTIG: Bitte schaut auf die Service Liste unten und falls da etwas dabei
>> ist wo ihr euch gerne beteiligen würdet lasst es mich wissen. Wie ihr seht
>> haben wir noch *viele* Maintainer Positionen offen (Habe diese mit <DU?>
>> markiert). Ohne eure Mithilfe können wir diese Services evt. in Zukunft
>> nicht mehr bereitstellen.
>>
>> Auch habe ich bei einigen Services mir die Freiheit genommen Leute als
>> Maintainer anzuführen von denen ich glaube das sie das machen wollen oder
>> von denen ich das konkret gehört habe. Solltet ihr hier gelistet sein und
>> das doch nicht wollen - bitte auch direkt um Info.
>>
>> Memorandum of Understanding (MoU)
>> ---
>> Jeder Service ...
>> - hat mindestens 2 aktive Maintainer
>> - dokumentiert im Wiki die prinzipiellen Skills um den Service zu betreiben
>> - nimmt die Erfordernisse der Community an und richtet sich nach deren
>> Bedürfnissen
>> - hat ein Mitglied im Vorstand als Project Angel, dieser kommuniziert mit
>> den Maintainern um den Status des Services zu evaluieren
>> - wird einmal pro Monat im Vorstandsmeeting auf dessen Status reviewed.
>>   Die Hauptfaktoren hierbei sind:
>>   - Entspricht der Servie den Wünschen/Erfordernissen der Community?
>>   - Kümmern sich die Maintainer aktiv um den Service?
>>   - Werden Sicherheitsupdates aktiv bearbeitet?
>> - verwendet die Vereinsinfrastruktur und commited sich bei etwaigen
>> Änderungen aktiv an der Implementierung mitzuarbeiten (Compute, Network,
>> Storage)
>> - 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
>>   - 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.
>>   - Wenn ein Service Security Mängel aufweist kann diese Frist auch im
>> ermessen des Vorstandes verringert werden oder ggf. der Service offline
>> genommen werden bis der Übergang und die Mängel behoben werden konnten.
>> - Der Verein supported nur noch Core Services welche dem Vereinszweck
>> mittelbar dienen. Andere Services können ggf. durch zur Verfügungstellung
>> von Resourcen (sprich - Housing von Hardware und evt. Kauf dieser) 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.
>>
>>
>> Services
>> ---
>> - Backbone Network (Router, Switches, Anbindung, RIPE Database, Whois,
>> Bandwidth Monitoring & Accounting dzt. Flow & Cacti) -> Stefan Schultheis,
>> Wolfgang Nagele
>> - Roof Nodes (Zutrittsverwaltung, Physische Installation und Standard
>> Konfigurationen) -> Bernhard Marker, <DU?>
>> - Core Compute & Storage Infra (inkl. Central Logging, Authentication &
>> Monitoring) -> Adi Kriegisch, <DU?>
>> - Housing Environment (Temperatur Monitoring und Lüftung, Zutrittssystem,
>> Kamera Überwachung, Reinigung, Strom, Power Leisten, etc.) -> Michael Med,
>> <DU?>
>> - DNS (Reverse, Domains & Provisioning von diesen Zonen, Betrieb von
>> zumindest einem Recursive Resolver) -> <DU?>
>> - Mailserver & Mailing Listen -> Adi Kriegisch, <DU?>
>> - Tunnels (Anbindung von Inselknoten) -> <DU?>
>> - Housing Verwaltung (Billing, Verträge, etc.) -> Clemens Hopfer, <DU?>
>> - Node Map -> Erich N. Pekarek, <DU?>
>> - Node Monitoring (SmokePing) -> Bernhard Marker, <DU?>
>> - Node Datenbank (Nachfolger für dzt. Redeemer) -> <DU?>
>> - Website -> <DU?>
>> - Gallery -> <DU?>
>> - Wiki (inkl. internem Dokumentations Bereich) -> <DU?>
>> - Social Media (Twitter, Facebook, etc.) -> <DU?>
>>
>>
>> Commons Services
>> ---
>> - VoIP -> Christoph Loesch, <DU?>
>> - download.funkfeuer.at (-> mirror.funkfeuer.at) -> <DU?>
>> - Etherpad -> <DU?>
>>
>>
>> Auflassen/Umstellen
>> ---
>> - Member Mailer -> Soll in eine Standard Mailingliste integriert werden
>> - Shop -> Auflassen/Aufgelassen
>>
>>
>> Wenn wir zu diesem Draft Konsensus finden würde ich als nächste Schritte
>> vorschlagen:
>> 1. Arbeitstreffen um die einzelnen Services und deren Scope im Wiki zu
>> definieren inkl. dzt. Status.
>> 2. Arbeitstreffen um die zukünftige Core Infrastruktur (Compute, Storage und
>> Network) zu definieren und eine gemeinsame Basis zu schaffen.
>>
>> lg
>> Wolfgang