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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about making that report public?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That depends on what would be included, I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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*.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 commented Jun 28, 2017

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

Copy link
Contributor

@nebrius nebrius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ghost ghost Jul 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jasnell
Copy link
Member Author

jasnell commented Aug 21, 2017

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

Copy link
Member

@MylesBorins MylesBorins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is not clear.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Thanks for the clarification

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@RichardLitt
Copy link
Member

LGTM.

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

@MylesBorins MylesBorins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a note to who?


### Temporary Interaction Limits

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What specific suggestions do you have for reworking it?

@jasnell
Copy link
Member Author

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: R -> `r"


## Escalation of Issues

Moderation issues disputes not involving a TSC, CommComm or Moderation Team
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: issues -> issue

@jasnell
Copy link
Member Author

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't these links break?

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 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 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 commented Aug 23, 2017

Here is an index for the substantive changes:

@RichardLitt
Copy link
Member

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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