Governance
Stewardship of the CABE project and specifications.
Current stewardship
The current core team is:
- Hugo Landau
- Andrés Vega
- Ryan Hurst
The website and specification drafts are maintained in the public messier-42/cabe repository, under Messier 42’s GitHub organisation. The project’s existing public contribution channels support specification discussion, issue reports and proposed changes.
Broadening stewardship
An organisation adopting CABE should be able to implement it independently and take part in its development. We intend to broaden stewardship beyond the founding team, with a clear route for sustained contributors to take responsibility for the project. We welcome specification review, independent implementations, interoperability testing and operational feedback.
The broader governance model is being developed.
Participation and roles
The following roles and processes describe a proposed governance model for adoption. They do not announce new appointments or repository permissions.
- Users
- Use CABE in their systems and bring questions, operational experience and requirements to the project. Reporting problems and explaining real application needs are useful contributions.
- Contributors
- Improve the specifications, documentation or implementations through proposals, reviews, code, interoperability tests and other substantive work. Contribution can begin through the existing public channels.
- Maintainers
- Take sustained responsibility for an area of the project, review changes, help contributors resolve feedback and look after technical quality and continuity. Maintainer responsibilities and appointments would be made explicit as the broader model is adopted.
Ideas and contributions are considered on their technical merit and alignment with the project’s objectives, scope and design principles. These guidelines are intended to support fair, transparent participation; they are not an exhaustive list of ways to contribute.
Proposed change review process
All changes must be submitted as a GitHub Pull Request (PR). The submitter is responsible for responding to feedback from reviewers and maintainers and keeping the change ready to merge while the PR remains open, including resolving conflicts and addressing failed checks.
- Minor changes require approval from at least one other maintainer. This includes documentation clarifications, bug fixes and other changes that do not significantly affect most users.
- Major changes require approval from at least two other maintainers. This includes new or changed functionality and significant changes to specified behaviour, even when the change is expressed in specification text.
The submitter’s own approval does not count towards either threshold. Reviewers should explain concerns and work with the submitter towards a change that can be accepted.
Proposed decision-making approach
We propose a lazy consensus approach: make proposals and their reasoning public, invite feedback and address reasoned objections. Where there is no unresolved objection, routine decisions can move forward without a formal vote.
Lazy consensus does not replace the explicit PR approvals above. Silence does not count as a maintainer approval. Objections should be discussed and resolved before the affected proposal proceeds.
A future steering group
As stewardship broadens, the proposed model would give a CABE steering group final authority over the project’s technical direction, governance and process, and contribution policy. This describes an intended body, not an existing appointment or operative charter.
For that future group, we aspire to have no more than two members affiliated with the same organisation and at least 40% of members drawn from organisations with a CABE implementation deployed in production. These are longer-term representation goals as the ecosystem develops, not claims about current deployments or the composition of the core team.
Contribute now
Start with the specification drafts. Use GitHub Discussions for questions and proposed directions, or open an issue with a specific problem. Pull requests for errata and proposed improvements are welcome. Implementation experience, interoperability findings and operational feedback can help shape the drafts.
The Get involved page lists the project’s existing participation channels.