Governance: registry roles (contributors, operations, review board)

[davidpesce]

This defines the registry's standing roles and how someone takes one on: contributors (no privileges, open to anyone), registry operations (day-to-day pull-request and issue work under the public runbooks, GitHub triage access, index-changing acts prepared as pull requests the lead merges), and the review board (the code reviews behind the Reviewed tier, working through pull-request approvals rather than write access). Applications for the two standing roles are private (volunteer@camp-registry.org or a direct message to the lead) and never published; appointments are announced on acceptance.

Open for comment from anyone; the substance most worth poking at is the operations access model (triage plus acts-as-pull-requests), the review-board conflict rules, and the bars for admission. Adoption follows the comment period, with a design-decision entry recording it.

[davidherney]

Hola @davidpesce

I have a few questions.

1. "The lead"—is that you right now? How do we know who has each role? Because some actions, like "send a direct message to the lead," require explicitly knowing who holds it.

2. I don't see a procedure for appointing the leader. What happens if the current leader can no longer do it? What happens if the leader goes to the dark side? Do the others just have to clone themselves and continue on their own?

3. What does the leader need to verify their suitability? This isn't clear in the rules. Is it my profile on moodle.org or the Moodle Tracker? Or directly my GitHub profile? What information do we need to provide?

Is this okay, or should we discuss it in the CAMP Chat?

Saludos

[davidpesce]

Thanks for these questions, keep them coming! Answers below:

1. Yes, I'm the current lead with Mike Churchward as my backup. Emails to the @camp-registry.org domain go to my email address for now.
2. Yeah, I got "nominated" because I was the one that didn't have anything to lose by posting publicly about it. I am also the main person who architected the registry. The design itself takes into account leadership changes. If there is ever anything I do as "lead" that the community doesn't like, the repo can be forked and maintained elsewhere. It's exactly like an open source project should be.
3. The verification is still in the works, but things like proven moodle plugin code, core contributions, community reputation will all be parts of it. People on the review board will have a lot of control over what is published and we want to maintain the same level of analysis as new members are onboarded.

[davidpesce]

The draft has been revised (5298272) following further design discussion. For anyone who read the first version, what changed:

• The single-lead merge model is replaced by a plural admins role. Any admin may merge a verified pull request. Machine-authored release PRs need no second human; the verification checks are the review. Human-authored PRs are merged by an admin who did not author them.
• One principle now heads the document and covers every role: no one certifies their own work.
• Reserved decisions (namespace determinations, removals for cause) require the written concurrence of two admins before enactment, and the enacting change is merged by an admin other than its drafter. The lead breaks ties.
• The ladder forks: registry operations is the path to admin, and the review board is a separate specialist track rather than a step toward admin. Direct entry on an established record remains open for every role.
• A new section defines selecting the lead: triggers (resignation, six weeks unreachable, or a call by two thirds of the electorate), a tenure-gated electorate (admins and board members with twelve months in role), a two-thirds threshold to pass, and a sunrise clause keeping the mechanism dormant while the electorate is smaller than five.
• Asset custody is explicit: registry assets transfer only on succession under that section, per a succession runbook, and the GitHub organization keeps at least two owners at all times.
• The organization two-factor requirement is spelled out: secure methods only, enforced mechanically by GitHub.

Comments welcome on all of it. The numbers in the selection section (twelve months, two thirds, five) and the admissions rules are the parts most worth pressure-testing.

[davidpesce]

One revision to the Merges bullet (99bdb73): it now keys the rule on what the checks establish rather than on who authored the pull request. camp-index#210 proposes letting fully machine-verified classes of pull requests merge automatically, starting with pipeline release publications; claims would join only once a proof-of-repo-control check exists. The reworded bullet covers both today's one-admin practice and that future without further amendment, keeps the non-author rule for everything that requires human judgment, and states the admin brake explicitly. If #210 does not move forward, the sentence still holds; the automatically merged set is simply empty.