Governance

How the standard is maintained

Lightweight during early development, with a clear path toward broader industry participation.

Current stage

OpenCOOS was founded by ManageStrata. It has no formal institutional backing and no governing body or member organizations yet. During early development, drafts are prepared by a small group of maintainers, starting with the ManageStrata team. The aim is to broaden maintainership to independent participants as the community grows.

Open contribution process

Anyone can propose changes. Discussion and decisions happen in public, in the specification repository's issues and discussions once they are configured.

Changes to the specification are made by pull request and must pass automated schema and example validation.

Issue reporting

Report errors, unclear definitions, missing concepts or terminology that doesn't match practice in your province as issues. You don't need to propose a solution.

Please never include real personal information or confidential strata records in an issue.

Proposals and design discussions

Substantial changes — new entities, new domains, breaking changes — start as a written proposal describing the problem, real-world examples, the proposed definitions and alternatives considered.

Proposals stay open for comment for a reasonable period before a decision, and the decision and its rationale are recorded with the proposal.

Maintainer responsibilities

Maintainers review contributions, keep the specification internally consistent, run releases, publish release notes, and make sure decisions are documented.

Maintainers must act in the interest of the standard as a whole and not of any one product, including products they work on. They disclose relevant affiliations.

Versioning policy

Releases follow semantic versioning. Before 1.0.0, minor releases may include breaking changes. Working drafts carry a -draft suffix.

Full versioning policy →

Release notes

Every release lists added, changed, deprecated and breaking changes with migration instructions.

Changelog →

Deprecation policy

Fields and entities are deprecated before they are removed, remain valid for at least one further minor release, and are only removed in a major release.

Compatibility principles

Consumers ignore unknown extensions; producers send only defined fields; names are never reused with a different meaning once stable.

Conflict resolution

Disagreements are resolved by discussion aimed at consensus, guided by the design principles and real-world evidence.

If consensus can't be reached, maintainers make a decision, record the reasoning, and the question can be revisited when new evidence emerges.

Community participation

Participation is open to developers, councils, owners, property managers, industry organizations and researchers. A code of conduct will be published with the repository.

Path toward broader governance

Early development (now): small maintainer group, open drafts, public feedback.
First release: code of conduct and documented decision process.
Broader participation: maintainers from multiple independent organizations, so that no single vendor controls the standard.
Mature governance: if there is demand, a more formal structure, such as a steering group, with industry and community representation.