[Discuss] WICHTIG: Vereins Services - ein neuer Ansatz

So Mär 19 18:51:44 CET 2017

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