This looks like either a blocker or a duplicate of T90908: Goal: Binding code of conduct for all Wikimedia technical spaces with consequences for breaches. Maybe a blocker if we consider this the task for creating a committee / subteam in charge of maintaining and enforcing the CoC (which is what the Moderation team does in Rust).

Yeah, looks like a blocker to me.

I would note that even for Rust, the moderation subteam does not work the same as the other subteams. For example, "the moderation team does not have a leader" and "the moderation subteam should not include any core team members", whereas all other Rust subteams are led by a core team member.

The CoC parts about enforcement and the committee are still being drafted.

They are based on various sources (one important one being jQuery) rather than the Rust model, and the current draft has some key differences from Rust (e.g. how the committee is proposed to start and sustain its membership).

But I definitely agree we should think about this Committee/subteam in connection with the ongoing governance work.

Please, let's keep the concept of discussing at https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft and using Phabricator just for significant updates.

I have started https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Considering_the_model_of_Rust.27s_community_Moderation_team -- see you there. :)

This is https://www.mediawiki.org/wiki/Code_of_Conduct/Draft#Page:_Code_of_Conduct.2FCommittee . Let me know how I can help.

My plan was to start a discussion of that after Code of Conduct/Cases was done. Basically in order of the page draft.

Great, thanks @Mattflaschen! I might have made a tactical error by filing this, since I don't believe there is any way of changing the "Author" to not be me. It seems the best way of handling this (and ArchCom-RFCs in general) is for us to have a standard header which gives "driver" and "shepherd" fields. For this RFC, here's what I'm thinking:

• Driver: @Mattflaschen
• Shepherd: @RobLa-WMF

I think that basically just codifies the roles we're already implicitly playing. Do you concur?

One reason for this to be a "moderation" group and not "code of conduct" group is that our code of conduct should probably tie into our rules for giving +2 in Gerrit. That's the reason why TechCom involvement may make sense.

Such great steps and advances with process with RUST and Phabricator - Congratulations!

In T126605#2152027, @Mattflaschen wrote:

My understanding is that ArchCom has not decided that the Code of Conduct is within their scope.

Unless and until they decide a CoC/moderation is within scope, a moderation subteam is not within scope either. If they did decide to put the concept of a CoC/moderation in scope, we would want to re-discuss how exactly a Code of Conduct Committee/moderation subteam should relate to the ArchCom.

But as of now, I don't think this proposal (in subteam form) is actionable.

I agree 100%. We (ArchCom) can't have our cake and eat it too. We can't say that the CoC is out of scope as far as approving/endorsing it goes, but also say that setting up a subcommittee enforcing this CoC is within our purview.

The CoC already provides for a committee, which derives its authority from the CoC itself, not from ArchCom. I think it's unnecessary and counterproductive to talk about a different committee, because it'll either be an attempt to hijack the CoC committee or to create a second committee with overlapping responsibilities.

If we want to govern +2 policy in a way that doesn't overlap with the CoC committee's responsibilities (e.g. decide when to hand out +2, and when to revoke it for reasons other than "the CoC committee told us to"), that's fine, although I'm not sure if that leaves enough to justify a subcommittee.

I personally am in favor of modeling the committee concerned with ensuring a civil environment on the Rust moderation team. As I have said before, I especially like its focus on early intervention to set the tone, demonstrate and fine-tune limits, and avoid things escalating to the point where hard rules in the CoC need to be invoked.

I also think that the ArchCom should take a more active role in supporting the CoC and moderation team efforts. A civil environment is critical for the success of our technical community. The ArchCom has a guiding function for this space, is embedded in the community, and is trusted to have some degree of independence. As such, it is well positioned to guide this effort, lend it credibility, and provide some checks & balances, helping build trust in the community.

These two aspects are independent: We can have a moderation team without any support from the ArchCom, and we can also have support from the ArchCom without the moderation team being a sub-team of the ArchCom. I personally think that the ideas for *how* the moderation team itself is set up are more important than its relation to the ArchCom / core team, and I think it would be a mistake to dismiss the Rust ideas based on a wavering ArchCom.

The CoC already provides for a committee, which derives its authority from the CoC itself

Real trust and authority need to be earned through actions, and can't be purely created from thin air based on a formal document. Any document necessarily leaves a lot of room for interpretation, and how this interpretation happens will determine whether the community builds trust & lends authority to the committee or not.

In T126605#2152328, @GWicke wrote:

The CoC already provides for a committee, which derives its authority from the CoC itself

Real trust and authority need to be earned through actions, and can't be purely created from thin air based on a formal document. Any document necessarily leaves a lot of room for interpretation, and how this interpretation happens will determine whether the community builds trust & lends authority to the committee or not.

This is an idealistic view, but it tends to not work in practice; there are actual cases that arise (and some that are happening right now) that require some action, and that action needs to stem from an agreed-upon base set of rules to go by. A committee can't just go and say "you violated our code" without having a proper code.

That said, I think that we are missing the point a bit here. The discussion about how the committee is create, when, how, and what its authority is, is already set in the procedure that has already been going on through the Code of Conduct process. When it was an option that the Architecture Committee may take "ownership" over the CoC, this task was filed to explore the idea that as part of taking ownership, the CoC committee will be run under the ArchCom purview. I am personally in the view that this is not a good idea in general, but besides that, since ArchCom's decision is that the CoC is not under the scope at all, then the questions about the CoC committee should continue where they already started -- in the CoC process.

We will be discussing the more practical aspects of the CoC process soon by opening the remaining sections of "Cases" and "Committee". Instead of splitting the discussion to yet another venue, let's continue it there.

The idea of making the CoC Rust-like can be debated. The idea of making it be a subcommittee of the Architecture Committee seems to be a settled matter (of a no). Let's continue the discussion of what the committee is going to be like (Rust-like or not) in the place where the community is currently discussing the process, at the discussion page.

It seems that the intent and function of this specific task is out of date either way, though.

In T126605#2152335, @Mooeypoo wrote:

In T126605#2152328, @GWicke wrote:

The CoC already provides for a committee, which derives its authority from the CoC itself

Real trust and authority need to be earned through actions, and can't be purely created from thin air based on a formal document. Any document necessarily leaves a lot of room for interpretation, and how this interpretation happens will determine whether the community builds trust & lends authority to the committee or not.

This is an idealistic view, but it tends to not work in practice; there are actual cases that arise (and some that are happening right now) that require some action, and that action needs to stem from an agreed-upon base set of rules to go by. A committee can't just go and say "you violated our code" without having a proper code.

The idea that we'll be able to develop a "proper code" without trust is an idealistic view that assumes that humans are as easy to program as computers are. The written code and the committee need to have a symbiotic relationship of continually building trust through good process around the CoC, as well as sound interpretation and productive iteration. The committee will get its authority from that. In short, I agree with @GWicke.

The idea of making the CoC Rust-like can be debated. The idea of making it be a subcommittee of the Architecture Committee seems to be a settled matter (of a no). Let's continue the discussion of what the committee is going to be like (Rust-like or not) in the place where the community is currently discussing the process, at the discussion page.

I think the terms "subcommittee" and "subteam" may be loaded. I think the good thing out of the Rust process is that the Rust core team lends their authority about issue/pull request access out to a Moderation team, who then uses that authority to remove issue/pull request access. TechCom has some authority to lend in this area (+2 access in particular). The terminology of "subteam" suggests lower rank, so I'm fine with coming up with some other name for it.

I believe this task should be used to continue conversation on this topic:

In T126605#2152175, @Catrope wrote:

If we want to govern +2 policy in a way that doesn't overlap with the CoC committee's responsibilities (e.g. decide when to hand out +2, and when to revoke it for reasons other than "the CoC committee told us to"), that's fine, although I'm not sure if that leaves enough to justify a subcommittee.

The "the CoC committee told us to" question is basically the topic that we need to resolve. I'll attempt to modify the title and description of this task accordingly.

In T126605#2152445, @RobLa-WMF wrote:

The "the CoC committee told us to" question is basically the topic that we need to resolve. I'll attempt to modify the title and description of this task accordingly.

Bluntly, "the CoC committee told us to" isn't a question. Assuming the CoC is adopted in a form similar to what's currently being discussed, ArchCom or ModCom or whoever is in charge of revoking +2 access will be required by the CoC to revoke +2 access on the CoC committee's say-so, just like IRC admins, Phabricator admins, etc etc will be required to carry out sanctions handed down by the CoC committee. If you think there's any question / topic to resolve there, you should bring that up in the CoC discussion, since whatever CoC ends up being approved will apply to all technical spaces, including Gerrit.

In T126605#2152445, @RobLa-WMF wrote:

I think the terms "subcommittee" and "subteam" may be loaded. I think the good thing out of the Rust process is that the Rust core team lends their authority about issue/pull request access out to a Moderation team, who then uses that authority to remove issue/pull request access. TechCom has some authority to lend in this area (+2 access in particular). The terminology of "subteam" suggests lower rank, so I'm fine with coming up with some other name for it.

One problem I think is worth raising, though, is that there seems to be a bit of a collision between what we want to model after and what the "facts on the ground" are. What I mean is that on one hand, there were suggestions to model this team a bit like Rust's moderation team, which seems fine -- but Rust's moderation team (a) is a subteam of the core team (in our comparison, it is run by, or delegated by, the Architecture Committee equivalent) and (b) it is dealing with many issues about the Code of Conduct.

Since ArchCom's consensus seems to be that the CoC is not under their purview, it means that the committee that is discussed in this ticket can't really be modeled completely after Rust's moderation team.

My worry is that we're going to end up with two committees that overlap or step on each others' toes. That's why I recommended that anything that discusses specifically the Code of Conduct-related committee should be discussed in the CoC process, where it is being discussed so far. I hope this clarification makes more sense than my previous post.

I believe this task should be used to continue conversation on this topic:

In T126605#2152175, @Catrope wrote:

If we want to govern +2 policy in a way that doesn't overlap with the CoC committee's responsibilities (e.g. decide when to hand out +2, and when to revoke it for reasons other than "the CoC committee told us to"), that's fine, although I'm not sure if that leaves enough to justify a subcommittee.

The "the CoC committee told us to" question is basically the topic that we need to resolve. I'll attempt to modify the title and description of this task accordingly.

Not sure I understood what you mean here.

Are we talking about creating a committee, under ArchCom that deals with granting and taking away committer rights, like +1/+2, etc?

If so, then it is a separate entity than the Code of Conduct committee, which does completely different things, and is, for the most part, unrelated to it.
That is, people may lose their +2 rights if they are acting against the Code of Conduct in a severe enough manner, but the committee that needs to decide on how to investigate the complaints, how to handle the cases, where to proceed and how to enforce the rules is the CoC committee -- who is also going to have its members go through specific (and needed) training on how to do all these things properly. That bit should not (and cannot, practically and on principle, imho) be part of a committer 'subteam' (or whatever you end up calling it)

I think this distinction between the two committees is extremely important, especially if we are starting a discussion about committees here that is separate from the efforts that are going on in the CoC process itself.

In T126605#2152175, @Catrope wrote:

If we want to govern +2 policy in a way that doesn't overlap with the CoC committee's responsibilities (e.g. decide when to hand out +2, and when to revoke it for reasons other than "the CoC committee told us to"), that's fine, although I'm not sure if that leaves enough to justify a subcommittee.

I agree with Roan and Moriel. I think it is fine to have a Committers Committee (or whatever name is clear) for granting and revoking +2 (if ArchCom thinks that makes sense). The CoC Committee should also have the authority to temporarily or permanently revoke +2 (this was already pretty clear in the draft, but I've spelled it out a little more). The Committers Commitee should not be called the Moderation Subteam, nor should the Committers Committee and the Moderation Subteam/Code of Conduct Committee be the same team/committee.

In T126605#2152317, @GWicke wrote:

I personally am in favor of modeling the committee concerned with ensuring a civil environment on the Rust moderation team.

The Rust core team is very clear that the Code of Conduct is within their scope, and a subteam in a substantive sense. It's one of the four issues the Rust community lists as most important in their governance RFC. In practice, the core team also takes action to help improve the CoC when necessary (e.g. here).

These two aspects are independent: We can have a moderation team without any support from the ArchCom, and we can also have support from the ArchCom without the moderation team being a sub-team of the ArchCom.

I think informal support from ArchCom and its members would be great, but I don't think it should be a subteam. I think we should stick with the name "Code of Conduct Committee", and continue the current drafting process.

I personally think that the ideas for *how* the moderation team itself is set up are more important than its relation to the ArchCom / core team, and I think it would be a mistake to dismiss the Rust ideas based on a wavering ArchCom.

Rust has both similarities and differences from the MediaWiki community. I would like if we end up in a place with a strong CoC enforced informally and formally (as I think the Rust one is). As stated above, I don't think it should be a subteam at this point. Also, while I think informally attempting to get people to comply with the CoC is a good thing in certain cases, I don' t think that should be part of the CoC Committee's job. One of the key differences between Rust and MediaWiki is that the MediaWiki community is more diffuse (and I believe bigger). It doesn't seem scalable to have the CoC Committee monitoring our many mailing lists, IRC channels, and talk pages trying to resolve things. It's not a good use of their time (and that holds even if someone else comes notify them and says, "Could you come calm down #wikimedia-dev?).

In T126605#2152328, @GWicke wrote:

The CoC already provides for a committee, which derives its authority from the CoC itself

Real trust and authority need to be earned through actions, and can't be purely created from thin air based on a formal document. Any document necessarily leaves a lot of room for interpretation, and how this interpretation happens will determine whether the community builds trust & lends authority to the committee or not.

I agree it's essential the Committee does a good job in practice to earn trust. However, documents do grant authority, in every field (from organization bylaws to drivers' licenses).

(As I was drafting this, the title changed to "ArchCom: Support Code-of-Conduct committee's authority to eject CoC violators from the Wikimedia development community?". If the CoC Committee has to impose a penalty (such as a temporary or permanent ban or +2 revocation, etc., that needs to be implemented in practice, and it is a good idea to draft a clear process for that).

In T126605#2152609, @Mooeypoo wrote:

My worry is that we're going to end up with two committees that overlap or step on each others' toes. That's why I recommended that anything that discusses specifically the Code of Conduct-related committee should be discussed in the CoC process, where it is being discussed so far. I hope this clarification makes more sense than my previous post.
[...]
I think this distinction between the two committees is extremely important, especially if we are starting a discussion about committees here that is separate from the efforts that are going on in the CoC process itself.

As of my earlier edit to the description on this task, this task is no longer about whether a Rust-style moderation committee should be created, but rather, resolving the following questions of TechCom:

• What support should TechCom provide to the Code of Conduct and supporting committee?
• If the Code of Conduct committee agrees to eject someone from our community (e​.g. remove Gerrit +2 support), should TechCom support that without question, or be open to appeal from the banned party?
• Will ArchCom members be expected to discontinue backchannel Wikimedia software​ discussions with the banned party?

I hastily added it to the E152 list, but I removed in in my last comment. This task is mainly for TechCom to understand its role with respect to CoC. I particularly support @GWicke's earlier comment, which I'll quote (with light clarifications in square brackets to remove the "Moderation"/"Code of Conduct" confusion):

In T126605#2152317, @GWicke wrote:

I personally am in favor of modeling the committee concerned with ensuring a civil environment on the Rust moderation team. As I have said before, I especially like its focus on early intervention to set the tone, demonstrate and fine-tune limits, and avoid things escalating to the point where hard rules in the CoC need to be invoked.

I also think that the ArchCom should take a more active role in supporting [Code of Conduct] efforts. A civil environment is critical for the success of our technical community. The ArchCom has a guiding function for this space, is embedded in the community, and is trusted to have some degree of independence. As such, it is well positioned to guide this effort, lend it credibility, and provide some checks & balances, helping build trust in the community.

These two aspects are independent: We can have a [Code of Conduct] team without any support from the ArchCom, and we can also have support from the ArchCom without the [Code of Conduct] team being a sub-team of the ArchCom.

Thanks for writing this, @GWicke! I think this describes the very positive role that TechCom can play in supporting the Code of Conduct, both in letter and in spirit.

Regarding:

If the Code of Conduct committee agrees to eject someone from our community (e.g. remove Gerrit +2 support), should ArchCom support that without question, or be open to appeal from the banned party?

I don't think it should involve ArchCom at all. They shouldn't need to support or oppose it. It should just proceed. The draft has an appeals process. This section is not finalized, but as of the current draft, the sanction (e.g. a ban) would apply immediately, then there could be an appeal in some cases (The draft currently specifies DevRel as the appeals body) (when to allow appeals is unresolved). The appeals body could reverse the decision.

The +2 policy says that only the architecture committee (or, for emergency situations/obvious policy breach, people authorised by the foundation's board) can sign off on a +2 revocation, they have to be involved. The CoC can't change anything about that.

How many users have been banned from Wikimedia's Gerrit installation? What on earth are you all talking about? Is +2 access an actual issue?

In T126605#2152736, @MZMcBride wrote:

How many users have been banned from Wikimedia's Gerrit installation?

13 accounts are disabled out of 3237 (10 of which have wikimedia.org emails, and a remaining one is a staff member's personal address)

In T126605#2152629, @RobLa-WMF wrote:

• What support should TechCom provide to the Code of Conduct and supporting committee?

I think this is a valid question. The mood among ArchCom members so far seems to be that approving or endorsing the CoC is outside of ArchCom's scope. My position is that it would be within the scope of ArchCom to certify existing consensus on the CoC, as it would for an RfC. I don't know how many other ArchCom members agree with that; I think it's at least one, but I haven't heard from most of the committee about this.

As for whether ArchCom should endorse / emphatically support the CoC, IIRC the consensus was that ArchCom as a group should not, but that individual members should feel free to engage in the discussion around it.

As for logistical support, which your question seems to partly imply, I don't know, that's a valid question.

• If the Code of Conduct committee agrees to eject someone from our community (e​.g. remove Gerrit +2 support), should TechCom support that without question, or be open to appeal from the banned party?

IMO this isn't even a valid question. Yes, ArchCom should carry out such a sanction without question. If the CoC that ends up being approved is similar to the current draft, then ArchCom is required to help carry out sanctions since it administers a technical space. ArchCom, in its role of custodians of +2s, is not special: it is required to help carry out CoC sanctions just like any other admin of a space. There is no fundamental difference between implementing (or appealing) a +2 revocation or an IRC ban, and we shouldn't try to create one. Appeals from the banned party should be handled the same as appeals to any other CoC sanction. As Matt points out, the current draft of the CoC provides for an appeals process. Fragmenting this appeals process by space would be harmful: a multi-space sanction should be appealed as one sanction in one place, not for each space separately.

To suggest that ArchCom should somehow be special with respect to the CoC process or be above the CoC process is to significantly undermine the CoC and the community consensus process that is writing the CoC. The eventual version of the CoC, whatever it ends up looking like, will be a consensus-approved document, and ArchCom has no business overriding that IMO.

• Will ArchCom members be expected to discontinue backchannel Wikimedia software​ discussions with the banned party?

I don't think this is necessary, unless the CoC committee imposes such a sanction. The current CoC draft does not explicitly list this as a possible sanction (although its list of sanctions is not exhaustive), so I’m not sure it makes sense to plan for the case where it does choose to impose such a sanction.

In T126605#2152676, @Krenair wrote:

The +2 policy says that only the architecture committee (or, for emergency situations/obvious policy breach, people authorised by the foundation's board) can sign off on a +2 revocation, they have to be involved. The CoC can't change anything about that.

Sure it can. A consensus-approved policy can override an older policy. The +2 policy can also be amended. But regardless, the CoC requires administrators of technical spaces to implement the CoC committee’s sanctions. The administrator of the +2 space is ArchCom, so the CoC requires it to implement +2 revocation sanctions.

In T126605#2153398, @Catrope wrote:

A consensus-approved policy can override an older policy. The +2 policy can also be amended. But regardless, the CoC requires administrators of technical spaces to implement the CoC committee’s sanctions. The administrator of the +2 space is ArchCom, so the CoC requires it to implement +2 revocation sanctions.

Agreed; this stuff seems pretty cut and dry to me.

@RobLa-WMF my inclination is to close this task as "resolved" per above discussion; the "open questions" seem to be pretty solidly answered except for 'what support to give the CoC committee in setting stuff up' which feels outside the scope of this task.

I agree that it is better to resolve this task in some way, to avoid confusion.

Four weeks since proposing resolving. If no further objection I'll go ahead and resolve after a check in at tomorrow's archcom call.