Governance & Community
WAF++ ist ein community-getriebenes, vendor-neutrales Nonprofit-Projekt – mit klarer, transparenter Governance in Anlehnung an etablierte Open-Source-Modelle (z. B. CNCF).
Entscheidungen werden nachvollziehbar über RFCs, Reviews und dokumentierte Abstimmungen getroffen. Die Struktur ist bewusst schlank, aber skalierbar – passend für eine wachsende Community.
Technical Steering Committee
Verantwortlich für technische Ausrichtung, Architekturentscheidungen und RFC-Freigaben.
Maintainer-Team
Pflegt zentrale Repositories, führt Reviews durch und stellt Konsistenz/Qualität sicher.
Working Groups
Thematische Arbeitsgruppen (z. B. Säulen, Scoring, Controls). Arbeiten offen über Issues/RFCs.
User Advisory Group
Bringt Praxisperspektive aus Projekten, Betrieb und Audits ein und priorisiert Relevanz.
Transparenz
Roadmap, Diskussionen und Entscheidungen sind öffentlich nachvollziehbar dokumentiert.
RFC-Prozess
Draft → Community Review → Entscheidung → Umsetzung. Jede Entscheidung wird begründet.
Maintainer Terms
Maintainers werden für 12 Monate ernannt (renewable). Eine Verlängerung erfolgt, wenn Engagement und Review-Aktivität gegeben sind und keine begründeten Einwände vorliegen.
Inaktivität: Bei 90 Tagen ohne Aktivität kann der Status auf „emeritus“ gesetzt werden (nach Ping & transparenter Notiz). Reaktivierung ist jederzeit möglich.
TSC Terms
TSC-Mitglieder haben ebenfalls 12 Monate Term (renewable). Zusammensetzung folgt dem Prinzip „active contributors first“ und vendor-neutraler Balance. Rollen/Responsibilities sind öffentlich dokumentiert.
Working Groups starten
Jede:r kann eine WG vorschlagen. Minimaler Inhalt: Charter (Ziel, Scope, Deliverables), Lead(s), Kommunikationskanal und ein Maintainer Sponsor.
WG-Outputs laufen als PRs/RFCs in die Haupt-Repos zurück.
Lazy Consensus
Für kleinere Änderungen gilt Lazy Consensus: Vorschlag wird öffentlich gepostet, 5 Werktage Review-Zeit. Keine begründeten Einwände → angenommen.
Ein „Block“ muss begründet sein und eine alternative Lösung/Anpassung vorschlagen.
Quorum & Abstimmungen
Für größere Entscheidungen (z. B. neue Säule, Breaking Changes, Charter-Änderungen) gilt Voting im TSC:
- Quorum: mindestens 60% der aktiven TSC-Mitglieder stimmen ab
- Mehrheit: einfache Mehrheit der abgegebenen Stimmen
- Minimum: mindestens 3 Stimmen, falls TSC klein ist
- Conflicts: bei Interessenkonflikt enthält man sich und wird nicht fürs Quorum gezählt
Erwartungen
Vendor-neutral handeln, Community-Interessen priorisieren, Entscheidungen dokumentieren, respektvoller Umgang (Code of Conduct) und Security-themen verantwortungsvoll melden.
Was wird wo entschieden?
Damit Governance „auditierbar“ bleibt, nutzen wir wiederholbare Templates: RFCs für größere Änderungen, ADRs/Notes für Architekturentscheidungen, Issues/PRs für Umsetzung. Jede Entscheidung referenziert die Diskussion.
RFCs & Entscheidungen auf GitHub →Das Projekt startet im Rahmen der Cloud Native Conference und der bestehenden CCC-Community. Ziel ist es, Erfahrung zu bündeln und öffentlich weiterzuentwickeln.
Sessions & BoFs
Austausch auf Konferenzen – Talks, Panels und Birds-of-a-Feather Sessions.
Workshops
Gemeinsame Workshops zu Reifegradmodellen, Scoring und praxisnaher Umsetzung.
Roadmap- & RFC-Sessions
Öffentliche Sessions zur Roadmap und zu offenen RFC-Entwürfen.
Use Cases teilen
Welche Herausforderungen habt ihr in Cloud-Projekten? Welche Patterns funktionieren (nicht)?
Fragen & Kriterien vorschlagen
Input für Reifegradmodell und Fragebögen: was muss zwingend geprüft werden?
Review & Feedback
Review zu Architektur-Patterns und Referenzmodellen: Konsistenz, Praxisnähe, Tradeoffs.
Dokumentation & Übersetzungen
Inhalte verbessern, erweitern und in weitere Sprachen übertragen.
Working Group beitreten
Hilf bei Säulen, Scoring, Controls oder Referenzarchitekturen – transparent auf GitHub.
Speaker & Sessions
Bring Themen in CFPs ein, halte Talks oder moderiere BoFs – Praxisbeispiele sind Gold.
