|
1 | | -== Governance |
2 | | - |
3 | | -=== Overview |
4 | | - |
5 | | -This project is governed by the following principles and structures to |
6 | | -ensure transparent, inclusive, and effective decision-making. |
7 | | - |
8 | | -=== Roles and Responsibilities |
9 | | - |
10 | | -==== Maintainers |
11 | | - |
12 | | -Maintainers are responsible for: - Reviewing and merging pull requests - |
13 | | -Managing releases and versioning - Ensuring code quality and standards - |
14 | | -Triaging issues and bug reports - Community engagement and support |
15 | | - |
16 | | -==== Contributors |
17 | | - |
18 | | -Contributors are expected to: - Follow the code of conduct - Submit |
19 | | -well-documented pull requests - Write tests for new functionality - |
20 | | -Maintain existing tests - Update documentation as needed |
21 | | - |
22 | | -=== Decision Making |
23 | | - |
24 | | -==== Minor Changes |
25 | | - |
26 | | -* Can be made by any maintainer |
27 | | -* Include bug fixes, documentation updates, dependency updates |
28 | | - |
29 | | -==== Major Changes |
30 | | - |
31 | | -* Require discussion in issues or pull requests |
32 | | -* Include new features, architectural changes, API changes |
33 | | -* Need approval from at least 2 maintainers |
34 | | - |
35 | | -==== Breaking Changes |
36 | | - |
37 | | -* Require RFC (Request for Comments) process |
38 | | -* Need approval from majority of maintainers |
39 | | -* Must include migration guide |
40 | | - |
41 | | -=== Code of Conduct |
42 | | - |
43 | | -All participants are expected to follow our Code of Conduct. Violations |
44 | | -can be reported to the maintainers. |
45 | | - |
46 | | -=== Communication |
47 | | - |
48 | | -* *Issues*: For bug reports and feature requests |
49 | | -* *Discussions*: For questions and general discussion |
50 | | -* *Pull Requests*: For code contributions |
51 | | - |
52 | | -=== Licensing |
53 | | - |
54 | | -All contributions are made under the terms of the repository’s LICENSE |
55 | | -file. By submitting a pull request, you agree to license your |
56 | | -contributions accordingly. |
57 | | - |
58 | | -''''' |
59 | | - |
60 | | -_Last updated: 2026-07-18_ |
| 1 | +// SPDX-License-Identifier: CC-BY-SA-4.0 |
| 2 | +// SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath) <j.d.a.jewell@open.ac.uk> |
| 3 | += Governance |
| 4 | +:author: Jonathan D.A. Jewell (hyperpolymath) |
| 5 | +:revnumber: 2.0.0 |
| 6 | +:revdate: 2026-09-24 |
| 7 | +:toc: |
| 8 | +:icons: font |
| 9 | + |
| 10 | +[NOTE] |
| 11 | +==== |
| 12 | +v2.0.0 replaces a generic placeholder (v1) that did not describe this estate |
| 13 | +and carried a broken document tail. The placeholder said, for example, that |
| 14 | +major changes "need approval from at least 2 maintainers" — a statement that |
| 15 | +is not true of a single-owner estate and that contradicted the constitution. |
| 16 | +Authority for this document is derived from the |
| 17 | +link:constitution/README.adoc[Constitutional District], which it summarises |
| 18 | +for orientation and does not supersede. |
| 19 | +==== |
| 20 | + |
| 21 | +== What governs this repository |
| 22 | + |
| 23 | +This repository is the standards host of the Hyperpolymath estate: it holds |
| 24 | +the constitutional district, the RSR (Repository Standard) canon, the |
| 25 | +machine-readable format definitions, and the reusable CI/CD and security |
| 26 | +workflows that the estate consumes. |
| 27 | + |
| 28 | +* The *constitutional district* (link:constitution/README.adoc[0-canon/constitution/]) |
| 29 | + is the highest estate-level authority. It states what may govern: authority |
| 30 | + classes and precedence, the assurance constitution, the contribution |
| 31 | + constitution, exceptions and ANCHORs, known tensions, and the change |
| 32 | + procedure. |
| 33 | +* *Normative standards* (the RSR tree, the format trees, the policies under |
| 34 | + `docs/`) govern within constitutional bounds. |
| 35 | +* *Implementation* (scripts, reusable workflows, gates) may enforce rules |
| 36 | + but cannot create them. |
| 37 | + |
| 38 | +Where this document and the constitution differ, the constitution wins. |
| 39 | + |
| 40 | +== Roles |
| 41 | + |
| 42 | +*Owner*:: |
| 43 | +The estate is single-owner (hyperpolymath). The owner holds the authority |
| 44 | +classes the constitution assigns to the estate: rulings on `status:needs-ruling` |
| 45 | +matters, ANCHOR usage, licence and scope decisions, and changes to this |
| 46 | +document and the canon. |
| 47 | + |
| 48 | +*Maintainers*:: |
| 49 | +There are no separate maintainers. The owner may delegate scoped, revocable |
| 50 | +permissions via repository rulesets and branch protection; delegation is |
| 51 | +recorded in the rulesets, not in this document. |
| 52 | + |
| 53 | +*Agents and automation*:: |
| 54 | +Agents and bots act under the owner's authority and under the constraints of |
| 55 | +link:constitution/CONTRIBUTION-CONSTITUTION.adoc[Contribution Constitution] |
| 56 | +and `0-AI-MANIFEST.a2ml`. Automation may open issues only under the contract |
| 57 | +in link:../docs/ISSUE-INTAKE-SPEC.adoc[Issue Intake Specification] Rule 6. |
| 58 | + |
| 59 | +== Decision making |
| 60 | + |
| 61 | +* *Constitutional changes* — via link:constitution/CHANGE-PROCEDURE.adoc[Change |
| 62 | + Procedure]; they identify what they supersede. |
| 63 | +* *Normative standard changes* — proposal in an issue or PR, reviewed against |
| 64 | + the precedence test (link:constitution/AUTHORITY-AND-PRECEDENCE.adoc[Authority |
| 65 | + and Precedence]); a change that contradicts a higher class is a recorded |
| 66 | + contradiction, not a silent amendment. |
| 67 | +* *Local changes* (docs, scripts, config) — normal PR review; required checks |
| 68 | + on `main` are the mechanical floor. |
| 69 | +* *Owner rulings* — batched in the owner-decision register; a decision |
| 70 | + template issue names the register entry so one reply resolves a batch. |
| 71 | + |
| 72 | +== Communication |
| 73 | + |
| 74 | +* *Issues* — one issue, one actionable defect, correct scope, per the |
| 75 | + link:../docs/ISSUE-INTAKE-SPEC.adoc[Issue Intake Specification]. Estate-wide |
| 76 | + findings live in the estate register, not here. |
| 77 | +* *Pull requests* — the only path by which a change reaches `main` on the |
| 78 | + protected branches. |
| 79 | +* *Evidence* — claims in this repository that assert current state must |
| 80 | + carry their evidence (command + output, or the run that produced them). |
| 81 | + A number without a measurement method is a comment, not a claim. |
| 82 | + |
| 83 | +== Licensing |
| 84 | + |
| 85 | +This repository is licensed under MPL-2.0 (see `LICENSE`). Constitutional and |
| 86 | +RSR canon documents carry CC-BY-SA-4.0 headers per the estate licence axis. |
| 87 | +`LICENSES/` and the REUSE sidecars keep the per-file record; a file that cannot |
| 88 | +carry a header needs its sidecar (see the open REUSE findings in the issue |
| 89 | +tracker) — the record is part of the standard, not optional furniture. |
0 commit comments