Governance & Community.

Wombat 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.

v1.1
Framework
8
Pillars
100+
Controls
Apache 2.0
Code license
CC BY 4.0
Docs license

Built to last, open by default.

Three principles that shape how Wombat is governed — lightweight enough to move fast, structured enough to scale.

RFC-driven decisions

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.

Transparent & traceable

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.

Vendor-neutral, always

No single company controls Wombat. 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.

Technical Steering Committee

Technical direction · RFC decisions · 12-month terms

Maintainers

Reviews · Quality · Releases

User Advisory Group

Practical feedback · Audit perspective

Contributors & Working Groups

Issues · PRs · WG work · Proposals

Transparency: GitHub · RFCs · Meeting notes

Governance you can watch.

Group hierarchy, health and validation metrics in one view. Every decision and every scan leaves a trace you can follow.

Wombat monitoring a governance dashboard with group health and validation metrics

Governance model (CNCF-inspired).

Six clearly defined roles and mechanisms — each with a specific scope, accountability, and process.

TSC

Technical Steering Committee

Responsible for technical direction, architecture decisions, and RFC approvals. Elected from active contributors. 12-month renewable terms.

Maintainers

Maintainer Team

Maintains core repositories, performs reviews, and ensures consistency and quality. Appointed for 12 months, renewable based on activity.

WG

Working Groups

Topic-focused groups for pillars, scoring, controls, and reference architectures. Work openly via GitHub issues and RFCs. Anyone can propose a WG.

Advisory

User Advisory Group

Brings real-world perspectives from projects, operations, and audits. Prioritizes relevance — ensures the framework reflects production reality, not just theory.

Transparency

Public by Default

Roadmap, discussions, votes, and decisions are publicly documented and traceable on GitHub. No private decision channels for framework changes.

RFC

RFC Process

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.

Maintainers

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

TSC terms

TSC members serve 12-month terms, renewable. Composition follows "active contributors first" and vendor-neutral balance. Roles and responsibilities are publicly documented.

Working Groups

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.

Decisions

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.

Voting

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
Conduct

Expectations

Act vendor-neutral, prioritize community interests, document decisions, communicate respectfully (Code of Conduct), and report security topics responsibly through the defined channels.

Templates

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.

RFCs & decisions on GitHub

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.

Sessions & BoFs

Exchange at conferences — talks, panels, and Birds-of-a-Feather sessions where engineers share real challenges and patterns.

Workshops

Hands-on workshops on maturity models, scoring, and practical implementation — turning framework concepts into engineering practice.

Roadmap & RFC sessions

Public sessions on the roadmap and open RFC drafts — anyone can attend, comment, and shape what gets built next.

View conferences
Community channels
GitHub

Issues · PRs · RFCs · Discussions

Open →
Slack

Real-time community chat

Conferences

Talks · Workshops · BoFs

View →
RFC Process

Draft · Review · Decide · Implement

RFCs →

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.

Share use cases

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.

Propose criteria & controls

Input for maturity models and questionnaires: what must be checked, no matter what? New controls, scoring criteria, and assessment patterns all start here.

Review & give feedback

Review architecture patterns and reference models for consistency, practicality, and trade-offs. Open RFCs always need thoughtful engineering perspectives.

Documentation & translations

Improve, extend, and translate content into additional languages. Good documentation is half the value — and always in demand.

Join a working group

Help with pillars, scoring, controls, or reference architectures — transparently on GitHub. Working groups are how the framework grows in focused, accountable sprints.

Speakers & sessions

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.

COMMUNITY SLACK

Join the conversation on Slack

Our Slack workspace is the place for community exchange around Wombat — questions, framework changes, working group coordination, and everything that would clutter GitHub discussions.

Community exchange
Questions, ideas & experience sharing
Framework changes
Early discussion before RFCs & PRs
Working Groups
Coordination & quick alignment

Traceable, fair, open.

Governance is lived practice. We keep processes lightweight but clear — so Wombat can grow with the community without losing accountability.