Proposal: Reduce moderator permissions and document what moderators can and cannot do

Start with this proposal and the linked openjs-foundation/summit#511 discussion, then read Moderation-Policy.md and ONBOARDING.md. Review the existing requirements for documenting decisions in nodejs/moderation. Done means consensus is reached, escalation owners are designated, the policy and onboarding boundaries are documented, and the stated permission changes are made.

Part of the moderation policy review framed by openjs-foundation/summit#511, for discussion at the Moderation Roundtable on October 1 (if not resolves to consensus prior).

Moderation staff hold org-wide control of Node.js

Because the Moderation Policy assumes org-owner access, eight moderation team members currently hold immense permissions incongruent with their typical role requirements. This makes them targets for threat actors.

Org-owner means the ability to:

• Delete any repository in the organization
• Read and rotate organization secrets and tokens
• Override branch protection and push to protected branches
• Alter CI/CD workflows
• Add or remove organization members
• Transfer repositories out of the organization
• Manage billing

That is a lot of power to hold for a role whose daily work is de-escalating conflict, closing or hiding spam, and blocking drive-by accounts. I suggest it is not power any of us needs in order to moderate.

Any one of those eight accounts, compromised, gives an attacker a lot of space to vandalize the project or cause harm. We have recently seen attacks targeting Node.js maintainers. This proposal may be the most security-minded improvement we can make to Node.js.

Reduce to what moderation actually requires

• Retain the Organization Moderator role
• Remove org-owner from anyone who does not hold it for other reasons
• Keep their existing write access to the private nodejs/moderation repo
• Add explicit write access to nodejs/node - the repo with the most activity

[!NOTE]
This will not cover everything. That is the tradeoff, but it feels necessary to reduce risk.

This proposal is to write the resulting boundaries into the policy so that moderators, reporters, and Collaborators all know where the limits sit.

The boundaries this creates

Any moderator can do these, across every public repo in the organizations, without asking anyone:

• Block and unblock non-members: spammers, bots, drive-by CoC violations
• Set interaction limits, org-wide or per repository
• Hide and unhide comments

A moderator can do these only where they already have write on the repository, which most of us do on the repos we work in as Collaborators:

• Edit, delete, or lock posts
• Hide comments in private repos, which the Moderator role does not reach

[!WARNING]
There is no way to extend this org-wide without granting write on every repository, and write includes push. Hiding is the action that works everywhere, and it is reversible and leaves an audit trail, so it should be the default.

These existing (potential) moderation team actions now require escalation

These seem to be the actions we have historically needed org-ownership for, yet, in practice, occur rarely. We don't need powerful permissions for such rare occurrences. But we should document what we'd do in these cases:

• Removing someone from the organization
• Blocking a Collaborator, which GitHub only permits after org removal

The process: document the decision in nodejs/moderation as the policy already requires, then request execution. Org owners engaged.

Moderators can no longer do these at all, and should not be asked to:

• Anything on the org-owner list above

The open question

Who holds owner for escalations, and how are they designated? Does the TSC have this power? Chairs only? Easy to determine and document.

Action items

• Consensus the change is warranted considering AS-IS permission model and risks
• Designate the org-owners who handle rare removals
• Add the boundaries above to the Moderation Policy as a permissions section
• Make the permission changes
• Edit moderation onboarding

---

Assisted by: Claude Opus

---