Code
PRs & Issues
Fix bugs, implement controls, improve tooling. Every PR gets reviewed by a maintainer and linked back to a decision.
Open Source · Community
Contributing to WAF++
WAF++ lives from contributions. Whether you write code, improve documentation, review RFCs, or share experience from real projects — every contribution shapes the framework.
6 ways to contribute
No minimum contribution size
Everything happens in the open
How
Ways to contribute
Code, content, community — pick what fits your skills and time.
Content
Docs & Patterns
Write pillar documentation, reference architectures, best-practice patterns, or concrete examples from real projects.
Review
RFC Reviews
Comment on open RFCs, propose alternatives, or vote on framework decisions. Every voice counts — especially real-world perspective.
Translation
Localisation
Help translate content into German, English, or further languages. WAF++ should be accessible to the global cloud community.
Community
Working Groups
Join or propose a Working Group around a specific pillar, scoring model, controls library, or reference architecture.
Events
Talks & BoFs
Present WAF++ at a conference, host a Birds-of-a-Feather session, or run a community workshop. Practical experience is gold.
First steps
Getting started
Four steps from newcomer to contributor.
1
Explore the GitHub organisation
Browse open issues labelled good first issue or help wanted at github.com/waf2p. No issue yet? Open one and describe what you want to tackle.
2
Introduce yourself on Slack
Join the community on Slack, say hi in #general, ask questions, and find out which Working Group fits your background and interests.
3
Fork → branch → PR
Fork the relevant repository, create a feature branch, and open a pull request. A maintainer will review it, give feedback, and guide you through the process.
4
Larger changes? Open an RFC first
For new pillars, breaking changes, scoring changes, or governance updates — draft an RFC in GitHub Discussions. The community reviews it before implementation begins. This keeps decisions traceable.
Collaboration
Working Groups
Working Groups are topic-focused teams building specific parts of WAF++. Anyone can propose one — all you need is a charter, at least one lead, and a maintainer sponsor.
Find a WG
Check open WG proposals on GitHub Discussions and join the matching channel on Slack. You can contribute without a full-time commitment.
Start a WG
Draft a charter in a GitHub Discussion, find a maintainer sponsor, and announce it on Slack. WGs can focus on any scope: a single pillar, a tooling question, a scoring approach.
Ship results
WG outputs flow back as PRs and RFCs. Every result is public, traceable, and citable — consistent with WAF++'s transparency principles.
Availability
Feature lifecycle
Every WAF++ capability moves through a clear lifecycle. Each stage is gated by the RFC/ADR process, so users always know how mature a feature is and what to expect before they adopt it.
Explore privately
A small group of early adopters tests the capability in controlled environments. The API, scoring model, or CLI surface is intentionally unstable and may change without notice.
How it enters
- Draft or open RFC defines the experiment
- Invite-only early-access cohort
- Feedback drives fast iteration
Test in the open
The capability is available to everyone who wants to try it. Interfaces are mostly stable, but breaking changes are still possible based on community feedback.
How it enters
- RFC accepted with alpha scope
- Public docs and release notes available
- GitHub Discussions collect feedback
Use in production
The capability is feature-complete and production-ready for the documented use cases. Minor adjustments may still happen, but breaking changes require explicit migration guidance.
How it enters
- RFC accepted and implementation merged
- ADR documents production-readiness criteria
- Security, performance, and compatibility review passed
General Availability
The capability is fully supported, covered by the stability policy, and recommended for all users. It is maintained with backwards-compatible updates and clear deprecation windows.
How it enters
- RFC status moves to implemented
- Final ADR ratifies the stable contract
- Added to the official release train
Every stage is linked to the RFC/ADR process. When an RFC is accepted it triggers the Alpha or Beta gate; when it is marked implemented the capability becomes GA-ready. Follow the full picture on the RFC tracker or propose the next change in GitHub Discussions.
Process
The RFC process
Significant changes go through an RFC (Request for Comments). The process is lightweight but ensures every decision is community-reviewed and documented.
Draft
Open a GitHub Discussion with your proposal
→
Review
Community & maintainers comment and refine
→
Decision
TSC or lazy consensus — documented publicly
→
Implementation
PR merged, changelog updated
Ready to start?
No contribution is too small.
A typo fix, a clarifying comment, a review — it all moves the framework forward. WAF++ is built in public and the community is always open.