Governance & Community
WAF++ is a community-driven, vendor-neutral nonprofit initiative — with clear, transparent governance inspired by established open-source models (e.g., CNCF).
Decisions are made transparently through RFCs, reviews, and documented votes. The structure is intentionally lean but scalable — designed for a growing community.
Technical Steering Committee
Responsible for technical direction, architecture decisions, and RFC approvals.
Maintainer team
Maintains core repositories, performs reviews, and ensures consistency and quality.
Working Groups
Topic-focused groups (e.g., pillars, scoring, controls). Work openly via issues/RFCs.
User Advisory Group
Brings real-world perspectives from projects, operations, and audits, and prioritizes relevance.
Transparency
Roadmap, discussions, and decisions are publicly documented and traceable.
RFC process
Draft → community review → decision → implementation. Every decision is justified.
Maintainer terms
Maintainers are appointed for 12 months (renewable). Renewal happens if 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 a transparent note). Reactivation is possible at any time.
TSC terms
TSC members also serve 12-month terms (renewable). Composition follows the principle “active contributors first” and vendor-neutral balance. Roles and responsibilities are publicly documented.
Starting working groups
Anyone can propose a WG. Minimum content: a charter (goal, scope, deliverables), lead(s), a communication channel, and a maintainer sponsor.
WG outputs flow back into the main repos as PRs/RFCs.
Lazy consensus
For smaller changes, we use lazy consensus: 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 (e.g., a new pillar, breaking changes, charter changes), the TSC votes:
- Quorum: at least 60% of active TSC members participate
- Majority: simple majority of votes cast
- Minimum: at least 3 votes if the TSC is small
- Conflicts: in case of conflicts of interest, members abstain and are not counted toward quorum
Expectations
Act vendor-neutral, prioritize community interests, document decisions, communicate respectfully (Code of Conduct), and report security topics responsibly.
Where are decisions made?
To keep governance “auditable”, we use repeatable templates: RFCs for larger changes, ADRs/notes for architecture decisions, issues/PRs for implementation. Every decision references the discussion.
RFCs & decisions on GitHub →The project starts within the Cloud Native Conference context and the existing CCC community. The goal is to consolidate experience and evolve it openly in public.
Sessions & BoFs
Exchange at conferences — talks, panels, and Birds-of-a-Feather sessions.
Workshops
Hands-on workshops on maturity models, scoring, and practical implementation.
Roadmap & RFC sessions
Public sessions on the roadmap and open RFC drafts.
Share use cases
What challenges do you face in cloud projects? Which patterns work (or don’t)?
Propose questions & criteria
Input for maturity models and questionnaires: what must be checked, no matter what?
Review & feedback
Review architecture patterns and reference models: consistency, practicality, trade-offs.
Documentation & translations
Improve, extend, and translate content into additional languages.
Join a working group
Help with pillars, scoring, controls, or reference architectures — transparently on GitHub.
Speakers & sessions
Bring topics to CFPs, give talks, or host BoFs — practical examples are gold.
