meta: moderation policy updates #276

jasnell · 2017-05-31T02:47:34Z

@nodejs/tsc @nodejs/community-committee ... this is a proposed update to the moderation policy that accomplishes a number of things:

It establishes a Moderation Team responsible for enforcement.
- Members of this Moderation Team are selected by both the TSC and CommComm.
- The Moderation Team must regularly report all moderation actions to both committees.
- All Moderation actions may be overturned only through simple majority vote of both committees.
It relaxes the 24 hour rule for moderation on collaborator posts
It makes changes to the moderation policy the responsibility of both the TSC and CommComm
It clarifies temporary 24-hour bans vs. permanent bans
It permits the Moderation Team to use GitHub's new Temporary Interaction Limits

Trott · 2017-05-31T03:36:25Z

Moderation-Policy.md


 ### Modifications to This Policy

-Modifications to this policy are made through normal [TSC motion and vote](https://GitHub.com/nodejs/TSC/blob/master/TSC-Charter.md#section-8-voting). Any Collaborator may submit a PR proposing changes to this policy. Those PRs must be labeled using the `tsc-agenda` label. Including a mention to `@nodejs/tsc` can be used to call the issue to TSC's attention.
+Modifications to this policy are subject to approval by both the TSC and CommComm. If there any objections to any proposed change, a simple majority vote of all CommComm and TSC members is required.


This is unclear as to whether every person gets one vote or whether the two committees vote separately. In other words, is it one big mega-committee and everyone gets one vote? Or do the TSC and CommComm vote separately and each committee has to have a majority for it to pass?

(Example just in case I'm still not being clear: Let's say the TSC has 20 members but CommComm only has 15 and there is no overlap. If TSC votes unanimously to pass and CommComm votes unanimously to reject, is it passed because it's 20-15 for the change, or is it rejected because while it passed on the TSC, it did not pass on CommComm?)

BTW, this appears to apply to the other two instances of simple majority in the doc.

Good question. I don't know which is best. Opinions?

A simple majority in this case would not work if it is just the TSC and CommComm as voters. Since there are only 2 then every vote would have to be unanimous (or I suppose have an abstain). I'd suggest is should be that both TSC and CommComm have to agree, each holding their own votes.

A simple majority in this case would not work if it is just the TSC and CommComm as voters.

@mhdawson Yeah, that's self-evidently silly and I wasn't suggesting that. I was asking if it meant a simple majority of the members of both committees (combined) or a simple majority on each committee (so both committees must pass it). I imagine the latter was meant but that's not clear from the text.

To be honest, I didn't mean one way or the other ;-) ... I'm open to suggestions. I'm leaning towards one vote for the TSC, one vote for the CommComm, and it must pass in both. The one issue I can see there (that may not be all that important) is that the overlap in the TSC/CommComm membership means that some individuals would get to vote twice.

A simple majority of TSC + a simple majority of CommComm seems reasonable to me.

I have some thoughts on this, but I'll wait till after the TSC meeting on this one so we can discuss #270 first. This PR and that issue don't fully align, and I think we should figure out #270 first before working through the details of this section IMO.

So I've been thinking about this for a while, and I'm not sure which approach I like best.

Each Community Votes Separately

I like this concept more than combining the members into a mega committee, but it has some issues I haven't been able to work around yet.

I think that the voting mechanism should be left up to each committee to decide. I would recommend that we follow the normal process for changing policies, aka consensus w/ fallback to vote. I don't think that requiring a vote is necessary in most cases and will probably add unnecessary overhead.

Each committee needs to keep track of it's own part of the discussion. This implies we would need to have an issue opened in each committee's repo to track discussion so that we don't mash votes together in the case of voting, and that we don't mash consensus between the two committees together.

This has the disadvantage of fracturing the conversation into two places. This may be acceptable, but I do see the possibility of different viewpoints not being considered because they originated in an issue for a committee half of the folks aren't members of.

Some people will be involved in the discussion twice. This is less important during consensus seeking, but raises questions during voting. Should people be allowed to effectively "vote twice"?

On the one hand, it's possible for some individuals to have more influence than others, which can be discouraging

On the other hand, if someone is involved in both groups, they're probably putting more work in and have context that folks only involved in one committee don't have, so having "two votes" may actually make sense.

Form a mega-committee from members of each committee

This simplifies all of the problems that separating by each committee has. I think the primary downside though is that each committee brings a unique perspective to moderation, and I feel that this is something we don't want to loose in the deliberation process.

How about we do a "mega-committee" for now, but revisit this in the future, when the CommComm becomes more established? I’d only see a problem with the number of members in TSC & CommComm diverge too much. Maybe each committee could send in a limited amount of members to the vote, either decided voluntarily or if no consensus can be found, by random?

addaleax

I like the direction in which this is moving 👍

addaleax · 2017-05-31T22:09:04Z

Moderation-Policy.md

 * *Post* refers to the content and titles of any issue, pull request, comment or wiki page.
 * *Moderate* refers to the act of modifying the content and title of, or deleting, any Post for the purpose of correcting or addressing Code of Conduct violations.
 * *Remove* refers to the act of removing the configured write (commit) permissions for an individual Collaborator's GitHub account from *all* Node.js GitHub Organization repositories as well as removing the account from the Node.js GitHub Organization membership.
-* *Ban* refers to the act of blocking an individual GitHub account from any further participation in the Node.js GitHub Organization.
+* *Ban* refers to the act of blocking an individual GitHub account from any further participation in the Node.js GitHub Organization. Bans may be *temporary* (24 hours) or *indefinite*.


Does it make sense to fix a time limit here?

addaleax · 2017-05-31T22:11:01Z

Moderation-Policy.md

+* Any Collaborator with commit rights to a given repository may Moderate Posts within that repository's issue tracker.
+* The Moderation Team serves as the final arbiter for all Moderation issues.
+* Moderation Team members may Remove or Ban an individual from the Node.js GitHub Organization.
+* For any Removal or Banning action, an issue describing the reasons for the action, and identifying the Github account being acted upon, must be posted to the Moderation Repository with an explanation provided by the Moderation Team member performing the action.


This means a) that TSC members may no longer ban people even if we’re dealing with e.g, obvious trolls, and b) that Moderation Team members become org admins. Right?

Yeah, this is a part I'm not entirely sure on yet. org owners have access to lots of things that it may not make sense for moderators to have access to (the security repo, for instance). We need to be sure about this.

addaleax · 2017-05-31T22:15:09Z

Moderation-Policy.md


-The nodejs/moderation Repository is used to discuss the potentially sensitive details of any specific moderation issue. The repository is private but accessible to all Collaborators. The details of any issue discussed within the nodejs/moderation repository are expected to remain confidential and are not to be discussed in any public forum or social media service.
+Twice per month, the Moderation Team must provide a report of all Moderation actions taken by the Moderation Team to both the CommComm and TSC.


How about making that report public?

That depends on what would be included, I think.

I would be in favor of making statistics publicly available. We could indicate that x number of posts were moderated and y number of people were banned and how long they were banned for. I don't think we should include anything more than that though.

Doing this twice a month with public reporting sounds fairly cumbersome

nebrius · 2017-05-31T20:07:35Z

Moderation-Policy.md

@@ -19,7 +19,7 @@ If you are not a member of the Node.js GitHub Organization and wish to submit a

 By default, this policy applies to all repositories under the Node.js GitHub Organization and all Node.js Working Groups.

-Individual Working Groups and Top Level Projects chartered by the TSC may adopt an alternative Moderation Policy for any repository under their stewardship so long as:
+Individual Working Groups and Top Level Projects may adopt an alternative Moderation Policy for any repository under their stewardship so long as:
 * The Moderation Policy is openly documented as part of the Working Group or Project Charter and;
 * Includes provisions for clearly and openly documenting Moderation actions taken.


I realize this isn't part of this PR, but re-reading this, I think we should include some verbiage along the lines of "The Moderation Policy for the Working Group does not conflict with this Moderation Policy" to this list of requirements. This would effectively make all WG moderation policies supersets of the base policy, i.e. things can be added but not removed. This should make it easier for people to both contribute and to moderate without having to worry about interpreting jurisdiction disputes.

nebrius · 2017-05-31T20:08:27Z

Moderation-Policy.md

 * *Post* refers to the content and titles of any issue, pull request, comment or wiki page.
 * *Moderate* refers to the act of modifying the content and title of, or deleting, any Post for the purpose of correcting or addressing Code of Conduct violations.
 * *Remove* refers to the act of removing the configured write (commit) permissions for an individual Collaborator's GitHub account from *all* Node.js GitHub Organization repositories as well as removing the account from the Node.js GitHub Organization membership.
-* *Ban* refers to the act of blocking an individual GitHub account from any further participation in the Node.js GitHub Organization.
+* *Ban* refers to the act of blocking an individual GitHub account from any further participation in the Node.js GitHub Organization. Bans may be *temporary* (24 hours) or *indefinite*.


Can we rephrase (24 hours) to read (e.g. 24 hours)? I suspect there may be cases where, say, a week long ban would be appropriate, and I don't want to box us in here.

Put a cap on it.

Bans may be temporary (up to 1 week) or indefinite.

Doesn't have to be "1 week", can be whatever, but setting an agreed-upon maximum will limit bike-shedding the length of a ban. And that bike-shedding would delay the implementation. And delaying implementation is bad because bans are most effective (and instill the most confidence in observers) when they are swift without being capricious.

nebrius · 2017-05-31T20:13:41Z

Moderation-Policy.md

 ### Requesting Moderation

 Anyone may request Moderation of a Post. Requesting Moderation of a Post can be accomplished in one of four ways:

 * Via the [report@nodejs.org](mailto:report@nodejs.org) email address,
-* Via private email to individual TSC members,
+* Via private email to individual Moderation Team members,
 * Via a new Post in the same thread as the Post being requested for Moderation,


Now that there will be a moderation team, perhaps we should add and mentioning @nodejs/moderation to make sure the team is aware.

nebrius · 2017-05-31T20:16:12Z

Moderation-Policy.md

 * When Moderating any Post authored by another Collaborator, the moderating Collaborator must:
  * Explain the justification for Moderating the post,
  * Identify all changes made to the Post, and
  * Identify the steps previously taken to resolve the issue.
+  * If the Moderation action included Banning an indication of whether the Ban is permanent or temporary is required, along with a note justifying the action.


grammar nit: add a comma after "If the Moderation action included Banning"

nebrius · 2017-05-31T20:17:13Z

Moderation-Policy.md


 #### Non-Collaborator Posts

 * Posts authored by non-Collaborators are always subject to immediate Moderation by any Collaborator if the content is intentionally disruptive or in violation of the [Code of Conduct][].
 * When Moderating non-Collaborator Posts, the moderating Collaborator should:
  * Explain the justification for Moderating the post, and
  * Identify all changes made to the Post.
+  * If the Moderation action included Banning an indication of whether the Ban is permanent or temporary is required, along with a note justifying the action.


grammar nit: add a comma after "If the Moderation action included Banning"

nebrius · 2017-06-01T19:17:29Z

Moderation-Policy.md


-The nodejs/moderation Repository is used to discuss the potentially sensitive details of any specific moderation issue. The repository is private but accessible to all Collaborators. The details of any issue discussed within the nodejs/moderation repository are expected to remain confidential and are not to be discussed in any public forum or social media service.
+Twice per month, the Moderation Team must provide a report of all Moderation actions taken by the Moderation Team to both the CommComm and TSC.


I would be in favor of making statistics publicly available. We could indicate that x number of posts were moderated and y number of people were banned and how long they were banned for. I don't think we should include anything more than that though.

nebrius · 2017-06-01T19:18:26Z

Moderation-Policy.md


-For any Moderation issue that does not directly involve a TSC member, the TSC may choose to delegate some or all of it's Moderation-related responsibilities to a "Moderation Working Group". All members of such a Working Group must be Collaborators and the TSC will have responsibility for selecting the membership of that Moderation Working Group.
+Moderation Team members directly involved in a Moderation issue -- as either the Requester or author of the Post in question -- are expected to recuse themselves from any decisions required to resolve the issue.


I would change "are expected to recuse themselves" to "are required to recuse themselves." I don't think that should be up for discussions or negotiation.

nebrius · 2017-06-01T19:27:42Z

Moderation-Policy.md


 ### Modifications to This Policy

-Modifications to this policy are made through normal [TSC motion and vote](https://GitHub.com/nodejs/TSC/blob/master/TSC-Charter.md#section-8-voting). Any Collaborator may submit a PR proposing changes to this policy. Those PRs must be labeled using the `tsc-agenda` label. Including a mention to `@nodejs/tsc` can be used to call the issue to TSC's attention.
+Modifications to this policy are subject to approval by both the TSC and CommComm. If there any objections to any proposed change, a simple majority vote of all CommComm and TSC members is required.


I have some thoughts on this, but I'll wait till after the TSC meeting on this one so we can discuss #270 first. This PR and that issue don't fully align, and I think we should figure out #270 first before working through the details of this section IMO.

jasnell · 2017-06-28T23:55:56Z

Quick update: I'll be returning to this week after next.

nebrius

I re-read this again, and overall I think it looks good. I do have some comments/concerns/requests though.

nebrius · 2017-06-30T18:52:16Z

Moderation-Policy.md


 ### Modifications to This Policy

-Modifications to this policy are made through normal [TSC motion and vote](https://GitHub.com/nodejs/TSC/blob/master/TSC-Charter.md#section-8-voting). Any Collaborator may submit a PR proposing changes to this policy. Those PRs must be labeled using the `tsc-agenda` label. Including a mention to `@nodejs/tsc` can be used to call the issue to TSC's attention.
+Modifications to this policy are subject to approval by both the TSC and CommComm. If there any objections to any proposed change, a simple majority vote of all CommComm and TSC members is required.


So I've been thinking about this for a while, and I'm not sure which approach I like best.

Each Community Votes Separately

I like this concept more than combining the members into a mega committee, but it has some issues I haven't been able to work around yet.

I think that the voting mechanism should be left up to each committee to decide. I would recommend that we follow the normal process for changing policies, aka consensus w/ fallback to vote. I don't think that requiring a vote is necessary in most cases and will probably add unnecessary overhead.

Each committee needs to keep track of it's own part of the discussion. This implies we would need to have an issue opened in each committee's repo to track discussion so that we don't mash votes together in the case of voting, and that we don't mash consensus between the two committees together.

This has the disadvantage of fracturing the conversation into two places. This may be acceptable, but I do see the possibility of different viewpoints not being considered because they originated in an issue for a committee half of the folks aren't members of.

Some people will be involved in the discussion twice. This is less important during consensus seeking, but raises questions during voting. Should people be allowed to effectively "vote twice"?

On the one hand, it's possible for some individuals to have more influence than others, which can be discouraging

On the other hand, if someone is involved in both groups, they're probably putting more work in and have context that folks only involved in one committee don't have, so having "two votes" may actually make sense.

Form a mega-committee from members of each committee

This simplifies all of the problems that separating by each committee has. I think the primary downside though is that each committee brings a unique perspective to moderation, and I feel that this is something we don't want to loose in the deliberation process.

nebrius · 2017-06-30T19:00:40Z

Moderation-Policy.md


-Any Collaborator found to be violating the privacy of the nodejs/moderation repository by repeatedly sharing or discussing the details of nodejs/moderation issues in any public forum or social media service risks being removed from the Node.js GitHub organization through standard TSC motion and vote.
+#### Escalation of Issues


I've been thinking about this escalation policy, and I don't think it accurately addresses issues that crop up when escalating. If we look at the reasons for escalating, I think they will almost always fall into one of two categories:

A person escalates because they themselves were moderated for bad behavior and they disagree with that decision.

A person escalates because they were the target of bad behavior that was not moderated and they want the bad behavior to be addressed.

In both cases, but especially the latter case, there is direct conflict between two or more individuals who are most likely all collaborators themselves. Given this, we need to be careful to a) make sure that the issue is dealt with appropriately while b) not fanning the flames on GitHub. As such, I think the current implementation in this PR doesn't address point b).

At the last collaborator's summit, I and a few others worked on an escalation policy. Admittedly I never got around to polishing it off and submitting a PR, but I created a gist with what we have. I recommend we start with this, as it's already been workshopped with a number of people and addresses both a) and b).

https://gist.github.com/nebrius/6f8cfad621deb6d0a302b16078e7ab18

nebrius · 2017-06-30T19:04:05Z

@nodejs/community-committee can you please take a look at this PR when you get a chance?

ghost · 2017-07-07T20:45:55Z

Moderation-Policy.md

@@ -31,34 +31,33 @@ Any alternative Moderation Policy used for a given repository must be included i

 ### Terms

-* *Collaborator* refers to any individual with configured write (commit) permissions to any Node.js GitHub organization repository *other than the Moderation Repository*. See [GitHub's access permissions documentation](https://help.github.com/articles/what-are-the-different-access-permissions/) for more information.
-* *TSC* refers to the [Node.js Technical Steering Committee](https://github.com/nodejs/node#tsc-technical-steering-committee).
+* *Collaborator* refers to any individual with configured write (commit) permissions to any Node.js GitHub organization repository *other than the Moderation Repository*. See [GitHub's access permissions documentation][] for more information.


do people that are in the github org and only have write access to the moderation repository even exist? i'm struggling to understand the relevance of that specification

Yes, some … there are at-nodejs/… teams that are not associated with write permissions to any repository, e.g. at-nodejs/async_hooks. I don’t think they are actually part of nodejs/members, but our rules around that are a bit unclear anyway :(

as long as they exist it's fine and it makes sense

ghost · 2017-07-07T20:47:20Z

Moderation-Policy.md

 ### Requesting Moderation

 Anyone may request Moderation of a Post. Requesting Moderation of a Post can be accomplished in one of four ways:

 * Via the [report@nodejs.org](mailto:report@nodejs.org) email address,
-* Via private email to individual TSC members,
+* Via private email to individual Moderation Team members,


for people outside of the loop, might it make sense to (eventually) link the moderation team member list here?

ghost · 2017-07-07T20:51:08Z

Moderation-Policy.md

+* Any Collaborator with commit rights to a given repository may Moderate Posts within that repository's issue tracker.
+* The Moderation Team serves as the final arbiter for all Moderation issues.
+* Moderation Team members may Remove or Ban an individual from the Node.js GitHub Organization.
+* For any Removal or Banning action, an issue describing the reasons for the action, and identifying the Github account being acted upon, must be posted to the Moderation Repository with an explanation provided by the Moderation Team member performing the action.


does this have to be done before or after enacting the action? it might be important to clarify, since some bans have to be done quickly in order to avoid further consequences

ghost · 2017-07-07T20:51:33Z

Moderation-Policy.md

-* Collaborators must not Moderate any Post authored by another Collaborator without first giving the author at least 24 hours (from the time of the initial request) to modify or remove the Post on their own.
-* If the author of the Post disagrees that Moderation is required, the matter can be [escalated to the TSC](#escalation-to-the-tsc) for resolution. In such cases, no Moderation action should be taken until a decision by the TSC is made.
-* In extreme circumstances involving either obvious gross violations of the Node.js [Code of Conduct][] or possible compromise of a Collaborator's GitHub account, the TSC can be consulted to waive the 24 hour grace period and dispute process.
+* Prior to Moderating any Post authored by a Collaborator, the author must be given a reasonable opportunity to modify or remote the Post on their own.


typo: remote -> remove

ghost · 2017-07-07T20:56:18Z

Moderation-Policy.md

 * Explanations of Moderation actions on Collaborator Posts must be provided in:
  * A new post within the original thread, or
  * A new issue within the private nodejs/moderation repository.
-* Any Collaborator who habitually authors Posts that must be Moderated can be Removed or Banned from further participation in the Node.js GitHub organization for an indefinite period of time. Such action can only be taken through normal TSC motion and vote (see: [Escalation to the TSC](#escalation-to-the-tsc)).
+* Any Collaborator habitually violating the Code of Conduct or this Moderation policy may be Banned temporarily or, in extreme cases, Removed and Banned permanently.


we shouldn't restrict this to "habitual" offenses imo

jasnell · 2017-08-21T23:50:44Z

@nodejs/tsc @nodejs/community-committee ... PTAL

MylesBorins

LGTM

MylesBorins · 2017-06-01T20:46:30Z

Moderation-Policy.md


-The nodejs/moderation Repository is used to discuss the potentially sensitive details of any specific moderation issue. The repository is private but accessible to all Collaborators. The details of any issue discussed within the nodejs/moderation repository are expected to remain confidential and are not to be discussed in any public forum or social media service.
+Twice per month, the Moderation Team must provide a report of all Moderation actions taken by the Moderation Team to both the CommComm and TSC.


Doing this twice a month with public reporting sounds fairly cumbersome

rachelnicole · 2017-08-22T00:07:58Z

Moderation-Policy.md

-  address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
+The Moderation Team is responsible for deciding what constitutes inappropriate


How are we going to deal with the Moderation team deeming what is and isn't appropriate in regards to the Code of Conduct?

The question is not clear.

The Moderation Team decides moderation actions. Anyone on the TSC or CommComm can dispute. A simple majority vote of both committees is required to overturn the action. Disputes may be escalated to a Mediator. The Mediator's decision is final and binding. The Foundation Executive Director names the Mediator.

👍 Thanks for the clarification

It might be important to mention that Collaborators may Moderate non-Collaborator Posts at any time, as stated below.

With that in mind it would seem a "moderation team" might only be applicable when dealing with moderation of a collaborator

mhdawson

LGTM

RichardLitt · 2017-08-22T03:03:58Z

LGTM.

MylesBorins

Some more comments in line.

TLDR; I think this needs to be revisited taking in to mind the TSC arbitration discussed in #318. I'm not 100% a moderation team is needed in that case.

I like most of the changes in language here and think we are most of the way there!

MylesBorins · 2017-08-22T06:50:32Z

Moderation-Policy.md

-  address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
+The Moderation Team is responsible for deciding what constitutes inappropriate


It might be important to mention that Collaborators may Moderate non-Collaborator Posts at any time, as stated below.

With that in mind it would seem a "moderation team" might only be applicable when dealing with moderation of a collaborator

MylesBorins · 2017-08-22T06:52:01Z

Moderation-Policy.md


-Requests for Moderation that do not appear to have been submitted in good faith with intent to address a legitimate [Code of Conduct][] violation, as determined by the TSC, may be ignored.
+Requests for Moderation that do not appear to have been submitted in good faith
+with intent to address a legitimate [Code of Conduct][] violation may be


MylesBorins · 2017-08-22T06:53:09Z

Moderation-Policy.md

+not yet familiar with the [Code of Conduct][]; or it may be that cultural
+differences exist, or that the author is unaware that certain content is
+considered inappropriate. In such cases, the author should be given an
+opportunity to correct any error that may have been made.



perhaps a note about privately contacting an individual being a valid option if you think the intent may have been good, but the result bad.

This is a good learning opportunity, and would be good to nudge people towards a kinder approach

Do you have suggested language?

MylesBorins · 2017-08-22T06:54:34Z

Moderation-Policy.md

  * Explain the justification for Moderating the post,
  * Identify all changes made to the Post, and
  * Identify the steps previously taken to resolve the issue.
+  * If the Moderation action included Banning an indication of whether the Ban
+    is permanent or temporary is required, along with a note justifying the
+    action.


a note to who?

MylesBorins · 2017-08-22T06:55:45Z

Moderation-Policy.md

+
+### Temporary Interaction Limits
+
+The Moderation Team may, at their discretion, choose to enable GitHub's


is there a way to request the moderation team to do this?

What would you suggest?

MylesBorins · 2017-08-22T06:59:50Z

Moderation-Policy.md

+issues in any public forum or social media service risks being permanently
+Removed from the Node.js GitHub organization.
+
+## Moderation Team


I'm not 100% sure we need a moderation team.

Perhaps this should be reworked to be based on the third party arbitration mentioned in #318

What specific suggestions do you have for reworking it?

jasnell · 2017-08-22T14:39:50Z

@MylesBorins ... I'm of the opinion that a Moderation Team is required in all cases, not just moderation of a collaborator.

gibfahn · 2017-08-22T11:13:03Z

Moderation-Policy.md

+Any Collaborator found to be violating the privacy of the nodejs/moderation
+repository by repeatedly sharing or discussing the details of nodejs/moderation
+issues in any public forum or social media service risks being permanently
+Removed from the Node.js GitHub organization.


Typo: R -> `r"

gibfahn · 2017-08-22T11:13:44Z

Moderation-Policy.md

+
+## Escalation of Issues
+
+Moderation issues disputes not involving a TSC, CommComm or Moderation Team


Nit: issues -> issue

jasnell · 2017-08-23T14:27:49Z

One final call for comments from @nodejs/tsc @nodejs/ctc and @nodejs/community-committee. If there are no objections or further comments I will land this by this Friday.

RichardLitt · 2017-08-23T15:43:55Z

Moderation-Policy.md

-    is permanent or temporary is required, along with a note justifying the
-    action.
+    is permanent or temporary is required, along with an issue posted to the
+    moderation repository justifying the action.


Add a link to the moderation repository?

RichardLitt · 2017-08-23T15:44:41Z

Moderation-Policy.md

+Any Collaborator may request that the Moderation Team enable the Temporary
+Interaction Limits by posting an issue to the moderation repository. If the
+Moderation Team choose not to do so, then a comment explaining why that
+decision was made should be added to the moderation repository thread.


I think this ought to be "must be added." Otherwise, it leaves a gap where the Moderation Team decides not to, and then never posts a decision to the thread. This would not look good.

RichardLitt · 2017-08-23T15:46:51Z

Moderation-Policy.md

+If you are not a member of the Node.js GitHub Organization and wish to submit a
+moderation request, please see [Requesting Moderation][]
+
+* [Applicability][]


Won't these links break?

I would suggest using doctoc to automatically make a TOC here.

No they won't. The links are indexed at the bottom of the markdown document. This change is here to make the document more readable. If you preview the doc on GitHub you'll see that the links still work correctly.

RichardLitt · 2017-08-23T15:48:36Z

I have a request: @jasnell, would it be possible to tease out the line changes from the content changes in commit 98a6a49? It is incredibly difficult to tell whether content was edited in that commit, without spending a lot of time comparing each line.

jasnell · 2017-08-23T16:00:52Z

That would be rather difficult, I'm afraid. I can see if I can provide an index to the specific substantive changes tho... gimme a couple minutes.

jasnell · 2017-08-23T16:07:42Z

Here is an index for the substantive changes:

https://github.com/nodejs/TSC/pull/276/files#diff-ba1bbe10e98d34ecb91c62040189c025R75 -- Previously, the TSC was the arbiter of what constituted grounds for moderation, this changes that so that the Moderation Team decides.
https://github.com/nodejs/TSC/pull/276/files#diff-ba1bbe10e98d34ecb91c62040189c025R84 - Currently, messages sent to report@nodejs.org are directed to the TSC. This changes it so that those are sent to the Moderation Team.
https://github.com/nodejs/TSC/pull/276/files#diff-ba1bbe10e98d34ecb91c62040189c025R207 - This makes it the responsibility of the Moderation Team to apply Temporary Interaction Limits.
https://github.com/nodejs/TSC/pull/276/files#diff-ba1bbe10e98d34ecb91c62040189c025R218 - This bit makes the definition of Temporary and Indefinite bans explicit.
https://github.com/nodejs/TSC/pull/276/files#diff-ba1bbe10e98d34ecb91c62040189c025R241 - This part establishes the new Moderation Team
https://github.com/nodejs/TSC/pull/276/files#diff-ba1bbe10e98d34ecb91c62040189c025R256 - The entire escalation of disputes portion is revised. So this whole section is substantively new
https://github.com/nodejs/TSC/pull/276/files#diff-ba1bbe10e98d34ecb91c62040189c025R277 - This bit places ownership of the Moderation policy into the hands of both the CommComm and TSC. Previously ownership was solely with the TSC.

RichardLitt · 2017-08-23T16:10:31Z

Thank you, @jasnell. That is helpful - it took me a lot of time to look through things, and I've think others have likely had the same issue.

jasnell · 2017-08-23T16:17:49Z

No worries. for these kinds of things I tend to review holistically so often I don't think about separating them out. I appreciate the reminder that not every one looks at it that way ;-)

RichardLitt · 2017-08-23T16:18:02Z

Moderation-Policy.md

+
+Moderation team members are Collaborators nominated by either the TSC or
+CommComm and must be approved by *both* committees. If there are no objections
+after 72 hours, the nomination becomes automatic. If there are objections to


I would change this to 3 business days. Some people don't work weekends.

That problematic also because some only work on weekends. The way we handle this with PRs to core is 48 hours on weekdays and 72 hours on weekends. This normalizes it to just 72 hours all the time. That has worked rather well up to this point. Perhaps we can say something like 72 hours including at least one business day.

Why not just set to one week?

I could go with that if others can to.

+1 to one week.

RichardLitt · 2017-08-23T16:18:44Z

Moderation-Policy.md

+the Moderation Team following the same process. Votes to remove moderators
+succeed only if a simple majority of both committees is in *favor* of removal.
+
+Once per month, the Moderation Team must provide a report of all Moderation


Specify when in the month. Who is tasked with writing this report? A Moderation Secretary? The Chair?

My presumption is that would be left up to Moderation Team to determine the details for. I'd prefer not to be overly prescriptive on the specific process. It could even be something that is fully automated and updated incrementally.

Works for me.

refack

Requesting 2 clarifications.
Suggested wording provided.

refack · 2017-08-24T02:41:41Z

Moderation-Policy.md

+### Collaborator Posts
+
+* Prior to Moderating any Post authored by a Collaborator, the author must be
+  given a reasonable opportunity to modify or remove the Post on their own.


"reasonable opportunity" is an unknown and subjective quantity. I would suggest 24 or 48 hours.
Also AFAICT the author really has two

edit or let someone else edit

dispute

My suggested wording:

* Prior to Moderating any Post authored by a Collaborator, the author must be given 48 hours to modify or remove the Post on their own, or escalate the matter to the Moderation Team.

The original text gave 24 hours. The feedback that led to this change suggested that in some cases, 24 hours was too much time. 48 would definitely be too much time.

refack · 2017-08-24T02:54:19Z

Moderation-Policy.md

+* *CommComm* refers to the [Node.js Community Committee][].
+* *Post* refers to the content and titles of any issue, pull request, comment
+  or wiki page.
+* *Moderate* refers to the act of modifying the content and title of, or


It is not clear to me whether self-moderation is included or excluded so I suggest either:
Moderation is when someone else edits your posts:

*Moderate* refers to the act of modifying the content and title of, or deleting, any Post made by another person for the purpose of correcting or addressing Code of Conduct violations.

Or, merely the act of being called out is considered moderation:

*Moderate* refers to the act of modifying the content and title of, or deleting any Post, or requesting the author of said post to perform these actions, for the purpose of correcting or addressing Code of Conduct violations.

For the purposes of this document it's the first.

refack · 2017-08-24T03:00:03Z

FWIW I think that delegation this responsibility to a Moderation Team, and designating a Mediator is a very good idea.
I'm hoping that my requests for clarification would be considered.

bnoordhuis · 2017-08-24T05:17:31Z

One final call for comments from @nodejs/tsc @nodejs/ctc and @nodejs/community-committee. If there are no objections or further comments I will land this by this Friday.

I don't have time to review right now. It's not a good time to make such changes either because a lot of people must be on holiday and won't have time to review either. I suggest putting it off until mid-September.

hackygolucky · 2017-08-24T16:37:06Z

@bnoordhuis per the lazy consensus governance, I believe that the process here is to give 48 hours to object. You seem to be objecting? Then it's on you to challenge, or on to a vote for majority, yes?

refack

My request for clarification was addressed.

bnoordhuis · 2017-08-24T20:57:42Z

@hackygolucky I'm on the CTC, not the TSC. You linked to the TSC Charter.

James asked for comments from the CTC yesterday. They haven't been @-mentioned before and I know some are out of office. If you want their input, give it more time. If it was a pro forma thing, then carry on.

hackygolucky · 2017-08-24T23:12:27Z

@bnoordhuis My bad! Y'all seem to cover the consensus seeking model, which also calls for a vote to majority if an objection is made. Thanks.

targos · 2017-08-28T11:22:25Z

Moderation-Policy.md

  * Explain the justification for Moderating the post,
  * Identify all changes made to the Post, and
  * Identify the steps previously taken to resolve the issue.
+  * If the Moderation action included Banning an indication of whether the Ban


Maybe add a comma after "Banning"?

targos · 2017-08-28T11:22:34Z

Moderation-Policy.md

 * When Moderating non-Collaborator Posts, the moderating Collaborator should:
  * Explain the justification for Moderating the post, and
  * Identify all changes made to the Post.
-* If an explanation of a Moderation action for a non-Collaborator Post is provided, it should be provided in:
+  * If the Moderation action included Banning an indication of whether the Ban


jasnell · 2017-08-29T03:41:14Z

Updated one final time to add a mandatory annual recertification for moderators.

Please give one final review. If there are no objections by tomorrow, I will land this. (/cc @hackygolucky )

jasnell · 2017-08-29T15:45:47Z

Proceeding with landing given the approvals and no raised objections.

Trott reviewed May 31, 2017

View reviewed changes

addaleax reviewed May 31, 2017

View reviewed changes

nebrius suggested changes Jun 1, 2017

View reviewed changes

nebrius mentioned this pull request Jun 1, 2017

Adopting Contributor Covenant as CoC #261

Closed

mhdawson added the cc-agenda label Jun 29, 2017

nebrius mentioned this pull request Jun 29, 2017

Request to move moderation responsibilities to CommComm #270

Closed

nebrius reviewed Jun 30, 2017

View reviewed changes

nebrius added the cc-review label Jun 30, 2017

nebrius mentioned this pull request Jul 5, 2017

Node.js Foundation Community Committee (CommComm) Meeting 2017-07-06 nodejs/community-committee#87

Closed

nebrius removed the cc-agenda label Jul 6, 2017

ghost reviewed Jul 7, 2017

View reviewed changes

jasnell force-pushed the moderation-policy-updates branch from dc4d4fc to f67ea29 Compare August 21, 2017 23:50

meta: update moderation policy

98a6a49

jasnell force-pushed the moderation-policy-updates branch from f67ea29 to 98a6a49 Compare August 21, 2017 23:52

MylesBorins reviewed Aug 22, 2017

View reviewed changes

jasnell mentioned this pull request Aug 22, 2017

Moderation escalation policy nodejs/community-committee#35

Closed

rachelnicole reviewed Aug 22, 2017

View reviewed changes

gr2m approved these changes Aug 22, 2017

View reviewed changes

mhdawson approved these changes Aug 22, 2017

View reviewed changes

RichardLitt approved these changes Aug 22, 2017

View reviewed changes

jasnell mentioned this pull request Aug 22, 2017

Re-merge TSC and CTC #312

Closed

MylesBorins reviewed Aug 22, 2017

View reviewed changes

gibfahn reviewed Aug 22, 2017

View reviewed changes

jasnell added 2 commits August 22, 2017 07:54

[Squash] Language Refinements

2eb2eec

[Squash] Nits

29cec5a

gibfahn mentioned this pull request Aug 22, 2017

Discussion: CoC Violations & Accountability : Node's future nodejs/community-committee#111

Closed

RichardLitt reviewed Aug 23, 2017

View reviewed changes

[Squash] Extend auto approval period to seven days

588f6aa

refack suggested changes Aug 24, 2017

View reviewed changes

refack approved these changes Aug 24, 2017

View reviewed changes

rvagg mentioned this pull request Aug 25, 2017

Requesting Rod to step down or be removed from the CTC nodejs/CTC#165

Closed

targos approved these changes Aug 28, 2017

View reviewed changes

jasnell added 2 commits August 28, 2017 10:11

[Squash] nit

479eff3

[Squash] recertification for moderations

a7b190f

gr2m approved these changes Aug 29, 2017

View reviewed changes

jasnell merged commit 09e2aa2 into nodejs:master Aug 29, 2017

jasnell mentioned this pull request Aug 29, 2017

meta: Establishing the Moderation Team #329

Closed

mrhinkle mentioned this pull request Sep 6, 2017

Node.js Board Statement on TSC Action nodejs/board#67

Closed


		The nodejs/moderation Repository is used to discuss the potentially sensitive details of any specific moderation issue. The repository is private but accessible to all Collaborators. The details of any issue discussed within the nodejs/moderation repository are expected to remain confidential and are not to be discussed in any public forum or social media service.
		Twice per month, the Moderation Team must provide a report of all Moderation actions taken by the Moderation Team to both the CommComm and TSC.


		For any Moderation issue that does not directly involve a TSC member, the TSC may choose to delegate some or all of it's Moderation-related responsibilities to a "Moderation Working Group". All members of such a Working Group must be Collaborators and the TSC will have responsibility for selecting the membership of that Moderation Working Group.
		Moderation Team members directly involved in a Moderation issue -- as either the Requester or author of the Post in question -- are expected to recuse themselves from any decisions required to resolve the issue.


		Any Collaborator found to be violating the privacy of the nodejs/moderation repository by repeatedly sharing or discussing the details of nodejs/moderation issues in any public forum or social media service risks being removed from the Node.js GitHub organization through standard TSC motion and vote.
		#### Escalation of Issues


		### Temporary Interaction Limits

		The Moderation Team may, at their discretion, choose to enable GitHub's


		## Escalation of Issues

		Moderation issues disputes not involving a TSC, CommComm or Moderation Team

meta: moderation policy updates #276

meta: moderation policy updates #276

Conversation

jasnell commented May 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasnell commented Jun 28, 2017

nebrius left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nebrius commented Jun 30, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Jul 7, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

jasnell commented Aug 21, 2017

MylesBorins left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhdawson left a comment

Choose a reason for hiding this comment

RichardLitt commented Aug 22, 2017

MylesBorins left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasnell commented Aug 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasnell commented Aug 23, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RichardLitt commented Aug 23, 2017 • edited Loading

jasnell commented Aug 23, 2017

jasnell commented Aug 23, 2017

ghost Jul 7, 2017 •

edited by ghost

Loading

RichardLitt commented Aug 23, 2017 •

edited

Loading