Code
PRs & Issues
Bugs beheben, Controls implementieren, Tooling verbessern. Jeder PR wird von einem Maintainer gereviewed und mit einer Entscheidung verknüpft.
Open Source · Community
Mitmachen bei WAF++
WAF++ lebt von Beiträgen. Egal ob du Code schreibst, Dokumentation verbesserst, RFCs reviewst oder Erfahrungen aus echten Projekten teilst — jeder Beitrag prägt das Framework.
6 Wege zum Mitmachen
Kein Mindestbeitrag
Alles passiert öffentlich
Wie
Wege zum Mitmachen
Code, Inhalte, Community — wähle, was zu deinen Fähigkeiten und deiner Zeit passt.
Inhalte
Docs & Patterns
Pillar-Dokumentation, Referenzarchitekturen, Best-Practice-Patterns oder konkrete Beispiele aus echten Projekten schreiben.
Review
RFC Reviews
Offene RFCs kommentieren, Alternativen vorschlagen oder über Framework-Entscheidungen abstimmen. Jede Stimme zählt — besonders Praxiserfahrung.
Übersetzung
Lokalisierung
Inhalte ins Deutsche, Englische oder weitere Sprachen übersetzen. WAF++ soll für die globale Cloud-Community zugänglich sein.
Community
Working Groups
An einer Working Group rund um einen Pillar, ein Scoring-Modell, eine Controls Library oder eine Referenzarchitektur teilnehmen oder eine neue gründen.
Events
Talks & BoFs
WAF++ auf einer Konferenz präsentieren, eine Birds-of-a-Feather-Session veranstalten oder einen Community-Workshop durchführen. Praxiserfahrung ist Gold wert.
Erste Schritte
So fängst du an
Vier Schritte vom Einstieg zum Beitrag.
1
GitHub-Organisation erkunden
Offene Issues mit dem Label good first issue oder help wanted bei github.com/waf2p durchsuchen. Noch kein passendes Issue? Einfach eines öffnen und beschreiben, was du angehen möchtest.
2
Auf Slack vorstellen
Der Community auf Slack beitreten, in #general Hallo sagen, Fragen stellen und herausfinden, welche Working Group zum eigenen Hintergrund und Interesse passt.
3
Fork → Branch → PR
Das relevante Repository forken, einen Feature-Branch erstellen und einen Pull Request öffnen. Ein Maintainer wird ihn reviewen, Feedback geben und durch den Prozess führen.
4
Größere Änderungen? Erst einen RFC öffnen
Für neue Pillars, Breaking Changes, Scoring-Änderungen oder Governance-Updates: zuerst einen RFC in GitHub Discussions verfassen. Die Community reviewt ihn, bevor die Implementierung beginnt. So bleiben Entscheidungen nachvollziehbar.
Zusammenarbeit
Working Groups
Working Groups sind themenspezifische Teams, die bestimmte Teile von WAF++ aufbauen. Jeder kann eine WG vorschlagen — alles was es braucht ist ein Charter, mindestens ein Lead und ein Maintainer-Sponsor.
Eine WG finden
Offene WG-Vorschläge in GitHub Discussions prüfen und dem passenden Kanal auf Slack beitreten. Mitmachen ist auch ohne Vollzeit-Engagement möglich.
Eine WG gründen
Ein Charter in einer GitHub Discussion verfassen, einen Maintainer-Sponsor finden und auf Slack ankündigen. WGs können sich auf jeden Scope konzentrieren: einen Pillar, eine Tooling-Frage, einen Scoring-Ansatz.
Resultate liefern
WG-Outputs fließen als PRs und RFCs zurück. Jedes Ergebnis ist öffentlich, nachvollziehbar und zitierbar — konsistent mit den Transparenz-Prinzipien von WAF++.
Verfügbarkeit
Feature-Lifecycle
Jede WAF++-Fähigkeit durchläuft einen klaren Lifecycle. Jede Phase wird durch den RFC/ADR-Prozess geprüft — damit Nutzer immer wissen, wie ausgereift eine Funktion ist und was vor der Einführung zu erwarten ist.
Privat erproben
Eine kleine Gruppe von Early Adopters testet die Fähigkeit in kontrollierten Umgebungen. API, Scoring-Modell oder CLI-Oberfläche sind absichtlich instabil und können sich jederzeit ändern.
Wie sie entsteht
- Draft- oder Open-RFC definiert das Experiment
- Einladungsbasierter Early-Access-Kreis
- Feedback treibt schnelle Iterationen an
Öffentlich testen
Die Fähigkeit steht allen zur Verfügung, die sie ausprobieren möchten. Schnittstellen sind weitgehend stabil, aber Breaking Changes sind auf Basis von Community-Feedback noch möglich.
Wie sie entsteht
- RFC mit Alpha-Scope akzeptiert
- Öffentliche Docs und Release Notes verfügbar
- GitHub Discussions sammeln Feedback
Produktiv nutzen
Die Fähigkeit ist feature-complete und für die dokumentierten Use Cases produktionsreif. Kleine Anpassungen können noch passieren, aber Breaking Changes erfordern explizite Migrationshinweise.
Wie sie entsteht
- RFC akzeptiert und Implementierung gemergt
- ADR dokumentiert die Produktionsreife-Kriterien
- Security-, Performance- und Kompatibilitäts-Review bestanden
General Availability
Die Fähigkeit wird vollständig unterstützt, ist durch die Stabilitätsrichtlinie abgedeckt und wird allen Nutzern empfohlen. Updates bleiben abwärtskompatibel und haben klare Abschreibungsfenster.
Wie sie entsteht
- RFC-Status wechselt zu implemented
- Finale ADR besiegelt den stabilen Vertrag
- Aufnahme in den offiziellen Release-Zug
Jede Phase ist mit dem RFC/ADR-Prozess verknüpft. Wenn ein RFC akzeptiert wird, öffnet sich das Alpha- oder Beta-Gate; wenn er als implemented markiert ist, ist die Fähigkeit GA-reif. Den vollständigen Überblick gibt es im RFC-Tracker oder schlage die nächste Änderung in den GitHub Discussions vor.
Prozess
Der RFC-Prozess
Wesentliche Änderungen durchlaufen einen RFC (Request for Comments). Der Prozess ist schlank, stellt aber sicher, dass jede Entscheidung community-gereviewed und dokumentiert ist.
Entwurf
GitHub Discussion mit dem Vorschlag öffnen
→
Review
Community & Maintainer kommentieren und verfeinern
→
Entscheidung
TSC oder Lazy Consensus — öffentlich dokumentiert
→
Umsetzung
PR gemergt, Changelog aktualisiert
Bereit loszulegen?
Kein Beitrag ist zu klein.
Ein Tippfehler-Fix, ein klärender Kommentar, ein Review — alles treibt das Framework voran. WAF++ wird öffentlich gebaut und die Community ist immer offen.