From fae786d091134efe7a65e7ffa596e2eef63fd2bd Mon Sep 17 00:00:00 2001 From: camp project Date: Wed, 5 Aug 2026 15:30:59 -0400 Subject: [PATCH 1/3] =?UTF-8?q?governance:=20registry=20roles=20=E2=80=94?= =?UTF-8?q?=20contributors,=20operations,=20review=20board?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- governance/ROLES.md | 73 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 governance/ROLES.md diff --git a/governance/ROLES.md b/governance/ROLES.md new file mode 100644 index 0000000..a543482 --- /dev/null +++ b/governance/ROLES.md @@ -0,0 +1,73 @@ +# Registry roles + +Who does what in the registry, how someone takes on a role, and where +each role's authority ends. Three roles form a ladder; each admits from +demonstrated work in the one below, though direct entry stays possible +for people with an established record elsewhere in the Moodle community. + +Applications for any role are private (volunteer@camp-registry.org, or +a direct message to the lead in the CAMP Matrix room) and are never +published, accepted or not. Appointments are announced publicly when +someone accepts a role. Declining or leaving a role carries no public +record beyond the appointment ending. + +## Contributors + +Anyone, no privileges, no application. Contribution is showing up on +the work itself: evidence on the review queues, seeding verification, +documentation and display-name fixes, client testing, mirrors. The +contribute page on the site lists the current lanes. This work is also +how the registry gets to know people: admissions to the roles below +point at it. + +## Registry operations + +The day-to-day help: working claim and release pull requests, removal +and seed requests, repoint evidence, author questions, and issue +triage across the registry repositories. + +- **Procedure**: the public runbooks (camp-docs runbooks/) are the + operations manual. Each runbook ends its judgment at an explicit + escalation list; anything on those lists goes to the lead. An + operator never needs to guess where their authority ends. +- **Access**: GitHub triage permission on camp-index (label, respond, + assign, close). No code write. Registry acts that change the index + (removals, repoints, seeds) are prepared by the operator as pull + requests and merged by the lead; the operator's work product is a + prepared decision, the lead's click is the act. +- **Bar**: a track record of correct queue work as a contributor, or + an established identity in the Moodle community; organization + two-factor enforcement applies. +- **Admissions**: private application, decided by the lead against + this bar; outcome announced on acceptance. +- **Tenure**: lapses after sustained inactivity; step down any time by + telling the lead; removal for cause is the lead's call. + +## Review board + +The code reviews behind the registry's Reviewed tier (tier 3). + +- **Scope of a review**: defined by the review checklist the board + maintains publicly (code standards, security lint findings, plugin + correctness against its declared metadata). A camp review is not a + commissioned security audit; the registry's security-review display + (MDLShield) remains a separate, registry-level surface. +- **Access**: reviews land as pull-request approvals and recorded + review documents. Board membership does not grant write access to + the index; merges remain with the lead. +- **Conflicts**: board members do not review plugins they maintain, + contributed to substantially, or that their employer distributes; + conflicts are declared on the review. +- **Bar**: demonstrated Moodle code-review competence (registry + operations work, plugin maintainership, or an established review + record elsewhere), identifiable identity, organization two-factor. +- **Admissions**: private application, decided by the lead with the + sitting board against this bar; outcome announced on acceptance. +- **Tenure**: as registry operations. + +## The lead + +Holds the merge rights on the index, the final call on escalations, +namespace determinations, admissions, and removals for cause. The +runbooks' escalation lists and this document are the public record of +what only the lead decides. From 5298272551f2343041b1f3fd28a1fbe9b9d8f965 Mon Sep 17 00:00:00 2001 From: David Date: Fri, 7 Aug 2026 09:57:02 -0400 Subject: [PATCH 2/3] governance: admins role, succession, and capture defenses Rework ROLES.md from the single-lead model to a plural admins role: any admin merges, human-authored PRs are merged by a non-author, reserved decisions carry two-admin written concurrence. Adds the no-self-certification principle, the two-track ladder (operations is the path to admin; the review board is a destination, not a rung), lead selection with tenure-gated two-thirds voting and a sunrise clause below five electors, asset custody via a succession runbook, and spells out the org two-factor requirement. --- governance/ROLES.md | 122 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 98 insertions(+), 24 deletions(-) diff --git a/governance/ROLES.md b/governance/ROLES.md index a543482..3df39b1 100644 --- a/governance/ROLES.md +++ b/governance/ROLES.md @@ -1,15 +1,24 @@ # Registry roles Who does what in the registry, how someone takes on a role, and where -each role's authority ends. Three roles form a ladder; each admits from -demonstrated work in the one below, though direct entry stays possible -for people with an established record elsewhere in the Moodle community. +each role's authority ends. One principle underlies every rule here: +no one certifies their own work. Admins do not merge changes they +authored, review board members do not review plugins they maintain, +and authors do not verify their own releases. -Applications for any role are private (volunteer@camp-registry.org, or -a direct message to the lead in the CAMP Matrix room) and are never -published, accepted or not. Appointments are announced publicly when -someone accepts a role. Declining or leaving a role carries no public -record beyond the appointment ending. +Two tracks grow from a common base. Contributors who take up queue +work become registry operations, and a sustained record in operations +is the path to admin. The review board is a separate specialist track +for code review: a destination in its own right, not a step toward +admin. Roles are appointed for the work they do, not as steps toward +other roles. Direct entry to any role stays possible for people with +an established record elsewhere in the Moodle community. + +Applications for any role are private (volunteer@camp-registry.org, +or a direct message to an admin in the CAMP Matrix room) and are +never published, accepted or not. Appointments are announced publicly +when someone accepts a role. Declining or leaving a role carries no +public record beyond the appointment ending. ## Contributors @@ -17,8 +26,7 @@ Anyone, no privileges, no application. Contribution is showing up on the work itself: evidence on the review queues, seeding verification, documentation and display-name fixes, client testing, mirrors. The contribute page on the site lists the current lanes. This work is also -how the registry gets to know people: admissions to the roles below -point at it. +how the registry gets to know people. ## Registry operations @@ -28,20 +36,24 @@ triage across the registry repositories. - **Procedure**: the public runbooks (camp-docs runbooks/) are the operations manual. Each runbook ends its judgment at an explicit - escalation list; anything on those lists goes to the lead. An + escalation list; anything on those lists goes to the admins. An operator never needs to guess where their authority ends. - **Access**: GitHub triage permission on camp-index (label, respond, assign, close). No code write. Registry acts that change the index (removals, repoints, seeds) are prepared by the operator as pull - requests and merged by the lead; the operator's work product is a - prepared decision, the lead's click is the act. + requests and merged by an admin; the operator's work product is a + prepared decision, the admin's click is the act. - **Bar**: a track record of correct queue work as a contributor, or - an established identity in the Moodle community; organization - two-factor enforcement applies. -- **Admissions**: private application, decided by the lead against + an established identity in the Moodle community. The GitHub + organization requires two-factor authentication with secure + methods (authenticator app, passkey, or hardware key; not SMS). + GitHub enforces this mechanically: an account without it cannot + join the organization, so it applies to every role with access. +- **Admissions**: private application, decided by the admins against this bar; outcome announced on acceptance. - **Tenure**: lapses after sustained inactivity; step down any time by - telling the lead; removal for cause is the lead's call. + telling an admin; removal for cause is a reserved decision of the + admins. ## Review board @@ -54,20 +66,82 @@ The code reviews behind the registry's Reviewed tier (tier 3). (MDLShield) remains a separate, registry-level surface. - **Access**: reviews land as pull-request approvals and recorded review documents. Board membership does not grant write access to - the index; merges remain with the lead. + the index; merges remain with the admins. - **Conflicts**: board members do not review plugins they maintain, contributed to substantially, or that their employer distributes; - conflicts are declared on the review. + conflicts are declared on the review. A board member's own plugin + can still reach the Reviewed tier: another member reviews it under + the same checklist. - **Bar**: demonstrated Moodle code-review competence (registry operations work, plugin maintainership, or an established review record elsewhere), identifiable identity, organization two-factor. -- **Admissions**: private application, decided by the lead with the +- **Admissions**: private application, decided by the admins with the sitting board against this bar; outcome announced on acceptance. - **Tenure**: as registry operations. +## Admins + +The registry's maintainers: merge rights on the index, and the +authority the runbooks route upward. + +- **Merges**: any admin may merge a pull request that passed + verification. Machine-authored pull requests (release publications + from the pipeline) need no second human; the verification checks + are the review, and an admin may merge them even for a plugin they + maintain. Human-authored pull requests are merged by an admin who + did not author them. +- **Reserved decisions**: namespace determinations and removals for + cause. Each is recorded in writing with the concurrence of two + admins before it is enacted, and the enacting change is merged by + an admin other than its drafter. When the admins disagree, the lead + decides, and the record says so. +- **Admissions**: private application, decided by the sitting admins. + Admins are admitted one at a time. Admission to any role is decided + by the admins and is never put to a vote of the wider roles. +- **Bar**: a sustained record of correct registry operations work, or + an established identity in the Moodle community; identifiable + identity; organization two-factor enforcement. +- **Tenure**: lapses after sustained inactivity; step down any time; + removal of an admin for cause is a reserved decision of the other + admins. + ## The lead -Holds the merge rights on the index, the final call on escalations, -namespace determinations, admissions, and removals for cause. The -runbooks' escalation lists and this document are the public record of -what only the lead decides. +One of the admins serves as lead. The lead breaks ties among the +admins, holds the final call on escalations, represents the registry +externally, and maintains the succession runbook: the inventory of +the registry's assets (organization ownership, domain, hosting and +service accounts, the artifact archive) and the custodian of each. +The GitHub organization keeps at least two owners at all times. + +## Selecting the lead + +The project began with a founding lead. This section defines how the +role passes on. + +- **Triggers**: a selection runs when the lead resigns or retires; + when the lead has been unreachable for six weeks without notice, in + which case the admins jointly hold the lead's calls immediately and + a selection follows; or when two thirds of the electorate call for + one. +- **Electorate**: admins and review board members who have held their + role for at least twelve months. A selection passes at two thirds + of the electorate. +- **Sunrise**: while the electorate is smaller than five, this + mechanism is dormant. Succession is then by the lead's designation + with public notice, and the call-for-selection trigger does not + operate. +- **Nomination**: an outgoing lead may nominate a successor. The + nomination informs the vote; it does not decide it. +- **Alternative**: by the same two-thirds, the electorate may instead + vest the lead's calls in the admins jointly and leave the role + vacant. +- **Custody**: registry assets transfer only on succession under this + section, per the succession runbook. + +A design note on the numbers: the twelve-month tenure requirement, +the two-thirds threshold, and admin-decided admissions are +deliberate. They slow legitimate voices as well as hostile ones. The +registry accepts that trade because a small team is most exposed to +capture through its own growth, and these rules make a takeover +require years of correct public work. From 99bdb73710cbf5b9ba4298edf61f12c2698e6da6 Mon Sep 17 00:00:00 2001 From: camp project Date: Fri, 7 Aug 2026 12:18:19 -0400 Subject: [PATCH 3/3] governance: key the merge rule on verification, not authorship Pull requests whose assertions the checks fully establish may merge automatically as a registry act, with new classes admitted only through the public design record (camp-index#210) and the admin brake stated explicitly. The non-author rule is unchanged for everything that requires human judgment. --- governance/ROLES.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/governance/ROLES.md b/governance/ROLES.md index 3df39b1..f601ab8 100644 --- a/governance/ROLES.md +++ b/governance/ROLES.md @@ -85,11 +85,15 @@ The registry's maintainers: merge rights on the index, and the authority the runbooks route upward. - **Merges**: any admin may merge a pull request that passed - verification. Machine-authored pull requests (release publications - from the pipeline) need no second human; the verification checks - are the review, and an admin may merge them even for a plugin they - maintain. Human-authored pull requests are merged by an admin who - did not author them. + verification. The dividing line is what the checks establish, not + who authored the change. Pull requests whose assertions the + verification checks fully establish (release publications from the + pipeline today; further classes only as the public design record + admits them, camp-index#210) are reviewed by the checks alone and + may merge automatically as a registry act; an admin may also merge + them by hand, even for a plugin they maintain, and any admin may + hold, close, or revert one. Pull requests that require human + judgment are merged by an admin who did not author them. - **Reserved decisions**: namespace determinations and removals for cause. Each is recorded in writing with the concurrence of two admins before it is enacted, and the enacting change is merged by