Contributing.
Wombat lives from contributions. Whether you write code, improve documentation, review RFCs, or share experience from real projects — every contribution shapes the framework.
Ways to contribute.
Code, content, community — pick what fits your skills and time.
PRs & Issues
Fix bugs, implement controls, improve tooling. Every PR gets reviewed by a maintainer and linked back to a decision.
Docs & Patterns
Write pillar documentation, reference architectures, best-practice patterns, or concrete examples from real projects.
RFC Reviews
Comment on open RFCs, propose alternatives, or vote on framework decisions. Every voice counts — especially real-world perspective.
Localisation
Help translate content into German, English, or further languages. Wombat should be accessible to the global cloud community.
Working Groups
Join or propose a Working Group around a specific pillar, scoring model, controls library, or reference architecture.
Talks & BoFs
Present Wombat at a conference, host a Birds-of-a-Feather session, or run a community workshop. Practical experience is gold.
Who's building it.
Real people, real commits — no logo wall, no stock team photos.
lewandos 
t1murl Getting started.
Four steps from newcomer to contributor.
-
Explore the GitHub organisation
Browse open issues labelled
good first issueorhelp wantedat github.com/waf2p. No issue yet? Open one and describe what you want to tackle. -
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. -
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.
-
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.
Working Groups.
Working Groups are topic-focused teams building specific parts of Wombat. 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 Wombat's transparency principles.
Feature lifecycle.
Every Wombat 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.
- 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.
- 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.
- 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.
- 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.
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.
No contribution is too small.
A typo fix, a clarifying comment, a review — it all moves the framework forward. Wombat is built in public and the community is always open.