Define OCM Specification Change Management Process

[phoban01]

Description

Currently there is no defined method for proposing changes or updates to the OCM specification.

We should agree on an appropriate mechanism whether by voting¹ or some other means.

In tandem we should also decide upon an accompanying release process that defines when changes to the spec should be released.

Some initial proposals and ideas:

• No more uncontrolled enhancements to versions considered to be frozen
• Have a frozen version 0.x and a working-draft 0.x+1
• Have a defined way to release a new spec version
• community consensus (majority vote, absolute majority, unanimous, ...) or just if no one objects
• no more open issues (can be deferred to next version, but must have been reviewed)
• somehow documented release decision (e.g. as issue)

It has also been noted that the specification needs some attention to correct errata.

Epic links:

• Improve Open Component Model (OCM) Specification ocm-spec#60

Footnotes

1. see for example https://github.com/opencontainers/runtime-spec/blob/main/GOVERNANCE.md) ↩

[robertwol]

@open-component-model/collaborators

We decided to use the voting app/action on GitHub for this type of task.

To use voting, please put /vote-profileocm in the comment of issue or PR

Voting profile profileocm is defined in the following config file .gitvote.yml in the root folder of the repo and it targets only ocm-dev team on our project (only dev team) so no other people will be notified.

  profileocm:
    duration: 5d
    pass_threshold: 50
    allowed_voters:
      teams:
        - ocm-dev