Skip to content

Session Proposal: Node.js Moderation Roundtable and Proposal Review #511

Open

Description

@bmuenzenmeyer

Proposal

Topic of the session

Moderation Roundtable and Proposal Review

Type of the session

  • Collaborate
  • Workshop
  • Talk

Estimated duration of the session

1 hour

Date and Time of the session

October 1st - time TBD at Node.js Collaboration Summit - 1st of October 2026 - Bologna, Italy

Level

  • Beginner
  • Intermediate
  • Advanced

Pre-requisite knowledge

It would be helpful for attendees to be aware of these resources prior to the session:

Describe the session

Over the course of the last year or so, we've observed some potential improvements to both inward and outward facing Moderation policy. This session is dedicated time to discuss as a larger group and work closer towards official consensus via GitHub. This session proposal acts as a top-level issue framing the initiative, with each individual proposal opened as separate items to independently seek consensus on. Brian and Ethan will facilitate discussion through as many as we can.

Running List / Agenda as Brian and Ethan have time to prepare docs:

Session facilitator(s), Github handle(s) and timezone(s)

Brian Muenzenmeyer (@bmuenzenmeyer) - in person, Ethan Arrowwood (@Ethan-Arrowood) - remote

Meeting notes and Virtual Meeting Link

Follow-up / Set-up sessions (if any)

Additional context (optional)

@aduh95 encouraged me to share the prompt. it's a very long conversation with claude, directed and redirected (over and over) by @bmuenzenmeyer. all proposal documents were 100% read by a human before opening

share link: https://claude.ai/share/7564bf91-7060-47ed-b323-c8708b4425ae


Activity

  1. bmuenzenmeyer commented on Sep 30, 2026

    @bmuenzenmeyer
    Author

    Moderation Roundtable: 60 min

    Time Item TL;DR
    9:30 – 9:35 Intro Norms, pick a timekeeper
    9:35 – 9:47 #1092 Reduce moderator permissions In the interests of security, drop org-owner from moderators; keep the Org Moderator role; escalate rare removals to designated owners
    9:47 – 9:57 #1093 Moderation SLAs Response times for reports, issues, tags (24–48h) and onboarding (45 days max)
    9:57 – 10:05 #1094 Moderation team chair Yearly chair who keeps SLAs, reports and recertification moving; no veto, no extra permissions
    10:05 – 10:17 #1096 Incident response lifecycle 7-step process for bigger CoC reports, plus conflict-of-interest and no-retaliation rules
    10:17 – 10:25 #1097 Contributor Covenant 3.0 Upgrade the CoC to v3; review the notable new clauses
    10:25 – 10:30 Wrap-up Owner and next step per item

    If an item runs over, cut from #1097 first, since it can continue on the PR.

  2. benjamingr commented on Oct 1, 2026

    @benjamingr

    Just async comments:

    In the interests of security, drop org-owner from moderators; keep the Org Moderator role; escalate rare removals to designated owners

    Honestly I don't think we need this (wouldn't impact me with my org-owner role anyway - but still) - in practice we've tried this several times in the past and had no significant abuse due to moderators having org owner in ~10 years of the moderation team existing. As far as I remember only thing close is refack in ~2018 which was a very different story (and one or two small mistakes that were corrected/fixed).

    In any case I think moderator permissions is a question for the TSC and not the moderation team - it's really important to me the moderation team is able to act quickly and moderators are trusted in their role to manage incidents in a pinch. Moderator actions are fully auditable through the audit log.

    I'm fine if there is a JIT access flow (moderator pings a slack bot to get admin permissions temporarily) but I would want to not block this on other people being available.

    In practice - GitHub admin permissions aren't super scary and don't gate the actual scary stuff (the release ci which is separate, hackerone/incidents if that ever works again, release keys etc).

    Response times for reports, issues, tags (24–48h) and onboarding (45 days max)

    I agree ideally we'd have more help but to be fair moderation has been much more quiet in the last 3-4 years (yay!) with weeks without incidents at a time (which is a good thing but also a reduction in "hype").

    We're all volunteers why would we want to impose SLAs? We tried PagerDuty before (2017? @hackygolucky maybe remembers) I don't recall it working particularly well. I'd expect SLAs (and people being on call) would require funding and I doubt the TSC has an appetite for that.

    7-step process for bigger CoC reports, plus conflict-of-interest and no-retaliation rules

    I think the harder interpersonal stuff is hard and tricky enough and any process we impose is going to just complicate things. The current escalation paths make sense to me. What's missing with OpenJS CoC is arguably an explicit allowance to share information between CoC teams (or a process other than asking the TSC through a moderation team tsc member).

    As for relationships - I think the process (people self recusing) work well enough and moderators should be trusted to a high standard to do so. Moderation is about dealing with conflicts and the tricky parts in an empathic way and trying to de-escalate and create a collaborative environment.

    Retaliation against someone who reports a CoC concern in good faith or provides information during an investigation is itself a CoC violation.

    SGTM though this needs a TSC vote (and probably/maybe CPC board approval?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions