Governance & Community
WAF++ ist eine community-getriebene, vendor-neutrale Initiative — mit klarer, transparenter Governance angelehnt an etablierte Open-Source-Modelle wie CNCF. Jede Entscheidung ist nachvollziehbar. Jede Rolle hat eine Amtszeit.
Gebaut zum Bleiben, offen von Anfang an
Drei Prinzipien, die die Governance von WAF++ prägen — leichtgewichtig genug, um schnell zu sein; strukturiert genug, um zu skalieren.
Jede wesentliche Änderung durchläuft einen Request for Comments — öffentlich ausgearbeitet, von der Community geprüft und mit Begründung entschieden. Keine stillen Updates, keine intransparenten Vendor-Entscheidungen. Die Geschichte ist die Governance.
Roadmap, Diskussionen, Abstimmungen und Entscheidungen sind öffentlich auf GitHub dokumentiert. Jede Person kann die Begründung nachverfolgen, eine Entscheidung anfechten oder eine Alternative vorschlagen — immer mit demselben Prozess.
Kein einzelnes Unternehmen kontrolliert WAF++. Governance-Rollen folgen dem Prinzip "aktive Contributor zuerst" und vendor-neutraler Balance. TSC-Zusammensetzung, Working-Group-Charters und Advisory Group setzen das strukturell um.
Governance auf einen Blick
Bewusst schlank, aber skalierbar — für eine wachsende Community. Entscheidungen fließen durch RFCs, Reviews und dokumentierte Abstimmungen.
Governance-Modell (CNCF-inspiriert)
Sechs klar definierte Rollen und Mechanismen — jede mit eigenem Umfang, Verantwortung und Prozess.
Verantwortlich für technische Richtung, Architekturentscheidungen und RFC-Genehmigungen. Gewählt aus aktiven Contributoren. 12-monatige, verlängerbare Amtszeiten.
Pflegt die Kern-Repositories, führt Reviews durch und gewährleistet Konsistenz und Qualität. Ernannt für 12 Monate, verlängerbar je nach Aktivität.
Themenfokussierte Gruppen für Säulen, Scoring, Controls und Referenzarchitekturen. Arbeiten offen via GitHub Issues und RFCs. Jede Person kann eine WG vorschlagen.
Bringt Praxis-Perspektiven aus Projekten, Betrieb und Audits ein. Sorgt dafür, dass das Framework Produktionsrealität widerspiegelt — nicht nur Theorie.
Roadmap, Diskussionen, Abstimmungen und Entscheidungen sind öffentlich auf GitHub dokumentiert und nachvollziehbar. Keine privaten Entscheidungskanäle für Framework-Änderungen.
Entwurf → Community-Review → Entscheidung → Umsetzung. Jede wesentliche Entscheidung ist begründet und mit dem Diskussions-Thread verknüpft.
Rollen, Amtszeiten & Erwartungen
Klare Regeln machen Governance fair und vorhersehbar. Hier steht genau, wie Entscheidungen getroffen werden und wie Rollen funktionieren.
Maintainer-Amtszeiten
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 Anfrage auf "Emeritus" gesetzt werden. Reaktivierung ist jederzeit möglich.
TSC-Amtszeiten
TSC-Mitglieder haben 12-monatige Amtszeiten, verlängerbar. Die Zusammensetzung folgt "aktive Contributor zuerst" und vendor-neutraler Balance. Rollen und Verantwortlichkeiten sind öffentlich dokumentiert.
Eine Working Group gründen
Jede Person kann eine WG vorschlagen. Erforderlich: ein Charter (Ziel, Umfang, Deliverables), Lead(s), ein Kommunikationskanal und ein Maintainer-Sponsor.
WG-Ergebnisse fließen als PRs und RFCs in die Haupt-Repositories zurück.
Lazy Consensus
Für kleinere Änderungen: Ein Vorschlag wird öffentlich gepostet mit 5 Werktagen für Review. Keine begründeten Einwände → angenommen.
Ein "Veto" muss begründet sein und eine alternative Lösung oder Anpassung vorschlagen.
Quorum & Abstimmung
Für größere Entscheidungen (neue Säule, Breaking Changes, Charter-Änderungen) stimmt das TSC ab:
- Quorum: mindestens 60 % der aktiven TSC-Mitglieder
- Mehrheit: einfache Mehrheit der abgegebenen Stimmen
- Minimum: mindestens 3 Stimmen bei kleinem TSC
- Interessenskonflikte: Betroffene Mitglieder enthalten sich
Erwartungen
Vendor-neutral handeln, Community-Interessen priorisieren, Entscheidungen dokumentieren, respektvoll kommunizieren (Code of Conduct) und Sicherheitsthemen verantwortungsvoll über die definierten Kanäle melden.
Wo werden Entscheidungen getroffen?
RFCs für größere Änderungen · ADRs und Protokolle für Architekturentscheidungen · Issues und PRs für Umsetzung. Jede Entscheidung verweist auf die Diskussion, die zu ihr geführt hat.
Wo die Community zusammenkommt
Das Projekt entstand im Kontext der Cloud Native Conference und der bestehenden CCC-Community. Ziel: Praxiserfahrung bündeln und offen in der Öffentlichkeit weiterentwickeln.
Austausch auf Konferenzen — Talks, Panels und Birds-of-a-Feather-Sessions, bei denen Engineers reale Herausforderungen und Muster teilen.
Praxisnahe Workshops zu Reifegradmodellen, Scoring und Implementierung — Framework-Konzepte werden zu Engineering-Praxis.
Öffentliche Sessions zur Roadmap und offenen RFC-Entwürfen — jede Person kann teilnehmen, kommentieren und mitgestalten, was als Nächstes gebaut wird.
Wie du beitragen kannst
Es gibt keine Mindestbeitragsgröße. Jeder geteilte Use Case, jedes gegebene Review, jeder kommentierte RFC bringt das Framework voran.
Welche Herausforderungen begegnen dir in Cloud-Projekten? Welche Muster funktionieren — und welche nicht? Praxiserfahrung ist der wertvollste Input, den das Framework bekommen kann.
Input für Reifegradmodelle und Fragebögen: Was muss immer geprüft werden? Neue Controls, Scoring-Kriterien und Assessment-Muster entstehen hier.
Architekturmuster und Referenzmodelle auf Konsistenz, Praxistauglichkeit und Trade-offs prüfen. Offene RFCs brauchen immer durchdachte Engineering-Perspektiven.
Inhalte verbessern, erweitern und in weitere Sprachen übersetzen. Gute Dokumentation ist die halbe Miete — und immer gefragt.
An Säulen, Scoring, Controls oder Referenzarchitekturen mitarbeiten — transparent auf GitHub. Working Groups sind der Weg, wie das Framework in fokussierten, rechenschaftspflichtigen Sprints wächst.
Themen zu CFPs einreichen, Talks halten oder BoFs auf Konferenzen moderieren. Öffentlich präsentierte Praxisbeispiele prägen das Framework mehr als jeder RFC allein.
Nachvollziehbar. Fair. Offen.
Governance ist gelebte Praxis. Wir halten Prozesse leichtgewichtig, aber klar — damit WAF++ mit der Community wachsen kann, ohne Rechenschaftspflicht zu verlieren.
