Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta: moderation policy updates #276

Merged
merged 7 commits into from Aug 29, 2017
Merged

Conversation

@jasnell
Copy link
Member

@jasnell jasnell commented May 31, 2017

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

  1. 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.
  2. It relaxes the 24 hour rule for moderation on collaborator posts
  3. It makes changes to the moderation policy the responsibility of both the TSC and CommComm
  4. It clarifies temporary 24-hour bans vs. permanent bans
  5. It permits the Moderation Team to use GitHub's new Temporary Interaction Limits

### 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 comment has been minimized.

@Trott

Trott May 31, 2017
Member

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?)

This comment has been minimized.

@Trott

Trott May 31, 2017
Member

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

This comment has been minimized.

@jasnell

jasnell May 31, 2017
Author Member

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

This comment has been minimized.

@mhdawson

mhdawson May 31, 2017
Member

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.

This comment has been minimized.

@Trott

Trott May 31, 2017
Member

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.

This comment has been minimized.

@jasnell

jasnell May 31, 2017
Author Member

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.

This comment has been minimized.

@Trott

Trott May 31, 2017
Member

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

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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.

This comment has been minimized.

@nebrius

nebrius Jun 30, 2017
Contributor

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.

This comment has been minimized.

@gr2m

gr2m Jul 8, 2017

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?

Copy link
Member

@addaleax addaleax left a comment

I like the direction in which this is moving 👍

* *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*.

This comment has been minimized.

@addaleax

addaleax May 31, 2017
Member

Does it make sense to fix a time limit here?

* 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 comment has been minimized.

@addaleax

addaleax May 31, 2017
Member

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?

This comment has been minimized.

@jasnell

jasnell Jun 1, 2017
Author Member

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.


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.

This comment has been minimized.

@addaleax

addaleax May 31, 2017
Member

How about making that report public?

This comment has been minimized.

@jasnell

jasnell Jun 1, 2017
Author Member

That depends on what would be included, I think.

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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.

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

Doing this twice a month with public reporting sounds fairly cumbersome

@@ -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.

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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.

* *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*.

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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.

This comment has been minimized.

@Trott

Trott Jun 1, 2017
Member

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.

### 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,

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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

* 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.

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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


#### 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.

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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


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.

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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.


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.

This comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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.


### 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 comment has been minimized.

@nebrius

nebrius Jun 1, 2017
Contributor

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
Copy link
Member Author

@jasnell jasnell commented Jun 28, 2017

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

Copy link
Contributor

@nebrius nebrius left a comment

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


### 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 comment has been minimized.

@nebrius

nebrius Jun 30, 2017
Contributor

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.


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

This comment has been minimized.

@nebrius

nebrius Jun 30, 2017
Contributor

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 nebrius added the cc-review label Jun 30, 2017
@nebrius
Copy link
Contributor

@nebrius nebrius commented Jun 30, 2017

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

@@ -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.

This comment has been minimized.

@ghost

ghost Jul 7, 2017

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

This comment has been minimized.

@addaleax

addaleax Jul 7, 2017
Member

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 :(

This comment has been minimized.

@ghost

ghost Jul 7, 2017

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

### 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,

This comment has been minimized.

@ghost

ghost Jul 7, 2017

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

* 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 comment has been minimized.

@ghost

ghost Jul 7, 2017

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

* 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.

This comment has been minimized.

@ghost

ghost Jul 7, 2017

typo: remote -> remove

* 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.

This comment has been minimized.

@ghost

ghost Jul 7, 2017

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

@jasnell jasnell force-pushed the jasnell:moderation-policy-updates branch from dc4d4fc to f67ea29 Aug 21, 2017
@jasnell
Copy link
Member Author

@jasnell jasnell commented Aug 21, 2017

@jasnell jasnell force-pushed the jasnell:moderation-policy-updates branch from f67ea29 to 98a6a49 Aug 21, 2017
Copy link
Member

@MylesBorins MylesBorins left a comment

LGTM


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.

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

Doing this twice a month with public reporting sounds fairly cumbersome

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

This comment has been minimized.

@rachelnicole

rachelnicole Aug 22, 2017

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

This comment has been minimized.

@jasnell

jasnell Aug 22, 2017
Author Member

The question is not clear.

This comment has been minimized.

@jasnell

jasnell Aug 22, 2017
Author Member

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.

This comment has been minimized.

@rachelnicole

rachelnicole Aug 22, 2017

👍 Thanks for the clarification

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

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

@gr2m
gr2m approved these changes Aug 22, 2017
Copy link
Member

@mhdawson mhdawson left a comment

LGTM

@RichardLitt
Copy link
Member

@RichardLitt RichardLitt commented Aug 22, 2017

LGTM.

@jasnell jasnell mentioned this pull request Aug 22, 2017
Copy link
Member

@MylesBorins MylesBorins left a comment

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!

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

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

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


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

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

s/may/will

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.

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

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

This comment has been minimized.

@jasnell

jasnell Aug 22, 2017
Author Member

Do you have suggested language?

* 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.

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

a note to who?


### Temporary Interaction Limits

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

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

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

This comment has been minimized.

@jasnell

jasnell Aug 22, 2017
Author Member

What would you suggest?

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

## Moderation Team

This comment has been minimized.

@MylesBorins

MylesBorins Aug 22, 2017
Member

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

This comment has been minimized.

@jasnell

jasnell Aug 22, 2017
Author Member

What specific suggestions do you have for reworking it?

@jasnell
Copy link
Member Author

@jasnell jasnell commented Aug 22, 2017

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

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.

This comment has been minimized.

@gibfahn

gibfahn Aug 22, 2017
Member

Typo: R -> `r"


## Escalation of Issues

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

This comment has been minimized.

@gibfahn

gibfahn Aug 22, 2017
Member

Nit: issues -> issue

@jasnell
Copy link
Member Author

@jasnell jasnell commented Aug 23, 2017

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.

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.

This comment has been minimized.

@RichardLitt

RichardLitt Aug 23, 2017
Member

Add a link to the moderation repository?

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.

This comment has been minimized.

@RichardLitt

RichardLitt Aug 23, 2017
Member

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.

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

* [Applicability][]

This comment has been minimized.

@RichardLitt

RichardLitt Aug 23, 2017
Member

Won't these links break?

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

This comment has been minimized.

@jasnell

jasnell Aug 23, 2017
Author Member

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
Copy link
Member

@RichardLitt RichardLitt commented Aug 23, 2017

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
Copy link
Member Author

@jasnell jasnell commented Aug 23, 2017

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
Copy link
Member Author

@jasnell jasnell commented Aug 23, 2017

Here is an index for the substantive changes:

@RichardLitt
Copy link
Member

@RichardLitt RichardLitt commented Aug 23, 2017

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
Copy link
Member Author

@jasnell jasnell commented Aug 23, 2017

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 ;-)


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

This comment has been minimized.

@RichardLitt

RichardLitt Aug 23, 2017
Member

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

This comment has been minimized.

@jasnell

jasnell Aug 23, 2017
Author Member

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.

This comment has been minimized.

@RichardLitt

RichardLitt Aug 23, 2017
Member

Why not just set to one week?

This comment has been minimized.

@jasnell

jasnell Aug 23, 2017
Author Member

I could go with that if others can to.

This comment has been minimized.

@bnb

bnb Aug 23, 2017
Member

+1 to one week.

This comment has been minimized.

@jasnell

jasnell Aug 23, 2017
Author Member

Done

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

This comment has been minimized.

@RichardLitt

RichardLitt Aug 23, 2017
Member

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

This comment has been minimized.

@jasnell

jasnell Aug 23, 2017
Author Member

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.

This comment has been minimized.

@RichardLitt

RichardLitt Aug 23, 2017
Member

Works for me.

Copy link
Member

@refack refack left a comment

Requesting 2 clarifications.
Suggested wording provided.

### 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.

This comment has been minimized.

@refack

refack Aug 24, 2017
Member

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

  1. edit or let someone else edit
  2. 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.

This comment has been minimized.

@jasnell

jasnell Aug 24, 2017
Author Member

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.

* *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

This comment has been minimized.

@refack

refack Aug 24, 2017
Member

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.

This comment has been minimized.

@jasnell

jasnell Aug 24, 2017
Author Member

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

@refack
Copy link
Member

@refack refack commented Aug 24, 2017

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
Copy link
Member

@bnoordhuis bnoordhuis commented Aug 24, 2017

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
Copy link
Member

@hackygolucky hackygolucky commented Aug 24, 2017

@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
refack approved these changes Aug 24, 2017
Copy link
Member

@refack refack left a comment

My request for clarification was addressed.

@bnoordhuis
Copy link
Member

@bnoordhuis bnoordhuis commented Aug 24, 2017

@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
Copy link
Member

@hackygolucky hackygolucky commented Aug 24, 2017

@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
targos approved these changes Aug 28, 2017
* 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

This comment has been minimized.

@targos

targos Aug 28, 2017
Member

Maybe add a comma after "Banning"?

* 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

This comment has been minimized.

@targos

targos Aug 28, 2017
Member

ditto

@jasnell
Copy link
Member Author

@jasnell jasnell commented Aug 29, 2017

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 )

@gr2m
gr2m approved these changes Aug 29, 2017
@jasnell
Copy link
Member Author

@jasnell jasnell commented Aug 29, 2017

Proceeding with landing given the approvals and no raised objections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.