This document describes how the Open Aquarium Project makes decisions. It is intentionally light while the project is small, and it will grow as more people and organizations take part.
Specification work also follows the Community Specification Governance Policy 1.0, which every specification contributor agrees to under the Community Specification Contributor License Agreement. This document adds project-specific rules and does not override that policy. In that policy’s terms, this repository is the Working Group.
1 Roles
Project Lead. Sets the project’s direction, appoints Maintainers and Editors, and decides matters that are not specification content (for example, repository administration, the project name, and changes to this document). The founder, listed in Maintainers, is the Project Lead.
Maintainer. Organizes work on one or more specifications or reference designs, determines consensus, and handles appeals, as defined in the Community Specification Governance Policy. Until other Maintainers are appointed, the Project Lead is the Maintainer for every specification and reference design.
Editor. Makes sure a specification accurately reflects the Working Group’s decisions and follows the template and style rules. Each specification names its Editors in its front matter.
Participant. Anyone who has made a contribution.
Current role holders are listed in Maintainers.
2 Decision Making
Decisions about specification content are made by consensus. Agreement from every Participant is preferred but not required. The Maintainer determines consensus in good faith, considering the dominant view and the nature of support and objections, and records the evidence in the relevant issue or pull request.
Any decision can be appealed by opening an issue. The Maintainer responds in writing within a reasonable time. If the Maintainer was the decision maker and is also the Project Lead, the appeal is also posted publicly for at least 14 days of comment before the response.
No single person or organization may dominate specification development. This rule applies to the Project Lead as well.
3 Specification Lifecycle
| Stage | Meaning | How a specification gets there |
|---|---|---|
| Proposal | An idea with a written rationale. Optional for small changes. | A pull request adding a file to proposals/. |
| Pre-Draft | A candidate document submitted for consideration. | Any Participant submits one; the Maintainer designates it Pre-Draft. |
| Draft | The agreed basis for all further work on the specification. | Consensus to adopt the Pre-Draft. |
| Approved | Complete and stable enough to build products against. | Consensus to approve, plus the requirements below. |
| Superseded | Replaced by a later approved revision. | Approval of the later revision. |
| Withdrawn | No longer recommended for use. | Consensus to withdraw. |
Before approval, every specification must also meet these requirements:
- Its Tenet Compliance section addresses all five tenets in the charter.
- A public review period of at least 30 days has been announced and completed.
- At least two independent implementations exist, at least one from an organization not represented among its authors, and they have been shown to work together.
- Conformance materials, such as schemas, test vectors, or test procedures, are published.
- Its Approval Checklist appendix is complete.
Revisions before approval are numbered 0.x, and the first approved revision is 1.0. After 1.0, a minor revision (1.1, 1.2) must stay backward compatible, and a major revision (2.0) may break compatibility.
4 Reference Designs
Reference designs, such as the reference controller, follow the same process as specifications for significant decisions: a proposal, then review and consensus. A reference design implements the current specifications and documents any place it does not. It has no special status compared with any other implementation.
Anyone may manufacture and sell products based on a reference design under its license. The project itself does not sell products.
5 Name and Marks
The project name, and any future compatibility mark, are held by the Project Lead on the project’s behalf until they can be transferred to a neutral legal entity. A compatibility program, if created, will require conformance testing, and its policy will be published before the mark is used.
6 Competition Law
Participants include companies that compete with each other. Project discussions must not cover pricing, sales terms, distribution channels, division of markets or customers, or any other topic competitors must not discuss together. See Section 6 of the Community Specification License.
7 Evolving This Governance
When the project has active Maintainers from at least three organizations, the Project Lead will propose a Technical Steering Committee to take over the Project Lead’s decision-making role. When equipment makers ask for a neutral legal home, the project will consider moving to a foundation, such as the Linux Foundation’s Joint Development Foundation.
Changes to this document are made by pull request and approved by the Project Lead (later, by the Technical Steering Committee), after at least 14 days of public comment.