Need for public repo with conversation explicitly closed to Collaborators

[MylesBorins]

In a moderation thread it was brought up that time to time there is a need for conversations to happen that are limited to collaborators, but a venue to do so that is public facing does not exist.

I'm going to once again suggest a nodejs/collaborators repo where such discussions could happen. The intent is for better transparency, but I recognize this may be missing the mark

• Is this even a good idea?
• Should it be limited to TSC + CommComm or entire Collaborator base?
• What kind of issues would be appropriate for this setting, if any?
• Does @nodejs/collaborators @nodejs/tsc or @nodejs/community-committee see value in this
• Do members of our greater community have opinions or concerns?

I plan to post this issue on twitter in the next 72 hours to collect opinions from the greater community unless someone thinks that is a bad idea.

[gibfahn]

• What kind of issues would be appropriate for this setting, if any?

Some examples of this would be really useful.

from time to time there is a need for conversations to happen that are limited to collaborators, but a venue to do so that is public facing does not exist.

Is there a reason we couldn't just have the discussion on any repo and limit it to collaborators? I guess it'd need to be one where all node collaborators (i.e. members) have read/write access, so maybe nodejs/members might be a good fit.

Would rather use an existing repo if at all possible.

[benjamingr]

I'm going to once again suggest a nodejs/collaborators repo where such discussions could happen. The intent is for better transparency, but I recognize this may be missing the mark

I'm concerned about contributors that are not yet collaborators being excluded from parts of the work on Node.js and about closing things in general.

from time to time there is a need for conversations to happen that are limited to collaborators, but a venue to do so that is public facing does not exist.

I think why the conversation is limited is an important point here. What conversation do you think needs collaborator-only access?

[MylesBorins]

Fwiw I meant collaborators in the sense of the moderation guidelines, so anyone with a commit bit on any repo in the org aside from moderation. I would imagine that good topics could include anything that is contentious enough that the collaborator group themselves need time to hash out details before including other opinions The recent thread regarding behavior in external spaces being an example of this, at least in my opinion. This will likely be true for any larger governance changes that are controversial ** I removed email cruft that was here - WK **

[gibfahn]

I would imagine that good topics could include anything that is contentious enough that the collaborator group themselves need time to hash out details before including other opinions

I guess what we're currently doing is starting open, and then locking (collaborators only) if it becomes necessary. I think I'd rather do it this way if possible.

[MylesBorins]

The challenge we have is that if we lock an issue it is limited to the team that have access to that repo An alternative proposal would be to move contentious topics to a repo that members has ownership over allowing a wider net when the issue is locked ** I removed email cruft that was here - WK **

[gibfahn]

The challenge we have is that if we lock an issue it is limited to the team that have access to that repo

Is it definitely only people with Write or Admin access to a repo that can comment if an issue is locked? I notice there's a Read access level on some repos, and it'd be great if that allowed you to comment on locked threads (but probably not the case).

An alternative proposal would be to move contentious topics to a repo that members has ownership over allowing a wider net when the issue is locked

SGTM

[jakeNiemiec]

@MylesBorins I agree with the points you make here, despite the fact that this seems to silence the comments you referenced (some of which I made , but I may be assuming the wrong thread)

From my point of view of what you are proposing:

Pros:

• Good against throw away accounts for the sole purpose of derailing
• Increase the effectiveness of moderation, ie Temp Bans (see point above)
• Encourages those who really want a say in things to cross the threshold to collaborator (sounds good for both sides, but I may be misunderstanding)

Pro or Con?

• No more Anonymous comments. Some users fear that they will be harassed for dissenting with leadership. (See detail for more comment on this)

Cons:

• Takes speech away from users who are not collaborators (myself included)
• May be perceived negatively initially (But I think this will go away as benefits are realized)

harassment for dissenting

Personally, I have only received a relatively small amount of both public and private harassing messages based on comments I have made over the past month in nodejs/*. Some of which, looking back, I deserved and have grown from. But there were enough to see where users like the below were coming from.

I feel that Leadership just needs a productive way to address comments like this:

There is zero upside for me to enter the conversation as a programmer who has used Node for 5+ years, except anonymously. (link)

---

Edited for comments below:

keep a log of moderation decisions somehow available publicly with the decisions behind it for transparency

I commented on this aspect over here, but I didn't want to add a new reply.

The public needs to be able to sympathize with the ACTION of a moderator standing up for the transgressed. Both victim and accused are out of scope and should remain anonymous. The CoC covers everything from a clear and imminent threat to life to insensitive speech. Accusing a (even anonymous) member of committing "something within that range" is not OK.

Therefore I suggested...

1. Sectionize the CoC so that you can scope the severity of the violation.
2. Be transparent about the steps you are taking to resolve the situation without sharing details. E.g: We are currently collecting information from both parties or We are currently in mediation or The matter has been resolved and the accused has been reprimanded.

[rachelnicole]

@jakeNiemiec I strongly advocate for disabling of anonymous comments. For one, those of us that are willing to visibly contribute to the project deal with harassment as it is.

I do agree with the taking speech away from users who are not collaborators, though there may be a way for us to figure out around this.

[mcollina]

@rachelnicole a very easy way would be to have an "external" team that has access, and a TSC/CommComm/Moderation group can add someone external there if they want to partecipate.

[rachelnicole]

@mcollina I agree. Or keep a log of moderation decisions somehow available publicly with the decisions behind it for transparency.

[othiym23]

According to the moderation policy:

Collaborator Posts

[…]

• 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 an issue posted to the
  moderation repository justifying the action.
• 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.
  […]

Non-Collaborator Posts

[…]

• 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.
• If an explanation of a Moderation action for a non-Collaborator Post is
  provided, it should be provided in:
• The original Post being modified (as replacement or appended content),
• A new post within the original thread, or
• A new issue within the private nodejs/moderation repository.
  […]
• In the case where a GitHub Account appears to have been created with no
  intention to collaborate in good faith, swift actions may be taken without
  following the above procedures including: removing Posts, Banning permanently,
  and reporting accounts to GitHub.

Note that Moderating non-Collaborator posts can often lead to retaliation or
escalation of inappropriate behavior by the individual whose post is being
Moderated. This is true primarily of individuals whose intent is to harass,
disrupt or annoy individual members of the community. In such cases, it is best
to handle the Moderation as quickly and as quietly as possible without drawing
any further undue attention to the Post in question.

As I read it, this provides for a permanent record of moderation actions, most of the time, and potentially in more than one place. @rachelnicole, are you suggesting that there be a single log of all moderation actions, and that we err on the side of logging actions, as opposed the last two sections of the above? (I read those paragraphs as being intended to communicate that there are situations where urgency is prioritized over comprehensiveness, and that moderation is best considered as a regulatory and executive action, rather than an opportunity to grandstand or argue about policy – which are goals I strongly agree with.)

If so, I'd tend to agree that this would be good, not just for transparency, but for accountability for moderators as well. I think it would make sense for this record to be terse (to reduce the friction of maintaining it) and purely factual (ideally, something along the lines of "excised portion of comment because it was not in compliance of $section of the CoC" or "banned user for 24 hours in accordance with $section of the Moderation Guidelines").

I think that it would be best to amend the moderation policy to be explicit about this, and also we'd need to come up with where that log should be maintained, and how it should be kept up-to-date. If nobody else wants to put together a PR, I can do it.

[rachelnicole]

@othiym23 Yup. I think there should be a single place where we log, and I agree about the terseness as well. If you wouldn't mind opening a PR, I can help review. I think you're better at summarizing things than I would be if I opened one.

[jasnell]

The updated moderation guidelines require that the moderation team provides a regular reporting of all moderation actions to the TSC and CommComm. The format and location of that report is left unspecified, as is whether that report is public or not.

[jasnell]

Also just noting that changes to the moderation policy require ok from both the tsc and commcomm. The moderation team cannot unilaterally make changes to the policy without consensus of the committees.

[benjamingr]

I think StackOverflow's idea of "moderators as janitors" is a good analogy. The moderation team should do cleanup and maintenance but not dictate policy.

[MylesBorins]

I’m pretty sure that the current discussion around the moderation team is that they do help with escalated moderation concerns, but that it is still on the collaborators to do day to day moderation. Discussing policy and coming up with suggestions seemed very much in the prevue of the new team

…

On Sep 13, 2017, at 12:08 PM, Benjamin Gruenbaum ***@***.***> wrote: I think StackOverflow's idea of "moderators as janitors" is a good analogy. The moderation team should do cleanup and maintenance but not dictate policy. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#343 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV4tOMAjtzUEDsuFMogWRdm0PLm76ks5sh6m1gaJpZM4PTAB6>.

[othiym23]

@jasnell

Also just noting that changes to the moderation policy require ok from both the tsc and commcomm. The moderation team cannot unilaterally make changes to the policy without consensus of the committees.

I see that you're "just noting" this, but was there some reason to question what I was saying based on my wording? My assumption was that any PR to the moderation policy would obviously have to be approved by at least the TSC, given that it's in the TSC repo.

@benjamingr

I think StackOverflow's idea of "moderators as janitors" is a good analogy. The moderation team should do cleanup and maintenance but not dictate policy.

As I've mentioned elsewhere, I completely agree.

@MylesBorins

Discussing policy and coming up with suggestions seemed very much in the purview of the new team.

Yes, those may be within the purview of the group, but definitely within the context of discussion and offering suggestions -- I don't want to conflate making and enacting policy at all. Having clear lines of separation, and clear separation of duties, makes life easier for everyone.

it is still on the collaborators to do day to day moderation

We may want to discuss this a bit -- one of the benefits of having a dedicated team to handle moderation is to take the heat off of the rest of the collaborators, and to keep moderation as professional and impersonal as we can.

Edited: I accidentally the whole thing

[MylesBorins]

We may want to discuss this a bit -- one of the benefits of having a dedicated team to handle moderation is to take the heat off of the rest of the collaborators

@othiym23 this is totally reasonable. My main concern is scale... moderation spans across multiple repos. I'd be concerned that if a small group of moderators were responsible for all moderation it may not scale. Perhaps we could aim towards growing the moderation team, especially if the team has required training 🎉

If the intention is to take over the load we will have to significantly modify our moderation policy 😉

Perhaps I am getting ahead of things though. I'm very excited to hear how the moderation team views their role... it seems like a great first exercise, which will in turn drive policy changes

[ktrott]

I'm having a hard time following this issue in terms of what is being proposed. A lot of the discussion seems around moderation, but the issue is about creating a separate repo that only collaborators can comment on.

To come back to @MylesBorins original questions, I think it would be extremely helpful to post some concrete examples of what issues would have been brought to this newly proposed repo (from say over the last 6mths). This would help evaluate the types of issues and discussions that this group seeks to make "read only" for the greater community, and understand the possible frequency.

I'm also not super clear on the reason for this proposal to go "read only". Is it due to:

1. Trolling concerns
2. The need for alignment with collaborators first

I thought we have moderation tools to deal with 1).

For 2) would you plan to then move the issue into an open place where the broader community can then comment, once the collaborators have aligned on something?

Having more clarity on the rationale and types of issues that would be moved, would probably help the greater community be able to weigh in on this proposal.

[jasnell]

I'm generally -1 on having yet another space where conversations are limited to only collaborators. For the TSC, we already have a private email backchannel space; for moderation issues we already have the moderation repository; we already have the nodejs/tsc repo with the ability to lock discussions to limit those only to TSC members. Adding yet another channel will not do anything that I can see to improve communication. Not have yet another channel is not what has been limiting effective discussion and decision making as much as it's been lack of a willingness to engage and use the existing channels and mechanisms that we already have at our disposal.

@MylesBorins said:

I would imagine that good topics could include anything that is contentious enough that the collaborator group themselves need time to hash out details before including other opinions

Proactively locking threads but encouraging collaborators to continue discussing would be a good way to accomplish this. Or, perhaps, using the other mechanisms already at our disposal such as email, private IRC chats, etc.

@othiym23 said:

I see that you're "just noting" this, but was there some reason to question what I was saying based on my wording? My assumption was that any PR to the moderation policy would obviously have to be approved by at least the TSC, given that it's in the TSC repo.

I was not questioning anything that you were saying. I've learned through hard experience not to rely on assumptions of what may or may not be obvious to others. My intent is only to make sure folks know what the policy requires.

[MylesBorins]

Closing for now, can be revisited