RFC Tracker
Jede wesentliche Änderung an WAF++ beginnt mit einem öffentlichen Request for Comments. Diese Seite verfolgt jeden RFC — vom ersten Entwurf bis zum Merge — damit jede Entscheidung nachvollziehbar bleibt.
Alle Requests for Comments
Nach Status filtern, Zusammenfassungen lesen und den verlinkten Diskussionen sowie Pull Requests folgen.
Legt das grundlegende Sieben-Säulen-Modell als Basis von WAF++ fest: Sicherheit, Zuverlässigkeit, Performance-Effizienz, Kostenoptimierung, Operationelle Exzellenz, Nachhaltigkeit und Developer Experience. Durch RFC-0012 auf acht Säulen erweitert.
Definiert die öffentliche Roadmap für 2026 mit Q1–Q4-Meilensteinen, v1.0-Ziel, Pilotprogramm und Foundation-Readiness-Zielen.
Fügt die initiale Inhaltsdefinition für jede der 7 Säulen hinzu: Scope, Begründung und Kernbewertungsfragen. Bildet die Basis für die Controls Library und wurde später um die 8. Säule Agentic erweitert (RFC-0012).
Migriert die gesamte Framework-Dokumentation von Markdown nach AsciiDoc und etabliert Antora als Dokumentations-Build-System mit Komponenten-Versionierung (v1.0).
Fügt dem Framework-Repository die Standard-Open-Source-Health-Dateien hinzu: Beitragsrichtlinien, Verhaltenskodex (basierend auf Contributor Covenant v2.1) und Sicherheitsrichtlinie.
Führt den Sovereign-Pillar als 7. Säule von WAF++ ein — Datensouveränität, Compliance und jurisdiktionale Kontrolle. Liefert 10 initiale Controls (WAF-SOV-010 bis WAF-SOV-100).
Strukturiert den Governance-Pillar (Säule 7) in modulare Best-Practice-Seiten um, ergänzt Fallstudien-Inhalte und aktualisiert die Antora-Navigation für bessere Auffindbarkeit und Lesbarkeit.
Definiert ein formales Schema für WAF++-Controls-YAML-Dateien, das konsistente Validierung, Tool-Integration und die Nutzung der 83+ Controls Library durch Dritte ermöglicht. Mit der v1.0-Release ausgeliefert.
Formalisiert das PASS-Scoring-Modell als normative Spezifikation: Tier-Definitionen, Berechnungsregeln, Aggregationslogik und Versionierungsvertrag. Voraussetzung für und ausgeliefert mit WAFPass CLI / Server v1.0.0.
Definiert den Ansatz für das offizielle WAF++-Assessment-Tooling: WAFPass CLI, Server, Dashboard und Web-Scorecard, die die Controls Library nutzen und einen PASS-Score-Bericht erzeugen. Mit WAFPass v1.0.0 ausgeliefert und in v1.1.0 erweitert.
Führt automatisierte Checks und Release-Workflows für die Repositories framework, pass, wafpass-server und wafpass-dashboard ein: Antora-Build-Validierung, Controls-YAML-Linting, Release-Automatisierung und Link-Prüfung bei jedem Pull Request.
Fügt den Agentic-Pillar (WAF-AGN) als 8. Säule von WAF++ hinzu — Governance autonomer KI-Agenten. Liefert 10 initiale Controls (WAF-AGN-010 bis WAF-AGN-100), regulatorische Mappings sowie englische und deutsche Dokumentation. Erweitert das Framework auf 8 Säulen und 83+ Controls.
Erweitert WAFPass CLI, Server und Dashboard, um die Agentic-Pillar-Controls (WAF-AGN-*) im Rahmen einer vollständigen PASS-Bewertung auszuwerten. Vor der WAFPass-v1.1.0-Release gemergt.
Veröffentlicht WAFPass CLI v1.1.0, WAFPass Server v1.1.0 und WAFPass Dashboard v1.1.0 mit Unterstützung für Säule-8 Agentic, Korrekturen bei der Erkennung und SINA-Cloud-Region-Erkennung. Abgestimmt auf Framework v1.1 und die 83+ Controls Library.
Rollt das radical dunkle Design-System auf die verbleibenden öffentlichen Seiten (RFC-Tracker, Team, Rollen, About, Press, Install) aus, sodass die gesamte Website eine konsistente visuelle Sprache und Barrierefreiheitsmuster verwendet.
Standardisiert maschinen- und menschenlesbare Remediation-Anleitungen für jeden WAF++-Control, damit Betriebsteams direkt aus einem PASS-Bericht oder Dashboard handeln können.
Definiert, wie WAFPass-Erkennung und Controls um Azure, GCP und weitere Cloud-Provider erweitert werden, während das Framework cloud-agnostic bleibt.
Rollt das radical dunkle Design-System auf die verbleibenden öffentlichen Seiten (RFC-Tracker, Team, Rollen, About, Press, Install) aus, sodass die gesamte Website eine konsistente visuelle Sprache und Barrierefreiheitsmuster verwendet.
Standardisiert maschinen- und menschenlesbare Remediation-Anleitungen für jeden WAF++-Control, damit Betriebsteams direkt aus einem PASS-Bericht oder Dashboard handeln können.
Definiert, wie WAFPass-Erkennung und Controls um Azure, GCP und weitere Cloud-Provider erweitert werden, während das Framework cloud-agnostic bleibt.
Legt das grundlegende Sieben-Säulen-Modell als Basis von WAF++ fest: Sicherheit, Zuverlässigkeit, Performance-Effizienz, Kostenoptimierung, Operationelle Exzellenz, Nachhaltigkeit und Developer Experience. Durch RFC-0012 auf acht Säulen erweitert.
Definiert die öffentliche Roadmap für 2026 mit Q1–Q4-Meilensteinen, v1.0-Ziel, Pilotprogramm und Foundation-Readiness-Zielen.
Fügt die initiale Inhaltsdefinition für jede der 7 Säulen hinzu: Scope, Begründung und Kernbewertungsfragen. Bildet die Basis für die Controls Library und wurde später um die 8. Säule Agentic erweitert (RFC-0012).
Migriert die gesamte Framework-Dokumentation von Markdown nach AsciiDoc und etabliert Antora als Dokumentations-Build-System mit Komponenten-Versionierung (v1.0).
Fügt dem Framework-Repository die Standard-Open-Source-Health-Dateien hinzu: Beitragsrichtlinien, Verhaltenskodex (basierend auf Contributor Covenant v2.1) und Sicherheitsrichtlinie.
Führt den Sovereign-Pillar als 7. Säule von WAF++ ein — Datensouveränität, Compliance und jurisdiktionale Kontrolle. Liefert 10 initiale Controls (WAF-SOV-010 bis WAF-SOV-100).
Strukturiert den Governance-Pillar (Säule 7) in modulare Best-Practice-Seiten um, ergänzt Fallstudien-Inhalte und aktualisiert die Antora-Navigation für bessere Auffindbarkeit und Lesbarkeit.
Definiert ein formales Schema für WAF++-Controls-YAML-Dateien, das konsistente Validierung, Tool-Integration und die Nutzung der 83+ Controls Library durch Dritte ermöglicht. Mit der v1.0-Release ausgeliefert.
Formalisiert das PASS-Scoring-Modell als normative Spezifikation: Tier-Definitionen, Berechnungsregeln, Aggregationslogik und Versionierungsvertrag. Voraussetzung für und ausgeliefert mit WAFPass CLI / Server v1.0.0.
Definiert den Ansatz für das offizielle WAF++-Assessment-Tooling: WAFPass CLI, Server, Dashboard und Web-Scorecard, die die Controls Library nutzen und einen PASS-Score-Bericht erzeugen. Mit WAFPass v1.0.0 ausgeliefert und in v1.1.0 erweitert.
Führt automatisierte Checks und Release-Workflows für die Repositories framework, pass, wafpass-server und wafpass-dashboard ein: Antora-Build-Validierung, Controls-YAML-Linting, Release-Automatisierung und Link-Prüfung bei jedem Pull Request.
Fügt den Agentic-Pillar (WAF-AGN) als 8. Säule von WAF++ hinzu — Governance autonomer KI-Agenten. Liefert 10 initiale Controls (WAF-AGN-010 bis WAF-AGN-100), regulatorische Mappings sowie englische und deutsche Dokumentation. Erweitert das Framework auf 8 Säulen und 83+ Controls.
Erweitert WAFPass CLI, Server und Dashboard, um die Agentic-Pillar-Controls (WAF-AGN-*) im Rahmen einer vollständigen PASS-Bewertung auszuwerten. Vor der WAFPass-v1.1.0-Release gemergt.
Veröffentlicht WAFPass CLI v1.1.0, WAFPass Server v1.1.0 und WAFPass Dashboard v1.1.0 mit Unterstützung für Säule-8 Agentic, Korrekturen bei der Erkennung und SINA-Cloud-Region-Erkennung. Abgestimmt auf Framework v1.1 und die 83+ Controls Library.
Eine Änderung vorschlagen?
Eine GitHub Discussion mit dem RFC-Template eröffnen. Die Community prüft es, Maintainer entscheiden — alles ist dokumentiert und nachvollziehbar.
Was qualifiziert sich als RFC?
Nicht jede Änderung braucht einen RFC — nur wesentliche. Die folgende Tabelle hilft bei der Entscheidung.
| Änderungstyp | RFC erforderlich? | Prozess |
|---|---|---|
| Neue Säule oder Entfernung einer Säule | Ja | RFC → TSC-Abstimmung → PR |
| Änderungen am Scoring-Modell (PASS-Tiers, Gewichtungen) | Ja | RFC → TSC-Abstimmung → PR |
| Breaking Changes am Controls-Schema oder IDs | Ja | RFC → TSC-Abstimmung → PR |
| Neuer Working-Group-Vorschlag | Ja | RFC → Lazy Consensus → Charter veröffentlicht |
| Governance- oder Rollenänderungen | Ja | RFC → TSC-Supermehrheit |
| Neuer Control (nicht-breaking, additiv) | Empfohlen | PR mit Diskussionslink · Lazy Consensus |
| Docs-Wording, Tippfehler, Übersetzungen | Nein | Nur PR |
| Website-Inhalte, Blog-Beiträge | Nein | Nur PR |
RFC-Status-Ablauf
Jeder RFC folgt demselben dokumentierten Pfad — vom ersten Entwurf bis zur geschlossenen Entscheidung.
Was einen guten RFC ausmacht
Drei Dinge, die den Unterschied machen zwischen einem RFC, der schnell vorankommt, und einem, der stagniert.
Problem beschreiben, nicht die Lösung
Beginne damit, was fehlt oder nicht funktioniert — nicht damit, was du bauen willst. Reviewer müssen zuerst dem Problem zustimmen, bevor sie eine Lösung beurteilen können. Das „Warum“ kommt vor dem „Was“.
Trade-offs explizit benennen
Jede Entscheidung hat Kosten. Benenne sie. Was wird schlechter? Welche Alternativen hast du erwogen? Ein RFC, der Trade-offs anerkennt, gewinnt Vertrauen schneller als einer, der nur Vorteile verkauft.
Auf Evidenz verweisen
Verweise auf echte Beispiele — Issues, Vorfälle, frühere Diskussionen oder Produktionsmuster. Evidenz verwandelt Meinungen in nachvollziehbare Fakten und verkürzt den Review-Zyklus erheblich.
Starte heute einen RFC.
Eröffne eine Diskussion auf GitHub, folge dem Template und lass den Prozess den Rest erledigen. Keine vorherige Genehmigung nötig — nur eine klare Problembeschreibung.