User talk:Barkeep49/UCoC Enforcement

Strongly support this

I strongly support this entire idea. Thanks for bringing this forward to the discussion. Best, KevinL (aka L235 · t · c) 23:45, 15 May 2021 (UTC)

Assorted Feedback

Hi @Barkeep49:, generally a strong proposal, but a few points, so so I'll run through the sections:

Enforcement The options seem good, but perhaps a few more expected criteria (easier to include them at the start, than realise some things aren't obvious). That's especially the case for administrator panels - admins making up these panels would need to sign an NDA, because they'd be handling private evidence, even if it's not WMF-sourced private evidence. For "professional decision-makers", will they be working off "UCOC" or "UCOC + any rules the local community does have?"

Also, The membership of this committee will be designed following ratification - nope. I am never going to support such a key body as part of the UCOC if its structure is not clear in advance. Why are even 1/3 of members being appointed?

Reporting - currently there are already concerns about a literal deluge of cases that would come from making it so easy, as it's likely to lead to individuals clicking it for huge numbers of regular content-violation cases. That's a concern as distinct from this - the benefits are obvious, but the issues really need considering. I suspect it'll be en-wiki and the smallest wikis that get most hit, but I could be wrong.

Training - sure

U4C jurisdiction - I would actually suggest saying that it has jurisdiction over all projects that opt in, plus, after a 3 month period, any project that doesn't specifically opt-out (they can continue to opt-out later, but it helps with very low activity wikis not realising they could). This is generally well-written, but I have concerns with one area and there are two others that should be added.

I have to question whether any group, even one fully elected from the broader community could be accepted to have a mandate to state a project is systemically failing (edges cases of a community asking the U4C to review its own arbcom etc aside). I think such decisions can only reasonably be made by the meta-community. To take the hr-wiki issues as an example, the Community actually was fine at bringing evidence and discussing and coming to a consensus of issues. Where it fell down was anyone actually willing to both close/assess consensus and then to execute the actual decisions. It is here that the U4C could shine. If it felt there was a case to answer (it could do that by saying X, Y, and Z must be met for a claim of systemic failure to be raised, and having one person do that). An RfC could then be raised on meta, and the community discuss for 30 days. The U4C would then close and it would be responsible (if there was systemic failure found by the community) to resolve it as it saw fit. That would give a mandate, but allow the more nuanced bit (actually solving it) to be handled by a more agile body.

I would also suggest adding that in the event of this occurring, the U4C would have jurisdiction (including delegatable jurisdiction) to review cases that this Community may have misjudged on (both poor blocks and poor non-blocks).

Finally, the WMF and its employees/contractors are bound by the UCOC. While communities can sanction contractor accounts, they are reticent to do so. I'm aware of two incidents where they were considered and basically admins chose not to act purely because of their contractor status - full unblockables. This means the WMF is the group most actually likely to handle cases in this vein in the form of internal action. But they may miss such. I would propose that the U4C have jurisdiction (not sole jurisdiction, but as a possible channel) over reviewing misconduct by staff accounts and the volunteer accounts twinned with them (that is, any account of a current employee/contractor).

Ratification - I strongly disagree with the "2 out of 3" approval. I propose two options at this page, and you heard me run through it today (the second option has been slightly tweaked to factor in some discussion from it). But for others, it basically is "a majority of BOTH local projects and editors (and possibly affiliates) must ratify, by article", as well as the WMF Board. Given the numbers in affiliates, the only way to avoid both tyranny of democracy AND a majority of individuals being overruled by a few, is to require all 2 (or 3), not a "2 out of 3" option.

Amending As above, most likely Nosebagbear (talk) 23:48, 29 May 2021 (UTC)

@Nosebagbear thanks for this detailed feedback. I appreciate you taking the time to go through this with such depth and attention. Responding to what you wrote, for reporting I am envisioning some sort of reporting wizard. Putting a button on every page will increase reports so the question, for me, is will it increase reports beyond what the places they're being funneled can handle? Since I think people will largely end up at ANI (as I presume that's where UCoC enforcement would go for onwiki help) and ArbCom I think the answer is no. I think those two venues could handle the number of reports generated by a button.

Why is it possible for up to 1/3 to be appointed? Because a number of communities don't trust elections broadly or actually prefer professionals not volunteers handling things. I feel like when I show up to larger conversations I tend to be on the extreme "trust in elections" side of things and I know you feel at least as strongly if not more and so I am trying to respect that while having a bedrock of democratic accountability. It is about having something that people can live with.

This ability to live with things is also why I am strongly opposed to section by section ratification. Some things only work when taken as a whole. For instance, I think the project enforcement (revised section heading since you left the comment) and jurisdiction work hand-in-hand and would be reluctant to approve one without the other. I do think the method you've proposed on Meta is clever though I would tweak it to replace the board with affiliates. Ultimately because there are resourcing commitments I think if the board's not onboard it doesn't matter if projects, editors, and affiliates are so they would need to approve it to be sent to the projects and affiliates for approval. However, your general concept is well done in terms of balancing small projects vs large projects needs for voices and affiliates could easily slot in as a third group that could also contribute to the editor count (though maybe not since it would double count a lot of people since ideally someone is involved in affiliate and project work).

As for jurisdiction itself, for me someone to review systemic failing is a must do for UCoC enforcement. You write that the global community handled Croatian Wiki. I disagree strongly that hr wiki was handled by the meta community. First because this problem went on for years before Meta consensus finally coalesced that there was a problem and it wasn't for some lack of trying on hrwiki editors parts. Meta wasn't interested for a lot of that time and so editors had nowhere to turn. And then even once there was a problem, there was no one who felt empowered (or who desired) to enforce that consensus. To me whatever enforcement mechanism we come up with would need to be able to handle hrwiki situations (and hrwiki is not the only wiki which has these problems by any stretch of the imagination) and also be able to handle FRAM situations better than the foundation did. Like that's a non-negotiable for me. But that's a really hard balance to strike. This is my best attempt to do it but there perhaps could be refinements made. I don't quite understand your employee paragraph so I don't have a response to that.

Thanks again for the feedback and the points you raise. Best, Barkeep49 (talk) 16:20, 1 June 2021 (UTC)

@Barkeep49: thanks for the response. I'll attempt to cover a few things:

The WMF employees/contractors (I'm just going to call them contractors, take it to include all the US-based staff, too) section, first. While obviously it is rare for appreciable misconduct by contractors (whether on their staff or volunteer accounts), I am aware of a few cases. In two of those cases, admins would have normally have sanctioned them, but decided not to because they were staff members. That's clearly not ideal - my proposal was that the U4C would have non-exclusive jurisdiction over accounts of contractors and could be asked to handle issues with them. Communities could still act normally, as well as the WMF handling it internally, but it would be a channel for when those were not suitable/ideal.

Board ratification While, yes, if the Board were against it then it would likely fail, given that the UCOC is binding on the WMF, it's good for them to have a ratification proposal as well. It also would discourage, though not stop, reticence from the Board to support in the future if they formally backed it now. It would, however, perhaps indeed make sense for them to ratify it *first*.

Affiliate ratification I would certainly be against Affiliate votes also counting in the editor-count bit, since that would indeed be double voting (or, depending on how you interpret it, triple-voting vs double-voting). One of the issues I have is that those who are affiliate members are in effective getting additional weight even if it's just a fully distinct category, with individuals having to join affiliates to apply their maximum weight. On the far side of that is I could join dozens (likely not all, but a large number) and game influence on the ratification process that way. Unless you think there is a way to prevent individuals from voting in more than one affiliate? I'm not sure how we could monitor that.

Appointed members I take on board your point about appointed members - is it really as high as 1/3 of editors have major concerns about elections/would prefer professional members? And would that appointed group be appointed members of the communities or external professionals? While not all the procedure can be decided in advance, an organisation like the U4C shouldn't be deciding how its own membership so it would be good to know that in advance.

As a whole vs by-article In regards to by-article ratification, certainly to avoid issues with "I only agreed because of X", you'd need the setup in my proposal which is that if any article failed, then you'd need a 2nd "vote for everything remaining" step. The burden is higher than "something people can live with" - it's got to be higher than "what the current set-up is" as well. For some projects, the first is the higher burden, but on en-wiki and a number of other projects, it's the latter. Your view is, I think (let me know if wrong) you think that it's better to vote on it as a single block so people's unhappiness with some bits is covered by their general satisfaction with most areas. I would argue that that is rather like riders on laws - the base positive is so high that it's unpopular to stop it to let the negatives through, but it's still better to stop those negatives. I also feel there is the opposite risk - people argue/vote against the whole thing because it's the only way to stop a certain major concern.

Systematic review so certainly a formal process is needed now, vs the completely ad-hoc methodology in place. And I think you're right that to get the ball rolling would be good to use the U4C in that way. Someone raises to them, it (or a member) reviews and presents the case. But I do stand against any devolved body sanctioning whole communities. So have the meta-community do a discussion and an up/down case (akin to the actual misconduct Finding of Facts). The U4C would then determine the action to be taken and enforce that consensus. That would both smoothline the current "method" (shambles) and, critically, give it some teeth. It's not me saying the current system works on systematic project misconduct. Clearly it doesn't. It's me saying that making the cure one step better than the poison is also not viable.

Finally, you mentioned FRAM-situations - afaict, a FRAM-sitation wouldn't fall under any of the jurisdictional boundaries you've currently set - would be interested on hearing more on that.

Thanks again for the detailed response and for time spent reading yet another detailed one from me. And a few of your points have caused some rethink on my side, such as non-elected members and reducing the Community's remit in how I'd like systematic review done. Nosebagbear (talk) 16:48, 1 June 2021 (UTC)

Foundation people: ahh that makes more sense now, thanks. That's not something I've given much thought to but your initial comment makes sense to me.

Ratification: board ratification has always been on the table so I'm comfortable with that being its own discrete step. Community ratification is a must do for me which is why it is was in the ArbCom open letter on the UCoC. I think you and I agree on its importance even if you'd like to see more granular ratification than I would.

I think joining a project and voting in their RfC would be easier than joining affiliates, some of which carry membership dues or other forms, but yes I'd be fine with the editor count only coming from projects even while thinking Affiliates need to be its own group of approval.

1/3 maximum for appointed seemed like a fair number but I could be convinced to change it without too much trouble.

As for ratification, riders are 100% the wrong analogy in my view. This is closer to a constitution than a law - to carry out this metaphor the procedures/defaults the U4C pass out would be laws. Either people/projects can live with the mechanism as a whole or they can't. If they can't we would need to rethink. If they can then there needs to be a way for it to be amended. Honestly this is why I ducked the membership question. This, fairly, could be a dealbreaker for many and so I think having alignment on what the body is and would do could lead to a more productive membership discussion which would then get its own approval.

As for systemic review, I think we think different things which is of course fine. Some of what has lead me to this thinking is covered under privacy agreements so I can't reference them here which makes it hard to have a discussion. One piece of my background knowledge, the preview of the report I've seen on Croatian wiki, is on track to be published soon which will be of some help in leveling our knowledge. The reason I mention FRAM is because many people speculated that a systemic failure to enforce civility and harassment policies, which are covered under UCoC, was behind the foundation's overstep. Do I think a UCoC enforcement body could have caused less of an uproar than the foundation for the same action? Maybe but maybe not. However, I do hope that it would have reached a different outcome so it wouldn't have been a like for like situation. Best, Barkeep49 (talk) 18:08, 1 June 2021 (UTC)

One, amongst several, of the WMF's issues in that case was that they claimed (i think in the 1st or 2nd followup) systematic failure without a) proving it b) explaining why they didn't make that known i) before it was systematic ii) when it was, with the first notice instead being the ban. Obviously that's somewhat preaching to the choir, but would at least be avoided by the set-up here.

So I actually mentioned in my original draft some form of local eligibility to at least make project-hopping less viable. Given that the chat seemed to agree that Steward-elector eligibility should be the cross-project criteria, EC could be the criteria for participating in a local community's ratification RfC. That's not something I've put any significant thought in, but should be at least considered.

If it's being a constitutional equivalent then by-article is not inherently flawed. The bulk of actual critical bits in the US constitution actually came in through the bill of rights amendments, not all of which passed. But I believe that while this is akin to a constitution, my rider analogy (subject to all analogy limitations) retains value - individuals keen on a UCOC but, say, unhappy with how systematic cases will be handled, will have to either disregard their general support or put up with what may be a major negative. In a regular RfC admins can handle some degree of nuance, but here, ratification will be a straight up/down, with amendment being a tough process. Nosebagbear (talk) 18:34, 1 June 2021 (UTC)

More feedback

EDIT: deleted my garbage, see https://meta.wikimedia.org/wiki/User:Taylor_49#Shared_ArbCom:s where it is more appropriate

Taylor 49 (talk) 01:50, 6 June 2021 (UTC)

• In an event like this, how is going to work with same language/different projects having significantly different rule sets. ARBCOMS are responsible for ruling on conduct using all the applicable policy, rather than (when implemented) just the UCOC. For mixed arbcoms like this to work, you would either need a complete syncing of all conduct rules within an arbcom remit, or you would need some way of having the arbs not just know the rules in each project but be at the expert level necessary for arbitrators. I'm not sure how either of those could be viable. Nosebagbear (talk) 02:20, 6 June 2021 (UTC)

The rule sets are admittedly diferring, but not significantly. Some rules can be synced, the remaining ones that cannot ("no original research" is valid on wikipedia but not on wiktionary) have to be known and respected. Merging the jurisdiction for all projects of same language under same ArbCom is still the least bad option, at least much better than a central super-wiki-tribunal with trillions of paid translators needed to handle all trouble from all wikis without own ArbCom and speaking languages that nobody understands. Taylor 49 (talk) 17:42, 8 June 2021 (UTC)

EDIT: deleted my garbage, see https://meta.wikimedia.org/wiki/User:Taylor_49#Shared_ArbCom:s where it is more appropriate

Taylor 49 (talk) 14:52, 20 June 2021 (UTC)

• Thank you Taylor 49 for citing my proposal in your feedback. I just want to add one more thing about the proposed xwikiarb: the Croatian Wikipedia disinformation report, which was released last Monday, also recommended something along the line of "encouraging the affected communities to discuss unifying community elections for admin and functionary roles across the involved wikis" as one of the report's three recommendations. I would love to think that this is a step forward to incorporate the xwikiarb model (in whatever fashion that would eventually be recommended by the Drafting Committee) for future enforcement model. RamzyM (WMF) (talk) 09:12, 21 June 2021 (UTC)

Late update and moving long text to my own page. Feel free to discuss it there. Taylor 49 (talk) 18:47, 26 December 2021 (UTC)

Model Guidelines?

Hi Barkeep49 and all,

This isn't, strictly, within the UCOC remit, but it's the type of thing that might be beneficial (it might also be non-viable - please consider this some degree of spitballing).

I think it might be beneficial for a dozen or so core conduct policies that expand somewhat beyond the UCOC be distilled from existing policies here and on other projects. A surprising number of projects don't have anything like Involved, Adminacct, etc.

Obviously, even were en-wiki's or de-wiki's (etc) assumed to be perfect by all...which is not likely to be the case, a lightweight version of each would be preferable. These could then be translated as much as possible, and further on request. They wouldn't be imposed, but would exist for smaller projects to be able to adopt should they wish. A secondary benefit of this would be the potential for standardisation, which would aid the U4C in handling those without their own arbcom but a bit better basis than the literal UCOC text. Nosebagbear (talk) 18:31, 20 June 2021 (UTC)