Governance & Community.
Wombat ist eine Community-getriebene, anbieterneutrale Initiative — mit klarer, transparenter Governance nach dem Vorbild etablierter Open-Source-Modelle wie der CNCF. Jede Entscheidung ist nachvollziehbar. Jede Rolle ist befristet.
Auf Dauer gebaut, standardmäßig offen.
Drei Prinzipien prägen die Governance von Wombat — schlank genug, um schnell voranzukommen, strukturiert genug, um zu skalieren.
Entscheidungen per RFC
Jede wesentliche Änderung durchläuft einen Request for Comments — öffentlich entworfen, von der Community geprüft und mit Begründung entschieden. Keine stillen Updates, keine undurchsichtigen Anbieterentscheidungen. Die Historie ist die Governance.
Transparent & nachvollziehbar
Roadmap, Diskussionen, Abstimmungen und Entscheidungen werden öffentlich auf GitHub dokumentiert. Alle können die Begründung nachvollziehen, eine Entscheidung hinterfragen oder eine Alternative vorschlagen — jedes Mal mit demselben Prozess.
Immer anbieterneutral
Kein einzelnes Unternehmen kontrolliert Wombat. Governance-Rollen folgen dem Prinzip „aktive Contributors zuerst“ und einer anbieterneutralen Balance. Die Zusammensetzung des TSC, die Chartas der Working Groups und die Advisory Group sichern dies by design ab.
Governance im Überblick.
Bewusst schlank, aber skalierbar — gemacht für eine wachsende Community. Entscheidungen laufen über RFCs, Reviews und dokumentierte Abstimmungen.
Transparenz: GitHub · RFCs · Sitzungsprotokolle
Governance-Modell (nach CNCF-Vorbild).
Sechs klar definierte Rollen und Mechanismen — jeweils mit eigenem Zuständigkeitsbereich, eigener Verantwortung und eigenem Prozess.
Technical Steering Committee
Verantwortlich für technische Ausrichtung, Architekturentscheidungen und die Freigabe von RFCs. Gewählt aus den aktiven Contributors. Verlängerbare Amtszeiten von 12 Monaten.
Maintainer-Team
Pflegt die zentralen Repositories, führt Reviews durch und sichert Konsistenz und Qualität. Für 12 Monate ernannt, verlängerbar je nach Aktivität.
Working Groups
Themenbezogene Gruppen für Säulen, Scoring, Controls und Referenzarchitekturen. Arbeiten offen über GitHub-Issues und RFCs. Jede und jeder kann eine WG vorschlagen.
User Advisory Group
Bringt Praxisperspektiven aus Projekten, Betrieb und Audits ein. Priorisiert Relevanz — sorgt dafür, dass das Framework die Realität in Produktion widerspiegelt, nicht nur Theorie.
Standardmäßig öffentlich
Roadmap, Diskussionen, Abstimmungen und Entscheidungen werden öffentlich und nachvollziehbar auf GitHub dokumentiert. Keine privaten Entscheidungskanäle für Framework-Änderungen.
RFC-Prozess
Entwurf → Prüfung durch die Community → Entscheidung → Umsetzung. Jede wesentliche Entscheidung wird begründet und mit ihrem Diskussions-Thread verknüpft.
Rollen, Amtszeiten & Erwartungen.
Klare Regeln machen Governance fair und berechenbar. So werden Entscheidungen getroffen und so funktionieren die Rollen.
Amtszeiten der Maintainer
Ernannt für 12 Monate, verlängerbar, wenn Engagement und Review-Aktivität vorhanden sind und keine begründeten Einwände bestehen.
Inaktivität: Nach 90 Tagen ohne Aktivität kann der Status nach einer Rückfrage und einem transparenten Hinweis auf „Emeritus“ gesetzt werden. Eine Reaktivierung ist jederzeit möglich.
Amtszeiten im TSC
TSC-Mitglieder amtieren 12 Monate lang, verlängerbar. Die Zusammensetzung folgt dem Prinzip „aktive Contributors zuerst“ und einer anbieterneutralen Balance. Rollen und Verantwortlichkeiten sind öffentlich dokumentiert.
Eine Working Group gründen
Jede und jeder kann eine WG vorschlagen. Erforderlich sind: eine Charta (Ziel, Umfang, Ergebnisse), Leitung(en), ein Kommunikationskanal und ein Maintainer als Pate.
Die Ergebnisse der WG fließen als PRs und RFCs in die Haupt-Repositories zurück.
Lazy Consensus
Für kleinere Änderungen: Ein Vorschlag wird öffentlich gestellt, mit 5 Werktagen Zeit zur Prüfung. Keine begründeten Einwände → angenommen.
Ein „Block“ muss begründet werden und eine alternative Lösung oder Anpassung vorschlagen.
Quorum & Abstimmung
Bei größeren Entscheidungen (neue Säule, Breaking Changes, Änderungen der Charta) stimmt das TSC ab:
- Quorum: mindestens 60% der aktiven TSC-Mitglieder
- Mehrheit: einfache Mehrheit der abgegebenen Stimmen
- Minimum: mindestens 3 Stimmen, wenn das TSC klein ist
- Konflikte: Mitglieder mit Interessenkonflikten enthalten sich
Erwartungen
Anbieterneutral handeln, Interessen der Community priorisieren, Entscheidungen dokumentieren, respektvoll kommunizieren (Verhaltenskodex) und Sicherheitsthemen verantwortungsvoll über die vorgesehenen Kanäle melden.
Wo werden Entscheidungen getroffen?
RFCs für größere Änderungen · ADRs und Notizen für Architekturentscheidungen · Issues und PRs für die Umsetzung. Jede Entscheidung verweist auf die Diskussion, die zu ihr geführt hat.
Wo sich die Community trifft.
Das Projekt entstand im Umfeld der Cloud Native Conference und der bestehenden CCC-Community. Das Ziel: Praxiserfahrung bündeln und offen weiterentwickeln.
Austausch auf Konferenzen — Talks, Panels und Birds-of-a-Feather-Sessions, in denen Engineers echte Herausforderungen und Patterns teilen.
Praxisworkshops zu Reifegradmodellen, Scoring und Umsetzung — Framework-Konzepte werden zu Engineering-Praxis.
Öffentliche Sessions zur Roadmap und zu offenen RFC-Entwürfen — alle können teilnehmen, kommentieren und mitgestalten, was als Nächstes entsteht.
So können Sie beitragen.
Es gibt keine Mindestgröße für Beiträge. Jeder geteilte Use Case, jedes Review und jeder RFC-Kommentar bringt das Framework voran.
Use Cases teilen
Vor welchen Herausforderungen stehen Sie in Cloud-Projekten? Welche Patterns funktionieren — und welche nicht? Praxiserfahrung ist der wertvollste Input für das Framework.
Kriterien & Controls vorschlagen
Input für Reifegradmodelle und Fragebögen: Was muss in jedem Fall geprüft werden? Neue Controls, Scoring-Kriterien und Assessment-Patterns beginnen hier.
Prüfen & Feedback geben
Prüfen Sie Architektur-Patterns und Referenzmodelle auf Konsistenz, Praxistauglichkeit und Abwägungen. Offene RFCs brauchen immer durchdachte Engineering-Perspektiven.
Dokumentation & Übersetzungen
Verbessern, erweitern und übersetzen Sie Inhalte in weitere Sprachen. Gute Dokumentation ist der halbe Wert — und immer gefragt.
Einer Working Group beitreten
Helfen Sie bei Säulen, Scoring, Controls oder Referenzarchitekturen — transparent auf GitHub. Working Groups sind der Weg, auf dem das Framework in fokussierten, verantwortlichen Sprints wächst.
Speaker & Sessions
Reichen Sie Themen bei CFPs ein, halten Sie Talks oder veranstalten Sie BoFs auf Konferenzen. Öffentlich präsentierte Praxisbeispiele prägen das Framework mehr als jeder RFC allein.
Nachvollziehbar, fair, offen.
Governance ist gelebte Praxis. Wir halten Prozesse schlank, aber klar — damit Wombat mit der Community wachsen kann, ohne an Verantwortlichkeit zu verlieren.