Wombat Wombat

Contributing.

Wombat lives from contributions. Whether you write code, improve documentation, review RFCs, or share experience from real projects — every contribution shapes the framework.

Get started GitHub Slack
6
Ways to contribute
4
Core maintainers
2
Code contributors
0
Minimum contribution size

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.

Artem Lajko
Artem Lajko
Maintainer

Founder / Core maintainer

Sascha Lewandowski
Sascha Lewandowski
Maintainer

Founder / Core maintainer

Sebastian Meyer
Sebastian Meyer
Maintainer

Founder / Core maintainer

Tim Urlaub
Tim Urlaub
Maintainer

Founder / Core maintainer

Community Impact Contributors
Maximilian Hille
Maximilian Hille
Zusätzliche Einsichten in Business Usecases
All code contributors

Synced from GitHub · 12 commits total

lewandos lewandos · 11 t1murl t1murl · 1

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.

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.

Closed Alpha

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
See draft RFCs →
Alpha

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
Join alpha discussions →
Beta

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
Track accepted RFCs →
GA

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
View implemented RFCs →

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.

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
View RFC tracker

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.

Open GitHub Join Slack Governance & Community