RFC Tracker
Jede wesentliche Änderung an WAF++ beginnt mit einem öffentlichen Request for Comments. Diese Seite verfolgt jeden RFC — von der Entwurfsphase bis zur Umsetzung — damit Entscheidungen immer nachvollziehbar sind.
Legt das grundlegende Sieben-Säulen-Modell als Basis von WAF++ fest: Sicherheit, Zuverlässigkeit, Performance-Effizienz, Kostenoptimierung, Operationelle Exzellenz, Nachhaltigkeit und Developer Experience.
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.
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).
Definiert ein formales JSON-Schema für WAF++-Controls-YAML-Dateien, das konsistente Validierung, Tool-Integration und die Nutzung der Controls Library durch Dritte ermöglicht.
Formalisiert das PASS-Scoring-Modell als normative Spezifikation: Tier-Definitionen, Berechnungsregeln, Aggregationslogik und Versionierungsvertrag. Voraussetzung für die v1.0-Stabilitätsgarantie.
Definiert den Ansatz für das offizielle WAF++-Assessment-Tooling: ein CLI-Tool und/oder Web-Scorecard, das die Controls Library nutzt und einen PASS-Score-Bericht erzeugt.
Führt automatisierte Checks für das Framework-Repository ein: Antora-Build-Validierung, Controls-YAML-Linting und Link-Prüfung bei jedem Pull Request.
Definiert ein formales JSON-Schema für WAF++-Controls-YAML-Dateien, das konsistente Validierung, Tool-Integration und die Nutzung der Controls Library durch Dritte ermöglicht.
Formalisiert das PASS-Scoring-Modell als normative Spezifikation: Tier-Definitionen, Berechnungsregeln, Aggregationslogik und Versionierungsvertrag. Voraussetzung für die v1.0-Stabilitätsgarantie.
Definiert den Ansatz für das offizielle WAF++-Assessment-Tooling: ein CLI-Tool und/oder Web-Scorecard, das die Controls Library nutzt und einen PASS-Score-Bericht erzeugt.
Führt automatisierte Checks für das Framework-Repository ein: Antora-Build-Validierung, Controls-YAML-Linting und Link-Prüfung bei jedem Pull Request.
Legt das grundlegende Sieben-Säulen-Modell als Basis von WAF++ fest: Sicherheit, Zuverlässigkeit, Performance-Effizienz, Kostenoptimierung, Operationelle Exzellenz, Nachhaltigkeit und Developer Experience.
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.
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).
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.
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".
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.
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.