UNIVIP Governance (Draft)Link to the section UNIVIP Governance (Draft)
On this page
This document describes how the UNIVIP specification is developed, decided and released during the independent-standard phase (Route A in ADR-0004). It is intentionally lightweight and will be replaced by a formal charter when a steering group with multiple member organizations exists.
PrinciplesLink to the section Principles
- Open specification. Every normative document is public, versioned and freely licensed (CC BY 4.0 for text, Apache 2.0 for machine-readable artifacts).
- Transparent decision-making. Technical decisions are recorded as Architecture Decision Records (ADRs) in
docs/decisions/with their alternatives and rationale. - Implementation before endorsement. No feature reaches "Stable" without at least two independent implementations (at least one device-side, at least one client-side) demonstrating interoperability.
- Safety separation. Changes affecting Profile N (vehicle control) require explicit review by at least one reviewer with flight-operations or vehicle-controller expertise and may not be approved by the same person who authored them.
- No vendor capture. No single organization may hold a majority of steering-group seats once a steering group is formed.
RolesLink to the section Roles
| Role | Responsibilities |
|---|---|
| Editor(s) | Maintain the specification text, triage proposals, ensure consistency between prose, schemas and OpenAPI |
| Technical Working Group | Open to any contributor; discusses proposals, produces ADRs and pull requests |
| Steering Group (to be formed) | Approves release candidates and the conformance policy; resolves disputes; manages the IPR policy |
| Conformance Lead (to be appointed) | Owns the test-suite and conformance-claim rules in spec/14-conformance-testing.md |
Document maturity levelsLink to the section Document maturity levels
| Level | Meaning |
|---|---|
| Draft | Under active development. Anything may change. |
| Release Candidate | Feature-complete for the target version; at least one implementation exists; breaking changes require an ADR. |
| Stable | Two independent interoperating implementations; conformance tests exist; changes follow the versioning rules below. |
| Deprecated | Scheduled for removal in a future major version; a migration note exists. |
Every file in spec/ carries its own maturity level in its header. The repository as a whole is Draft.
Change processLink to the section Change process
- Open an issue describing the problem (not the solution) and the profiles it affects.
- For anything that changes interoperability (message fields, enumerations, endpoints, conformance rules), write or update an ADR using
docs/decisions/TEMPLATE.md. - Open a pull request that updates, in the same change, all of: the relevant
spec/document,schemas/and/orapi/, at least oneexamples/file, andCHANGELOG.md. - CI must pass (
tools/validate.py). - Two approvals from distinct organizations are required for normative changes; one approval is sufficient for editorial changes.
- Profile N changes additionally require the safety review in Principle 4.
VersioningLink to the section Versioning
- The specification uses semantic versioning:
MAJOR.MINOR.PATCH. - Schema identifiers (
univip.telemetry.v0.1) carryMAJOR.MINORonly. Adding optional fields is a MINOR change. Removing or renaming a field, changing a unit, or narrowing an enumeration is a MAJOR change. - Devices and clients MUST ignore unknown fields (see
spec/01-scope-and-conformance.md), which is what makes MINOR additions safe. - The REST API is versioned in its path (
/univip/v1/). A MAJOR version bump of the API introduces a new path segment; the previous version remains supported for at least 24 months after the new version reaches Stable.
Intellectual property (interim)Link to the section Intellectual property (interim)
Until a formal IPR policy is adopted, contributors agree that their contributions are licensed under the repository licenses and that they are not aware of any patent claims they hold that would be necessarily infringed by implementing the specification without having disclosed them in the pull request. A royalty-free (RAND-Z) patent commitment is the intended target policy and will be the first task of the Steering Group.
Relationship to ONVIF and other bodiesLink to the section Relationship to ONVIF and other bodies
UNIVIP is designed to interoperate with ONVIF, not to compete with it. The project will open a dialogue with ONVIF early and is prepared to contribute UNIVIP, in whole or in part, as a profile proposal through ONVIF's membership and profile-policy process. The same openness applies to the Dronecode Foundation (MAVLink), MISB and relevant national bodies. Decisions about such contributions are Steering Group decisions.