Governance & Community
WAF++ is a community-driven, vendor-neutral initiative — with clear, transparent governance inspired by established open-source models like CNCF. Every decision is traceable. Every role has a term.
Built to last, open by default
Three principles that shape how WAF++ is governed — lightweight enough to move fast, structured enough to scale.
Every significant change goes through a Request for Comments — drafted publicly, reviewed by the community, and decided with justification. No silent updates, no opaque vendor choices. The history is the governance.
Roadmap, discussions, votes, and decisions are publicly documented on GitHub. Anyone can follow the reasoning, challenge a decision, or propose an alternative — with the same process every time.
No single company controls WAF++. Governance roles follow "active contributors first" and vendor-neutral balance. The TSC composition, Working Group charters, and Advisory Group all enforce this by design.
Governance at a glance
Intentionally lean but scalable — designed for a growing community. Decisions flow through RFCs, reviews, and documented votes.
Governance model (CNCF-inspired)
Six clearly defined roles and mechanisms — each with a specific scope, accountability, and process.
Responsible for technical direction, architecture decisions, and RFC approvals. Elected from active contributors. 12-month renewable terms.
Maintains core repositories, performs reviews, and ensures consistency and quality. Appointed for 12 months, renewable based on activity.
Topic-focused groups for pillars, scoring, controls, and reference architectures. Work openly via GitHub issues and RFCs. Anyone can propose a WG.
Brings real-world perspectives from projects, operations, and audits. Prioritizes relevance — ensures the framework reflects production reality, not just theory.
Roadmap, discussions, votes, and decisions are publicly documented and traceable on GitHub. No private decision channels for framework changes.
Draft → community review → decision → implementation. Every significant decision is justified and linked to its discussion thread.
Roles, terms & expectations
Clear rules make governance fair and predictable. Here's exactly how decisions are made and how roles work.
Maintainer terms
Appointed for 12 months, renewable when engagement and review activity are present and no substantiated objections exist.
Inactivity: After 90 days without activity, status may be set to "emeritus" after a ping and transparent note. Reactivation is possible at any time.
TSC terms
TSC members serve 12-month terms, renewable. Composition follows "active contributors first" and vendor-neutral balance. Roles and responsibilities are publicly documented.
Starting a working group
Anyone can propose a WG. Required: a charter (goal, scope, deliverables), lead(s), a communication channel, and a maintainer sponsor.
WG outputs flow back into the main repos as PRs and RFCs.
Lazy consensus
For smaller changes: a proposal is posted publicly with 5 business days for review. No substantiated objections → accepted.
A "block" must be justified and propose an alternative solution or adjustment.
Quorum & voting
For larger decisions (new pillar, breaking changes, charter changes), the TSC votes:
- Quorum: at least 60% of active TSC members
- Majority: simple majority of votes cast
- Minimum: at least 3 votes if the TSC is small
- Conflicts: members with conflicts of interest abstain
Expectations
Act vendor-neutral, prioritize community interests, document decisions, communicate respectfully (Code of Conduct), and report security topics responsibly through the defined channels.
Where are decisions made?
RFCs for larger changes · ADRs and notes for architecture decisions · Issues and PRs for implementation. Every decision references the discussion that led to it.
Where the community meets
The project started within the Cloud Native Conference context and the existing CCC community. The goal: consolidate real-world experience and evolve it openly in public.
Exchange at conferences — talks, panels, and Birds-of-a-Feather sessions where engineers share real challenges and patterns.
Hands-on workshops on maturity models, scoring, and practical implementation — turning framework concepts into engineering practice.
Public sessions on the roadmap and open RFC drafts — anyone can attend, comment, and shape what gets built next.
How you can contribute
There is no minimum contribution size. Every use case shared, every review given, every RFC commented on moves the framework forward.
What challenges do you face in cloud projects? Which patterns work — and which don't? Real-world experience is the most valuable input the framework can get.
Input for maturity models and questionnaires: what must be checked, no matter what? New controls, scoring criteria, and assessment patterns all start here.
Review architecture patterns and reference models for consistency, practicality, and trade-offs. Open RFCs always need thoughtful engineering perspectives.
Improve, extend, and translate content into additional languages. Good documentation is half the value — and always in demand.
Help with pillars, scoring, controls, or reference architectures — transparently on GitHub. Working groups are how the framework grows in focused, accountable sprints.
Bring topics to CFPs, give talks, or host BoFs at conferences. Practical real-world examples presented publicly shape the framework more than any RFC alone.
Traceable, fair, open.
Governance is lived practice. We keep processes lightweight but clear — so WAF++ can grow with the community without losing accountability.
