Inclusivity WG as default moderation team

[ashleygwilliams]

hello! as a result of this issue in nodejs/moderation: https://github.com/nodejs/moderation/issues/25

it has been suggested that our working group be a fall back for moderating "out-of-control" issues on nodejs repos.

@jasnell outlines a good workflow here: https://github.com/nodejs/moderation/issues/25

i am writing a straw proposal that will detail the process. PR incoming.

[nebrius]

+1, I like the idea.

For the record, the moderation repo is a private repo. All Node.js collaborators should have access though.

[varjmes]

Is it possible to get an ~idea~ of the workflow suggested? I in no way want anyone want to share the private communications of others, but I'd love to offer input but am not part of the Node.js organisation.

No problems if not, thanks!

[juliepagano]

Is the idea here that our team would help do active moderation on other node projects' issues or that we'd provide some suggestions and feedback behind the scenes when projects need help?

[jasnell]

The idea is that if a thread begins to become too heated, a call for a moderator would be posted to the moderation repo. The role of that moderator is to steer the conversation into one or more concrete documented proposals that can be evaluated objectively. It's more of a guided discussion than moderation, perhaps, to avoid people shouting past one another. Ideally, any of the collaborators could step up and volunteer for the role, but if one doesn't, the inclusivity WG would be the fallback -- and would be the backstop should the moderator who does step up need help. And if necessary, the CTC would serve as the final decision maker between the documented proposals. On Jan 16, 2016 2:11 PM, "Julie Pagano" notifications@github.com wrote:

Is the idea here that our team would help do active moderation on other node projects' issues or that we'd provide some suggestions and feedback behind the scenes when projects need help?

— Reply to this email directly or view it on GitHub https://github.com/nodejs/inclusivity/issues/79#issuecomment-172261997.

[juliepagano]

@ashleygwilliams is this similar/related to https://github.com/nodejs/inclusivity/issues/66? If you ping me when you have your strawproposal ready, I'll take a look.

[mikeal]

For the record, the moderation repo is a private repo. All Node.js collaborators should have access though.

It's private but every member of the nodejs org has access, which is over 400 people. I'd call it "semi-public" because so many people have access but it just isn't visible by the general public or new people that show up, including trolls ;)

[jasnell]

... And the moderation policy requires that collaborators keep it confidential... On Jan 16, 2016 2:45 PM, "Mikeal Rogers" notifications@github.com wrote:

For the record, the moderation repo is a private repo. All Node.js collaborators should have access though.

It's private but every member of the nodejs org has access, which is over 400 people. I'd call it "semi-public" because so many people have access but it just isn't visible by the general public or new people that show up, including trolls ;)

— Reply to this email directly or view it on GitHub https://github.com/nodejs/inclusivity/issues/79#issuecomment-172266108.

[Trott]

Is it worth considering a term like facilitation in addition to (or perhaps instead of) moderation? I like the friendlier, assume-everyone-is-acting-in-good-faith vibe of facilitation but at the same time, there's obviously a need for moderation (that is, something with enforcement powers) when there are malicious participants.

I don't think we're being approached about moderation (at least not yet) even if that's the term being used. The conversations where this has come up seem to involve something closer to facilitation.

If someone's posting maliciously, there are a few TSC members who are pretty good about removing those posts. Those are the easy cases. The hard stuff is how to handle "real" conversations that get too heated but that are about topics that need to be discussed. And the unwelcome stuff is in the same comments as the valid stuff that you don't want to silence. I think that's the hard stuff and where help is most valuable/needed at this time.

[KarbonDallas]

I would like to voice my support for a focus on approaching conflict resolution wherever possible from the perspective of a 'facilitator'. This is something I've been trying to do more of personally in IRC through private messages with those in question, and it has generally seemed to have a positive impact on how often 'moderation' is necessary (as in decreasing the frequency of kicks and bans).

With that said, obviously swift moderation is still necessary when applicable. My anecdotal data suggests that looking toward 'facilitation' may make it easier to discern the difference between a bad actor (troll, abuser, etc.) and someone who just screwed up but is having trouble admitting it in the face of what might be perceived as hostility or undue scrutiny.

tl;dr — :smile_cat: :+1:

[nebrius]

I'm going to try and summarize the current ideas and recommendations so far. Please let me know if there's anything missing/misinterpreted/etc!

Based on the discussions, I feel like there are a two components being proposed: the process of moderating, and selection/training of moderators, so I'm going to refer to them as separate proposals for now.

First, the process of moderation:

• When a thread is shown to be getting heated, a single impartial moderator is selected from the list
  • This individual would be someone who is not close to the discussion
• The selected moderator will be the only person to moderate the thread, from a technical perspective (i.e. giving warnings, editing posts, etc).
  • This should ensure that exactly one person moderates the thread, i.e. preventing posts from slipping through that should be moderated, but also preventing pile-on from multiple people trying to moderate
• Somewhat unrelated, it is advisable for collaborators who are close to the topic to form ad hoc team(s) of some sort to coordinate responses to focus technical responses and to prevent pile-on. This idea is still very vague, but could be very valuable IMO.
• This WG is tasked with spear-heading the creation of the process

Second, the selection/training of moderators

• Someone (this WG, the TSC, etc) will be tasked with maintaining a list of moderators who have volunteered to act as moderator in the case they are needed (process of moderation program)
• This WG would be tasked with creating a training program for people who wish to become a moderator

Does that sound right?

EDIT: s/moderation/facilitation as appropriate

[ghost]

so, the concept of a working group for moderation has just been brought up in nodejs/TSC#45 again. @TheAlphaNerd and myself have proposed a mix of TSC, inclusivity WG and outside members.

@nebrius added that a WG might not be the optimal structure for such an endeavour, and suggested an independent group (i think) or a conglomeration.

[nebrius]

Expanding on what @sup said, I think that it's worth having a discussion on what the optimal organization is for this moderation thing. It very well could be a working group, but it may not at the same time, and I'd like to discuss pros and cons first. My (not very well thought) concern is that working groups are traditionally scoped to oversee themselves and make recommendations to the rest of the org, and this WG wouldn't follow that. This isn't necessarily a bad thing, but worth considering.

[nebrius]

A very interesting question came up in regards to express in the moderation repo. I won't be discussing details because that repo is private, but the question of scope came up again. So here's the question:

The moderation policy for the project is currently maintained by the TSC. Given that this is the TSC's moderation policy, it follows that the scope of the moderation policy is everything that the TSC has authority over. The thing is, the TSC has authority over everything in the foundation, which includes express now. So, technically speaking, the TSC has moderation power over express, at least in theory.

However, TSC members don't technically have permission to moderate because of org permissions. On top of it, I'm not sure if we actually want the TSC to have moderation ability, and thus the responsibility, of moderating express.

I think that this should be considered when working on the moderation process.

[mikeal]

The way our policies now work is that moderation falls under the same "copy on write" practice as other processes. Which means that projects in the foundation fall under the TSC policy unless they choose to take on responsibility for their project's moderation outside the base TSC policies. A project or working group has the autonomy to take on this responsibility themselves if they choose to, but if they don't it falls back to the TSC.

In terms of access, a few people on the TSC have access to every org. If moderation needs were to increase in an org the project would add more people from moderation in order to handle the load.

[nebrius]

Thanks for the clarification! This will help when creating "run books" for moderation, which is how I'm kinda viewing this task.

[nebrius]

I filed #132 with more concrete steps/proposals to get the ball moving forward with this thread. I think we should close this one now in favor of that one, but what does everyone else think?

[nebrius]

I'm closing this in favor of #132, feel free to re-open if there are separate concerns here.