RFC Tracker
Every significant change to WAF++ starts with a public Request for Comments. This page tracks every RFC — draft through implementation — so decisions are always traceable.
Establishes the core seven-pillar model as the foundational structure of WAF++, covering Security, Reliability, Performance Efficiency, Cost Optimisation, Operational Excellence, Sustainability, and Developer Experience.
Defines the public roadmap for 2026 covering Q1–Q4 milestones, including v1.0 target, pilot programme, and foundation readiness goals.
Adds the initial content definition for each of the 7 pillars: scope, rationale, and key assessment questions. Serves as the baseline for the controls library.
Migrates all framework documentation from Markdown to AsciiDoc and establishes Antora as the documentation build system with component versioning (v1.0).
Adds the standard open-source health files to the framework repository: contribution guidelines, code of conduct (based on Contributor Covenant v2.1), and security policy.
Introduces the Sovereign pillar as the 7th pillar of WAF++, covering data sovereignty, compliance, and jurisdictional control. Ships with 10 initial controls (WAF-SOV-010 through WAF-SOV-100).
Defines a formal JSON Schema for WAF++ controls YAML files, enabling consistent validation, tooling integration, and third-party consumption of the controls library.
Formalises the PASS scoring model as a normative specification: tier definitions, calculation rules, aggregation logic, and versioning contract. Required for v1.0 stability guarantee.
Defines the approach for official WAF++ assessment tooling: a CLI tool and/or web scorecard that consumes the controls library and produces a PASS score report.
Introduces automated checks for the framework repository: Antora build validation, controls YAML linting, and link checking on every pull request.
Defines a formal JSON Schema for WAF++ controls YAML files, enabling consistent validation, tooling integration, and third-party consumption of the controls library.
Formalises the PASS scoring model as a normative specification: tier definitions, calculation rules, aggregation logic, and versioning contract. Required for v1.0 stability guarantee.
Defines the approach for official WAF++ assessment tooling: a CLI tool and/or web scorecard that consumes the controls library and produces a PASS score report.
Introduces automated checks for the framework repository: Antora build validation, controls YAML linting, and link checking on every pull request.
Establishes the core seven-pillar model as the foundational structure of WAF++, covering Security, Reliability, Performance Efficiency, Cost Optimisation, Operational Excellence, Sustainability, and Developer Experience.
Defines the public roadmap for 2026 covering Q1–Q4 milestones, including v1.0 target, pilot programme, and foundation readiness goals.
Adds the initial content definition for each of the 7 pillars: scope, rationale, and key assessment questions. Serves as the baseline for the controls library.
Migrates all framework documentation from Markdown to AsciiDoc and establishes Antora as the documentation build system with component versioning (v1.0).
Adds the standard open-source health files to the framework repository: contribution guidelines, code of conduct (based on Contributor Covenant v2.1), and security policy.
Introduces the Sovereign pillar as the 7th pillar of WAF++, covering data sovereignty, compliance, and jurisdictional control. Ships with 10 initial controls (WAF-SOV-010 through WAF-SOV-100).
Want to propose a change?
Open a GitHub Discussion using the RFC template. The community reviews it, maintainers decide — everything is documented and traceable.
What qualifies as an RFC?
Not every change needs an RFC — only significant ones. Use the table below to decide.
| Change type | RFC needed? | Process |
|---|---|---|
| New pillar or removal of a pillar | Yes | RFC → TSC vote → PR |
| Scoring model changes (PASS tiers, weights) | Yes | RFC → TSC vote → PR |
| Breaking change to controls schema or IDs | Yes | RFC → TSC vote → PR |
| New Working Group proposal | Yes | RFC → lazy consensus → charter published |
| Governance or role changes | Yes | RFC → TSC supermajority |
| New control (non-breaking, additive) | Recommended | PR with discussion link · lazy consensus |
| Docs wording, typo fixes, translations | No | PR only |
| Website content, blog posts | No | PR only |
RFC status flow
Every RFC follows the same documented path — from first draft to closed decision.
How to write a good RFC
Three things that make the difference between an RFC that moves fast and one that stalls.
Start with what is broken or missing — not with what you want to build. Reviewers need to agree that the problem is real before they can evaluate your proposed solution. Frame the "why" before the "what".
Every decision has costs. Name them. What gets worse? What are the alternatives you considered? An RFC that acknowledges trade-offs earns trust faster than one that only sells the upside.
Point to real examples — issues, incidents, prior discussions, or production patterns. Evidence turns opinions into traceable facts and dramatically shortens the review cycle.
Start an RFC today.
Open a discussion on GitHub, follow the template, and let the process do the rest. No prior approval needed — just a clear problem statement.