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: bootstrap the moderation team #15366

Closed
benjamingr opened this issue Sep 12, 2017 · 27 comments
Closed

meta: bootstrap the moderation team #15366

benjamingr opened this issue Sep 12, 2017 · 27 comments
Labels
meta Issues and PRs related to the general management of the project.

Comments

@benjamingr
Copy link
Member

@nodejs/moderation has been established in order to help enforce the moderation policy:

The Node.js Moderation Team is tasked with enforcement of this policy.

Moderation team members are Collaborators nominated by either the TSC or CommComm and must be approved by both committees with annual recertification. If there are no objections after seven days, the nomination is automatically accepted. If there are objections to a specific nomination, then a simple majority vote of each the TSC and CommComm members in favor of the nomination is required.

An annual recertification vote is required for all moderators. For an individual to continue as a moderator, a simple majority vote of each the TSC and CommComm members must vote in favor of retaining an individual moderator.

A simple majority vote of each the TSC and CommComm members is required to remove a moderator.

Once 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 post is to discuss and establish the operations of the moderation team.

I'd like to quote @jasnell about the difference between general collaborators and the moderation team:

The difference, is that general collaborators may do moderation while the moderation team is expected to.


Things to discuss:

  • Meetings (are any needed? I think a first one could be nice to meet everyone)
  • Discuss how the team will provide a report to the TSC and CommComm
  • Discuss how to make the team approachable.
  • Adding people to the team (onboarding, how to communicate the position is voluntary and how to encourage people to step up - I'd love to see more diversity in the team itself).

I would also like to suggest we hold non TSC/CommComm collaborators such as myself to the same standards and restrictions the project imposes on TSC and CommComm members and the way they interact in the project.

I would also love it if other core and community members could share their thoughts here about how the moderation team should conduct itself.

The goal of the moderation team is to help promote constructive and inclusive communication in the project and to be approachable while being objective.

@benjamingr benjamingr added the meta Issues and PRs related to the general management of the project. label Sep 12, 2017
@ryanmurakami
Copy link
Contributor

Hi @benjamingr!

I'd love a meeting to start with. Once we get a full team membership, we can figure out scheduling. I can take point on that if needed. I'm not sure if most of the members plan to be at Node.js Interactive next month, but that may be an option vs. virtual.

As for the report, it seems like we might look for an external tool to help moderation activities. Otherwise, if we could establish a standard issue/pr template, we could just build off the Github API (that might be better, on second thought).

I think making the moderation team members list public and creating some documentation on how the team works and how to contact will help make the team seem approachable.

I'm wondering if there needs to be a target number of members that we're aiming for. That might help us weigh adding new people. The more the merrier, imo.

Thanks for starting this issue!

@mhdawson
Copy link
Member

One thing that it would be good for the team to figure out sooner than later is whether the @report email alias should go to a subset of the moderation team members or all team members. Once this is agreed we can reconfigure the alias so that issues reported at the alias get sent to this team instead of the TSC members.

@othiym23
Copy link
Contributor

@mhdawson Speaking for myself, I'd be fine receiving the emails directly, but reading the Moderation guidelines, it sort of sounds like the intent was for emails to report@ to create issues that the moderation team (and other interested observers) could respond to. Is this something we want to do? And do we want to come up with a protocol (not necessarily tooling) for people to indicate that they're handling a given report?

@refack
Copy link
Contributor

refack commented Sep 12, 2017

I had a few thing I had in mind...

  1. Responsiveness (Time Zones and availability)
    Is this issue of high priority for the team? Probably in the short term being on top of thing sounds like a healthy idea.
    Optimally there should be a team member on line at any time. Since this is a best-effort voluntary endeavour I don't think any of us should make any time commitments, so IMHO the best way to get good responsiveness is to have a geographically diverse team.
  2. Communication - How will the team coordinate? GitHub/IRC/other? Public/Private?
  3. Centralize known policies - IMHO there's a little bit of fragmentation with policies.
    1. The CoC and the moderation policy at the TSC repo
    2. Any guidelines that arise from the Collaborator guide
    3. Ongoing discussion in meta: explicit exclusion for outside social media posts TSC#327 & doc: expections on leadership committees TSC#339

RE: NINA & CollabSummit; I won't be attending 😞, so I'd rather we have a virtual talk sooner
RE: report@ I'm not sure it should go to this team, but I don't have any better ideas.

@refack
Copy link
Contributor

refack commented Sep 12, 2017

I always get some more after I post:

  1. IRC - Is it our responsibility? RE: Moderation shortage community-committee#33 (comment)
  2. Mode of action - Is it this team's job to take action, or to make recommendations.
    If we are expected be able to take (specifically editing) action we'll need write access to all repos 🤷‍♂️
    Anyway we should have a decision making mechanism. I'm not sure consensus seeking is the best, as IMHO "Whenever there is any doubt, there is no doubt". That is if anyone feels something is offensive, it's offensive, so some action needs to be taken. Severity of action IMHO is the part that needs discussion.

@othiym23
Copy link
Contributor

Is it this team's job to take action, or to make recommendations.

I would strongly prefer that the moderation team be empowered to take action directly, and to work as quickly as is practicable. If the idea of this makes members of the community uncomfortable, I think the best way to address that discomfort is to ensure that the moderation policy (and other policies governing community behavior, including the CoC) are explicit and complete enough that enacting that policy is uncontroversial.

This is absolutely a position that requires trust (so I do think that members of the team require write access to all repos), and that trust will be easier to build and maintain if we're all agreed that we're executive agents, enacting policy, and leaving to other teams, like the TSC and CommComm, to define that policy.

@refack
Copy link
Contributor

refack commented Sep 12, 2017

I totally agree with @othiym23.
I've formulated those points so that their answers will be explicit.

I also think that team members should abide by a more detailed code (similar is spirit to nodejs/TSC#339)

@bnb
Copy link
Contributor

bnb commented Sep 13, 2017

@mhdawson With regard to report@, I believe it should go to the entire team at present. If people would like to opt-out, they can, but the team is currently small enough (seven members, if I counted correctly) that it shouldn't be a massive problem.

For now I believe getting the team set up quickly is important - delegating email access can and should be addressed in more detail later as the group grows, if necessary.

@mhdawson
Copy link
Member

mhdawson commented Sep 13, 2017 via email

@benjamingr
Copy link
Member Author

benjamingr commented Sep 13, 2017 via email

@ryanmurakami
Copy link
Contributor

@mhdawson ryanharrisonlewis@gmail.com for me.

@refack
Copy link
Contributor

refack commented Sep 13, 2017

The email that's in nodejs/node/README is good for me.

@othiym23
Copy link
Contributor

@mhdawson othiym23@gmail.com for me

@ryanmurakami
Copy link
Contributor

I'm going to send out a survey to get times for a quick kick-off meeting for the moderation team. Looking between 9/21 and 9/27. Any objections?
@benjamingr @othiym23 @hackygolucky @bnb @gibfahn

@ryanmurakami
Copy link
Contributor

Also, we've got some people nominated, but not self-nominated, in the establish thread. Should we include them by default?

@othiym23
Copy link
Contributor

@ryanmurakami That date range works for me!

@Trott
Copy link
Member

Trott commented Sep 14, 2017

I'm going to send out a survey to get times for a quick kick-off meeting for the moderation team. Looking between 9/21 and 9/27. Any objections?
@benjamingr @othiym23 @hackygolucky @bnb @gibfahn

That list should also include @refack.

@ryanmurakami
Copy link
Contributor

@Trott Yeah, I wasn't sure about that since there was an objection raised in regards to @refack and the running table at the top of this issue shows them being objected to. I'm fine with whatever, but it wasn't clear to me.

@refack
Copy link
Contributor

refack commented Sep 14, 2017

I'm going to send out a survey to get times for a quick kick-off meeting for the moderation team. Looking between 9/21 and 9/27. Any objections?
@benjamingr @othiym23 @hackygolucky @bnb @gibfahn
That list should also include @refack.

I think it's easy to keep track of the team by clicking on @nodejs/moderation

@benjamingr
Copy link
Member Author

I will be traveling at those dates - I'll still try to make it.

@mhdawson
Copy link
Member

@othiym23, agreed that in many cases an email to @report should end up as an issue in the moderation repo. Having said that I think its needs human review first and I think it should be the moderation team handling that.

I think the moderation team can discuss/suggest how the reports should be handled, but right now they are going to the TSC. Since moderation is not shared between TSC and CommComm, I'm thinking it should go to the moderation team as the representative for those of those groups.

@mhdawson
Copy link
Member

PR to create moderation email and redirect @report alias to moderation team: nodejs/email#62

@ryanmurakami
Copy link
Contributor

Just sent out the meeting poll to the current, self-nominated team members.
These people were nominated, but I haven't noticed a comment saying they are interested. Please reply here if you do want to be included: @ChALkeR @thefourtheye

@Trott, just noticed you self-nominated as well. It's coming on 7 days with no objections, so I'll go ahead and send over the poll.

@bnoordhuis
Copy link
Member

Looks like this ran its course? I'll close, reopen if necessary.

@benjamingr
Copy link
Member Author

I'm not sure I can attend, I might be airborne due to flight delays.

@ryanmurakami
Copy link
Contributor

@benjamingr Ah, sorry to hear it. I'll take notes. Update the agenda if there's anything specific you want us to discuss.

@ChALkeR
Copy link
Member

ChALkeR commented Feb 10, 2018

@ryanmurakami just noticed this while reviewing my notifications…

I was mostly in the burn-out state between September and January (it could be noticed from my GitHub activity), so I missed this, sorry.

I think I don't have the strength to join the moderaton team right now, i.e. I probably won't be very useful there. You can cc/email/otherwise-ping me anytime if you want me to excercise in conflict solving on case-by-case basis, though. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests

9 participants