<div dir="ltr">Liebe Community,<div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div><div><br></div><div>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.</div><div><br></div><div><div>Memorandum of Understanding (MoU)</div><div>---</div><div>Jeder Service ...</div><div>- hat mindestens 2 aktive Maintainer</div><div>- dokumentiert im Wiki die prinzipiellen Skills um den Service zu betreiben</div><div>- nimmt die Erfordernisse der Community an und richtet sich nach deren Bedürfnissen</div><div>- hat ein Mitglied im Vorstand als Project Angel, dieser kommuniziert mit den Maintainern um den Status des Services zu evaluieren</div><div>- wird einmal pro Monat im Vorstandsmeeting auf dessen Status reviewed.</div><div>  Die Hauptfaktoren hierbei sind:</div><div>  - Entspricht der Servie den Wünschen/Erfordernissen der Community?</div><div>  - Kümmern sich die Maintainer aktiv um den Service?</div><div>  - Werden Sicherheitsupdates aktiv bearbeitet?</div><div>- verwendet die Vereinsinfrastruktur und commited sich bei etwaigen Änderungen aktiv an der Implementierung mitzuarbeiten (Compute, Network, Storage)</div><div>- 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>  - 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>  - 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.</div><div>- 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.</div><div><br></div><div><br></div><div>Services</div><div>---</div><div>- Backbone Network (Router, Switches, Anbindung, RIPE Database, Whois, Bandwidth Monitoring & Accounting dzt. Flow & Cacti) -> Stefan Schultheis, Wolfgang Nagele</div><div>- Roof Nodes (Zutrittsverwaltung, Physische Installation und Standard Konfigurationen) -> Bernhard Marker, <DU?></div><div>- Core Compute & Storage Infra (inkl. Central Logging, Authentication & Monitoring) -> Adi Kriegisch, <DU?></div><div>- Housing Environment (Temperatur Monitoring und Lüftung, Zutrittssystem, Kamera Überwachung, Reinigung, Strom, Power Leisten, etc.) -> Michael Med, <DU?></div><div>- DNS (Reverse, Domains & Provisioning von diesen Zonen, Betrieb von zumindest einem Recursive Resolver) -> <DU?></div><div>- Mailserver & Mailing Listen -> Adi Kriegisch, <DU?></div><div>- Tunnels (Anbindung von Inselknoten) -> <DU?></div><div>- Housing Verwaltung (Billing, Verträge, etc.) -> Clemens Hopfer, <DU?></div><div>- Node Map -> Erich N. Pekarek, <DU?></div><div>- Node Monitoring (SmokePing) -> Bernhard Marker, <DU?></div><div>- Node Datenbank (Nachfolger für dzt. Redeemer) -> <DU?></div><div>- Website -> <DU?></div><div>- Gallery -> <DU?></div><div>- Wiki (inkl. internem Dokumentations Bereich) -> <DU?></div><div>- Social Media (Twitter, Facebook, etc.) -> <DU?></div><div><br></div><div><br></div><div>Commons Services</div><div>---</div><div>- VoIP -> Christoph Loesch, <DU?></div><div>- <a href="http://download.funkfeuer.at">download.funkfeuer.at</a> (-> <a href="http://mirror.funkfeuer.at">mirror.funkfeuer.at</a>) -> <DU?></div><div>- Etherpad -> <DU?></div><div><br></div><div><br></div><div>Auflassen/Umstellen</div><div>---</div><div>- Member Mailer -> Soll in eine Standard Mailingliste integriert werden</div><div>- Shop -> Auflassen/Aufgelassen</div></div><div><br></div><div><br></div><div>Wenn wir zu diesem Draft Konsensus finden würde ich als nächste Schritte vorschlagen:</div><div>1. Arbeitstreffen um die einzelnen Services und deren Scope im Wiki zu definieren inkl. dzt. Status.</div><div>2. Arbeitstreffen um die zukünftige Core Infrastruktur (Compute, Storage und Network) zu definieren und eine gemeinsame Basis zu schaffen.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div>lg</div></div><div class="gmail_extra">Wolfgang</div></div>