The change request process is documented in two places that state the same rules.
docs/presentations/change-request-process/ is a 15-slide deck plus a PDF. docs/governance/versioning-sop.md already owns the versioning scheme, the change-class labels, the RAG states and the 14+5 cycle. A third prose page repeating the deck adds a source of truth without adding a reader.
Governance rules belong in the SOP, which is the document already in the mkdocs.yml nav and already cited by every process reference. The deck presents them; it does not define them.
Outcome
versioning-sop.md carries the whole change request process:
- Where work is tracked — JIRA owns planning, GitHub owns engineering execution
- Branching for core contributors and for community contributors
- Raising and executing a change, and the branch naming rule
- PR review: standard changes, and the 14+5 cycle for major changes
- Mandatory reviewer teams and the sign-off states
- The audit trail from requirement through to release
- The repository controls that enforce it
The deck stays as presentation material and cites the SOP rather than restating the rules, so a rule can only be changed in one place.
The change request process is documented in two places that state the same rules.
docs/presentations/change-request-process/is a 15-slide deck plus a PDF.docs/governance/versioning-sop.mdalready owns the versioning scheme, the change-class labels, the RAG states and the 14+5 cycle. A third prose page repeating the deck adds a source of truth without adding a reader.Governance rules belong in the SOP, which is the document already in the
mkdocs.ymlnav and already cited by every process reference. The deck presents them; it does not define them.Outcome
versioning-sop.mdcarries the whole change request process:The deck stays as presentation material and cites the SOP rather than restating the rules, so a rule can only be changed in one place.