Governance
OSIRIS is an Open Standard intended to be openly reviewable and community-driven.
This page explains how changes are proposed, reviewed, and released.
[!Info] Current maintenance model OSIRIS is currently maintained by a single lead maintainer. Contributions are welcome from the beginning, but the process is intentionally lightweight to keep v1.0 manageable and consistent.
Roles
Maintainer
Owns the quality and coherence of the specification text, schemas, producers, examples and release notes. Ensures changes preserve vendor-neutrality, clarity and compatibility expectations.
Contributor
Propose improvements via issues and pull requests: fixes, clarifications, new examples, new producers and implementation guidance.
Reviewer
Community members who provide technical insight, review and feedback. Review is especially valuable for normative changes and versioning impacts.
Where decisions happen
- GitHub discussions: design discussions, questions and early feedback.
- GitHub issues: bugs, inconsistencies and proposals to change the specification.
- Pull requests: the authoritative place where wording, schemas and examples are changed and reviewed.
Decision-making principles
OSIRIS follows the specification design principles with a focus on:
- Simplicity
- Vendor neutrality
- Extensibility without fragmentation
- Explicit over implicit
- Stability and compatibility
The default decision model is rough consensus through public discussion and review. When consensus cannot be reached, the lead maintainer makes a decision and documents the rationale in the PR or issue.
Change process
Types of changes
Editorial (non-normative)
- Fix typos, improve clarity, restructure sections, improve examples without changing requirements.
Normative
- Changes that alter requirements or interpretation (MUST/SHOULD/MAY rules), validation behavior, or compatibility expectations. OSIRIS uses the widely supported JSON format and aligns with established conventions, including JSON Schema for structural validation and RFC 2119 keywords for normative requirements.
Taxonomy / registry / extension guidance
- Updates affecting the interpretation of standard types, recommended namespaces, or extension best practices.
Versioning, compatibility, and releases
OSIRIS uses Semantic versioning 2.0.0 for specification releases.
The version field in an OSIRIS document declares which specification version it conforms to and producers/consumers are expected to follow the compatibility behavior described in the spec.
Draft and pre-release versions
During development, versions MAY use SemVer pre-release notation (e.g. 1.0.0-DRAFT). Draft/pre-release versions are not considered stable and may change incompatibly until a stable release is published.
Deprecation policy
Deprecated features follow a defined lifecycle: announcement, documentation + migration guidance, transition period (at least one MINOR cycle), and removal only in the next MAJOR release.
Extension governance
OSIRIS defines the namespace rules and (when applicable) registry policy for well-known extension namespace prefixes, but does not govern the internal semantics of vendor/organization extensions. Consumers must treat values inside extensions as opaque unless they explicitly support that namespace.
Namespace registration (v1.0)
For OSIRIS v1.0, namespace registration is informal and community-driven:
- Document namespace usage publicly
- Publish extension schemas for consumer reference (when applicable)
- Coordinate with the OSIRIS community to avoid collisions
Recommended namespaces
- Organization namespaces should use reverse-domain patterns (e.g.
osiris.com.<org>) to reduce collisions. osiris.custom.*may be used for short-lived experiments and community drafts, but is not collision-resistant. Producers should migrate to organization namespaces for persistent/production usage.
Code of Conduct
Participation in the OSIRIS community is governed by the Code of Conduct.
Read the Code of Conduct