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

Request to move moderation responsibilities to CommComm #270

Closed
nebrius opened this issue May 18, 2017 · 12 comments
Closed

Request to move moderation responsibilities to CommComm #270

nebrius opened this issue May 18, 2017 · 12 comments

Comments

@nebrius
Copy link
Contributor

nebrius commented May 18, 2017

As per the discussion in #263, I propose that the TSC transfer moderation responsibilities to CommComm. By moving moderation to CommComm, along with creating an admin team, this frees up the TSC to focus on more technical matters, and hopefully we'll get more engagement in the TSC as a result.

Moderation responsibilities are specified in the TSC charter, so changing this will mean a charter change and board approval. CommComm's charter will also need to be amended.

To be clear, I am not proposing we change anything about how moderation works. The only difference will be who "owns" moderation. Currently, the TSC is not actively involved in moderation and this ownership is mostly on paper. The only ways the TSC has been involved is in approving changes to the CoC and moderation guidelines, which are rare, and this would continue to be the case with CommComm for the foreseeable future.

This move is really an administrative change as part of the larger effort to refocus the TSC on more technical issues, and possibly to remerge the TSC and CTC.

@mikeal
Copy link
Contributor

mikeal commented May 18, 2017

I'm a little confused because these requests were added concurrently. Is this dependent on your request to create an admin team, or is it actually a parallel request that doesn't depend at all on the admin group?

@nebrius
Copy link
Contributor Author

nebrius commented May 18, 2017

I'm a little confused because these requests were added concurrently. Is this dependent on your request to create an admin team, or is it actually a parallel request that doesn't depend at all on the admin group?

A parallel request that doesn't depend on the admin team.

@mikeal
Copy link
Contributor

mikeal commented May 18, 2017

Ok, one concern which we've heard in the past is that the majority of issues sent to moderation are in project threads. Why should project thread moderation be put into a group outside of the project's governance?

@nebrius
Copy link
Contributor Author

nebrius commented May 18, 2017

Ok, one concern which we've heard in the past is that the majority of issues sent to moderation are in project threads. Why should project thread moderation be put into a group outside of the project's governance?

It won't, moderation will still be done using the moderation repo as it exists today. This proposal is a change in ownership, not process.

@ChALkeR
Copy link
Member

ChALkeR commented May 23, 2017

Would that induce adding more people as the org owners and/or giving more people access to the private repos? If yes — how many?

@nebrius
Copy link
Contributor Author

nebrius commented May 23, 2017

@ChALkeR currently this would not involve adding more org owners because the moderation process will not change, nor will the people doing the moderating.

Down the road I think this is something we'll need to address though. I personally don't want to add people as owners just so they can moderate the org because ownership grants too many permissions IMO. This is a problem with GitHub though, so we'll need to investigate getting GitHub to add finer grained permissions, or we can update the GitHub bot so that it can do the moderating on behalf of a human moderator.

@hackygolucky
Copy link
Contributor

Was there a result from the meeting on this? I was only able to attend part of it because I had meeting conflicts.

@mikeal
Copy link
Contributor

mikeal commented Jun 8, 2017

My recollection from the TSC meeting was that there was a lot of resistance and confusion.

It didn't seem clear what "moving moderation" actually meant. Given that the majority of issues are still project related, the participants are mainly project members, and the access controls necessary for moderation have yet to be delegated from the TSC, what would be "moved."

I think I suggested that what would really be moved would be the final escalation mechanism, but discussion of that couldn't really move forward until a clearer proposal was in place.

Also, while so many other threads are up in the air about delegating administration and other re-org options it's hard to place this in the proper context given everything that is in flux.

@nebrius
Copy link
Contributor Author

nebrius commented Jun 8, 2017

It didn't seem clear what "moving moderation" actually meant. Given that the majority of issues are still project related, the participants are mainly project members, and the access controls necessary for moderation have yet to be delegated from the TSC, what would be "moved."

To attempt to clarify again, what I'm suggesting we move is ownership of moderation. Nothing would change aside from who has "moderation" listed in their charter, where the moderation documents will live, and who is responsible for overseeing the PR process for changes to the moderation process.

I think I suggested that what would really be moved would be the final escalation mechanism, but discussion of that couldn't really move forward until a clearer proposal was in place.

We currently do not have a real escalation in place yet in any true sense of the word, so there's nothing there to be moved. We do need to create an escalation policy though, and moving moderation responsibilities to CommComm will allow us to get that implemented much faster since members of CommComm have more experience with these things and is willing to put in the time to craft such a policy, neither of which is true of the TSC.

Also, while so many other threads are up in the air about delegating administration and other re-org options it's hard to place this in the proper context given everything that is in flux.

One of my key motivations for doing this change now is to make the other re-org work a lot easier, as this (and the admin work) has been a point of contention in these discussions. Removing these from the equation should make the other re-org work a lot easier to reason about and implement.

@mikeal
Copy link
Contributor

mikeal commented Jun 8, 2017

We currently do not have a real escalation in place yet in any true sense of the word, so there's nothing there to be moved. We do need to create an escalation policy though

Good point.

One of my key motivations for doing this change now is to make the other re-org work a lot easier, as this (and the admin work) has been a point of contention in these discussions.

I think that's a good strategy except for the delegation of admin privileges. That can probably be done in isolation, and in a way that places people from CommComm and the TSC in the group with those privileges, but there appears to be a natural dependency on that happening for this to work.

@hackygolucky
Copy link
Contributor

hackygolucky commented Jun 8, 2017

Let's talk about scope. I think this conversation has gone a little sideways in terms of what the intention of 'moving' this is. Moving it gives the false appearance that all of the folks who are already contributing get booted. That would be a huge mistake! If you're thinking about a venn diagram of who is represented when we talk about voice, CommComm covers both TSC and non-TSC members(and TSC members attend our meetings). We need to expand what Moderation currently covers. It doesn't cover:

  • CommComm or anything under CommComm(the autonomy of the charter carved that out)
  • The Node.js Slack(they have expressed interest in official buy-in)
  • Freenode #Node.js

We should be building up everyone who is participating in these spaces. That is in -every- single repo. There is no intention of closing this off, and I think that's what the word 'moving' gives off. It is expanding scope. Is some joint ownership, instead, a more understandable way to move forward? If so, solving the issue around how folks access Moderation when activation is required is the focus, right? Currently, I don't think participants from CommComm or the amazing IRC moderators are necessarily given access to the Moderation repo.

@nebrius
Copy link
Contributor Author

nebrius commented Jun 29, 2017

After discussion in the latest TSC meeting, we've decided to consolidate this discussion in #276 and hash out the details there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants