This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Inclusivity WG as default moderation team #79
Description
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.
Activity
nebrius commentedon Jan 15, 2016
+1, I like the idea.
For the record, the moderation repo is a private repo. All Node.js collaborators should have access though.
varjmes commentedon Jan 16, 2016
Is it possible to get an
ideaof 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 commentedon Jan 16, 2016
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 commentedon Jan 16, 2016
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:
juliepagano commentedon Jan 16, 2016
@ashleygwilliams is this similar/related to #66? If you ping me when you have your strawproposal ready, I'll take a look.
mikeal commentedon Jan 16, 2016
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 commentedon Jan 16, 2016
... And the moderation policy requires that collaborators keep it
confidential...
On Jan 16, 2016 2:45 PM, "Mikeal Rogers" notifications@github.com wrote:
Trott commentedon Jan 22, 2016
Is it worth considering a term like
facilitationin addition to (or perhaps instead of)moderation? I like the friendlier, assume-everyone-is-acting-in-good-faith vibe offacilitationbut at the same time, there's obviously a need formoderation(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.
affinity-matrix commentedon Jan 22, 2016
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 — 😸 👍
nebrius commentedon Jan 22, 2016
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:
Second, the selection/training of moderators
Does that sound right?
EDIT: s/moderation/facilitation as appropriate
nebrius commentedon Feb 7, 2016
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 commentedon Feb 28, 2016
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 commentedon Feb 28, 2016
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
moderationin order to handle the load.nebrius commentedon Feb 28, 2016
Thanks for the clarification! This will help when creating "run books" for moderation, which is how I'm kinda viewing this task.
nebrius commentedon Apr 27, 2016
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 commentedon Jun 7, 2016
I'm closing this in favor of #132, feel free to re-open if there are separate concerns here.