Proposal: Add a more explicit incident response lifecycle to the Moderation Policy
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- documentation
Direzione di ricerca
Inizia da Moderation-Policy.md e confronta le sezioni esistenti relative a escalation, ricorsi e considerazione dell’intento con i CNCF Incident Resolution Procedures collegati. Esamina il ciclo di vita della proposta, le aggiunte relative ai conflitti di interesse e al divieto di ritorsioni, insieme ai feedback della tavola rotonda sulla moderazione. Il lavoro sarà completato quando sarà raggiunto il consenso e un PR aggiornerà la policy di conseguenza.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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).
[!NOTE]
This proposal has a bit more ambiguity than the others, and should be considered later in the session.
The policy covers content moderation but not larger CoC concerns
The Moderation Policy handles the common cases well: inappropriate posts in a public repo, and spam. Consideration of intent, self-correction opportunities, documentation requirements, and worked scenarios are all defined. Escalation and appeal paths exist.
What's missing is a default or suggested lifecycle for reports that aren't resolved by moderating a single post. Larger-scoped CoC violations have less written guidance for us all to align against. This routinely leaves moderation team members to continually do their best to evaluate many factors at once, and the ambiguity can impact SLAs for moderation and repair.
Some gaps against the policy as written, in my opinion:
- Someone emails
report@nodejs.orgabout an incident, pattern of behavior, a private conversation, or a serious CoC violation. We don't mention acknowledgement to the reporter or the accused. - A report involves conflicting accounts. There is no process for resolving factual disagreements.
- The team needs to check jurisdiction: is this ours, the TSC's (PR #990), or the OpenJS CoC Team's?
- A moderator has a relationship with the accused but is not "directly involved." The recusal requirement only covers direct involvement.
I've done a bit of research and noted that other projects, in particular the CNCF, have better outlined procedures. We can mature here.
Gaps relative to CNCF
The CNCF Incident Resolution Procedures cover these cases. Not all of it applies to a volunteer team, but the structure is useful reference.
| Step | CNCF | Node.js |
|---|---|---|
| Acknowledge receipt | Yes | Reporting channels defined, no acknowledgment step |
| Confirm jurisdiction | Explicit check; transfer or escalate | Not addressed (escalation/appeal paths exist but no intake check) |
| Investigation | Review evidence, interview witnesses | Consideration of intent only |
| Notify the accused | Yes, balances retaliation risk | Collaborators get a chance to self-correct; no general notification step |
| Interim protective measures | Explicit authorization during investigation | Temp blocks exist but not framed as interim measures |
| Conflict of interest | Hard/soft definitions with procedures | Recuse if "directly involved" |
| Communicate results | Defines what to tell reporter and accused | Not addressed |
| No retaliation | Explicit | Not addressed |
The below here would turn into a PR against the Moderation Policy. I include it here for early feedback, and then expect to draft a PR.
Add to the Moderation Policy:
Proposed lifecycle
1. Receive and acknowledge. A moderator acknowledges receipt to the reporter.
2. Confirm jurisdiction. Is this governed by the Node.js CoC? Does the accused's role change who handles it (TSC members per PR #990)? Should this be escalated to the OpenJS CoC Team? If not ours, transfer and notify the reporter.
3. Assess interim protective measures. If there is active harm, the team may hide content, set interaction limits, or temporarily block before the investigation is complete.
[!NOTE]
This is a substantial addition, for us to consider carefully.
4. Investigate. Review available evidence. Contact the reporter for clarification. Interview witnesses where appropriate. Consider intent per existing policy. Write down our evidentiary threshold, per comments in https://github.com/openjs-foundation/cross-project-council/issues/1701#issuecomment-4063822741
5. Notify the accused. Inform them a report was received. Give them an opportunity to respond. Do not disclose the reporter's identity without consent.
6. Decide. Determine action, referencing the enforcement ladder in the Code of Conduct. Document the decision and rationale in nodejs/moderation.
7. Communicate results. Inform the reporter of the outcome. Inform the accused of any action taken and the appeals process.
Conflict of interest
A moderator has a conflict of interest if they are personally involved (reporter, accused, or witness), have a close personal or professional relationship with someone involved, or have another interest that would affect their impartiality. Conflicted moderators disclose and recuse.
No retaliation
Retaliation against someone who reports a CoC concern in good faith or provides information during an investigation is itself a CoC violation.
Not included
This proposal does not cover specific timelines (see SLA proposal), but the two proposals would intertwine and be stewarded by a chair per that proposal.
Prior art
- CNCF Incident Resolution Procedures
- Python PSF Enforcement Procedures
- Contributor Covenant 3.0 "Reporting an Issue" section
Action items
- Feedback period before and during Collab Summit
- PR to add the lifecycle to the Moderation Policy, where more consensus explored
Assisted by: Claude Opus
- Lingua principale
- JavaScript
- Stelle
- 202
- Fork
- 183
- Merge medio
- 2m
- PR unite (30g)
- 1
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nodejs/admin
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 35/100
-
tsc-agenda
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Tutte le issue di nodejs/admin
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
avniproject/avni-client#2135 ·
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
babalae/bettergi-scripts-list#3674 ·
-
A-Release-Notes C-Editing D-Modest S-Ready-For-Implementation
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
bevyengine/bevy-website#2595 ·
-
ecosystem wording
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
matrix-org/matrix.org#3649 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
vadimdemedes/ink#1029 ·