Update the GItHub management policy for Moderation

[Trott]

We now have access to a beta feature that permits a moderation role in the org. (Thanks, @bnb!) It doesn't quite allow the moderation team to do everything they currently can do, but it seems close and I'd like to give it a try. We can always flip things back if it doesn't work out.

@nodejs/tsc @nodejs/moderation

[ljharb]

Does this new feature also include the ability to edit/hide/delete comments, including editing offensive info out of issue/PR titles?

[Trott]

Does this new feature also include the ability to edit/hide/delete comments, including editing offensive info out of issue/PR titles?

Probably not, but if that proves to be a big problem, we can switch back.

[ljharb]

It's infrequent, but those capabilities are pretty important to fulfill the role.

It seems like perhaps changing it wholesale for everyone might be a bit premature, until we've had a moderator or three volunteer to try it out and make sure it will suffice? That'd also likely help Github, since we could provide that feedback.

[mcollina]

lgtm

[Trott]

It seems like perhaps changing it wholesale for everyone might be a bit premature,

That would be true if this were a change that was difficult to reverse. It's easy to switch back to Owner roles if it doesn't work.

until we've had a moderator or three volunteer to try it out and make sure it will suffice?

This would effectively be that. I am a TSC member so I will retain Owner role, and I do most of the moderation actions on GitHub anyway (at least the easy ones anyway). The rest of y'all will be Moderation role and we'll see how that does or doesn't work. At least, that's what I'm proposing.

[benjamingr]

@ljharb @Trott I think this is probably fine to turn on for everyone but if you want a trial I am happy to volunteer for it.

A few things I'd like moderators to have access to (not sure if that's the case):

• The audit log (ability to track a user's activity and look for patterns of abuse or none).
• Ability to delete comments (editing would be nice but deleting would probably be sufficient - 95% of cases already successfully resolve with self-moderation).
• The ability to block users (ideally we can give this to more people outside the moderation team too in order to deal with spammers/bots more quickly - not sure if the granularity level of "let members block non-members and let TSC/moderation block anyone" is possible).
• Full access to discussions/issues (for example a non-collaborator moderator should be able to see https://github.com/orgs/nodejs/teams/collaborators in order to moderate it.

[benjamingr]

I'd like to also remind everyone that we did in fact have issues in the (distant) past where a moderation team member (no longer in the team) used their owner privilege to perform non-moderation actions (not in bad faith and because they were concerned about a security-related issue but still).

So while I think the level of trust inside the project and inside the moderation team is much higher (which is great!) I'm not sure it'll always stay that way and I feel strongly that moderation as non-Owners should be a goal.

[ljharb]

I am 100% in favor of that goal - I don't want to be an owner, and I want to be able to freely review PRs without risking my review being mistaken as being from a collaborator ;-)

I don't think that goal is more important than all moderators being able to freely and rapidly respond effectively when things come up.

Effectively, the permissions we need (also enumerated above) are full issue/PR/discussion editing/closing/comment-deletion capability; full audit log access; block/unblock; all moderation settings (cooldowns, responding to reports, etc); the things we do NOT need and ideally would not have are the ability to have PR reviews count as "maintainers"; the ability to merge PRs or push commits; the ability to delete/transfer repos/issues; the ability to manage access to individual repos/teams (in the event that becomes necessary, it's perfectly fine to pull in a TSC member, imo).

[Trott]

@ljharb @Trott I think this is probably fine to turn on for everyone but if you want a trial I am happy to volunteer for it.

A few things I'd like moderators to have access to (not sure if that's the case):

• The audit log (ability to track a user's activity and look for patterns of abuse or none).
• Ability to delete comments (editing would be nice but deleting would probably be sufficient - 95% of cases already successfully resolve with self-moderation).
• The ability to block users (ideally we can give this to more people outside the moderation team too in order to deal with spammers/bots more quickly - not sure if the granularity level of "let members block non-members and let TSC/moderation block anyone" is possible).
• Full access to discussions/issues (for example a non-collaborator moderator should be able to see https://github.com/orgs/nodejs/teams/collaborators in order to moderate it.

@benjamingr If you want, I could make you a moderator and remove your owner permissions (temporarily or otherwise) and you can check all these things and report back.

[Trott]

Effectively, the permissions we need (also enumerated above) are full issue/PR/discussion editing/closing/comment-deletion capability; full audit log access; block/unblock; all moderation settings (cooldowns, responding to reports, etc); the things we do NOT need and ideally would not have are the ability to have PR reviews count as "maintainers"; the ability to merge PRs or push commits; the ability to delete/transfer repos/issues; the ability to manage access to individual repos/teams (in the event that becomes necessary, it's perfectly fine to pull in a TSC member, imo).

@ljharb Same offer I made to @benjamingr now goes to you too! If you want, I could make you a moderator and remove your owner permissions (temporarily or otherwise) and you can check all these things and report back.

Looking at the interface for adding/removing people from Moderator role, it doesn't look like there are any knobs to tweak to dial things up or down. It looks like it's org-wide, and you get what you get. So it should be pretty straightforward for now to document what's available and what's not.

The only information provided in the interface is this:

Moderators can block and unblock users from the organization, and manage interaction limits for all public organization repositories.

It sounds like it is more limited than what y'all are talking about above, but I don't actually know that. I'm assuming that the bit of text quoted is a complete description, but perhaps it is not.

[ljharb]

Happy to try it out and report back.

[Trott]

Happy to try it out and report back.

@ljharb You are now a Moderator without Owner privileges. If/when you want/need to be switched back to Owner, let me know here or in the Moderator Slack!

[ljharb]

So, immediately I see I can't edit or hide comments on this very issue, nor the issue title. Going to "settings" only shows me the three "interaction limits" settings.

Without even the ability to hide comments, this role seems pretty useless to us, unfortunately. How can we provide feedback to Github about what we need?

[Trott]

How can we provide feedback to Github about what we need?

I'd say ask @bnb in the Moderation Slack.

[benjamingr]

Happy to try it out too @Trott