87 lines
2.6 KiB
Markdown
87 lines
2.6 KiB
Markdown
# Governance
|
|
|
|
Operational governance for the Church of Kosmo repository.
|
|
|
|
## Scope
|
|
|
|
This document governs how canonical texts are proposed, reviewed, approved, and released across:
|
|
|
|
- `docs/en/**` (canonical source language)
|
|
- `docs/cs/**` (translation mirror)
|
|
- `LICENSE.md`
|
|
- `CONTRIBUTING.md`
|
|
- `README.md`
|
|
- `BACKLOG.md`
|
|
|
|
## Decision Model
|
|
|
|
The project uses a consensus-first model.
|
|
|
|
1. A change is proposed through a pull request.
|
|
2. Reviewers discuss wording, consistency, ethics, and structure.
|
|
3. If no unresolved objections remain, the change is considered approved.
|
|
|
|
## Consensus Fallback
|
|
|
|
If consensus cannot be reached in a reasonable window, use this fallback:
|
|
|
|
1. Mark the PR as `needs-reflection`.
|
|
2. Open a focused follow-up issue summarizing the conflict and options.
|
|
3. Pause merge until one of these outcomes occurs:
|
|
- wording is revised to remove objection, or
|
|
- the proposal is split into smaller non-contentious changes.
|
|
|
|
No forced-majority merge for disputed canonical wording.
|
|
|
|
## Canonical vs Translation Policy
|
|
|
|
1. English files in `docs/en/` are canonical reference texts.
|
|
2. Czech files in `docs/cs/` should remain semantically aligned.
|
|
3. Intentional localization is allowed only when documented in the PR description.
|
|
4. Translation PRs must preserve structure, section numbering, and key terms unless explicitly justified.
|
|
|
|
## Amendment Flow
|
|
|
|
For material changes to charter, codex, or ethics text:
|
|
|
|
1. Open an issue first with:
|
|
- motivation
|
|
- affected files
|
|
- expected impact
|
|
2. Link the issue in the pull request.
|
|
3. Include a short amendment note in PR body:
|
|
- what changed
|
|
- why now
|
|
- compatibility or interpretation impact
|
|
4. Require CODEOWNERS review before merge.
|
|
|
|
## Release Cadence
|
|
|
|
Repository releases follow a docs cadence:
|
|
|
|
1. Patch release (`vX.Y.Z`) for typo/format/link-only changes.
|
|
2. Minor release (`vX.Y.0`) for approved content updates that do not redefine core principles.
|
|
3. Major release (`vX.0.0`) for structural or doctrinal-level updates to canonical texts.
|
|
|
|
Recommended rhythm:
|
|
|
|
- Monthly patch/minor tags as needed.
|
|
- Quarterly canonical review checkpoint.
|
|
- Annual governance review of charter and process documents.
|
|
|
|
## Merge and Branch Rules
|
|
|
|
1. All changes arrive through pull requests.
|
|
2. Direct pushes to protected branches should be disabled.
|
|
3. CI checks must pass:
|
|
- markdown lint
|
|
- local markdown link validation
|
|
- translation parity report
|
|
|
|
## Records and Traceability
|
|
|
|
1. Significant decisions should be traceable via linked issue + PR.
|
|
2. Release notes should summarize canonical text changes by file path.
|
|
3. Backlog updates should mark completed governance/process milestones.
|
|
|