-
Notifications
You must be signed in to change notification settings - Fork 134
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
Comments
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. |
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. |
Would that induce adding more people as the org owners and/or giving more people access to the private repos? If yes — how many? |
@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. |
Was there a result from the meeting on this? I was only able to attend part of it because I had meeting conflicts. |
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. |
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.
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.
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. |
Good point.
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. |
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:
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. |
After discussion in the latest TSC meeting, we've decided to consolidate this discussion in #276 and hash out the details there. |
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.
The text was updated successfully, but these errors were encountered: