User:Worm That Turned/Managing functionaries, an arb's view

Recent events have made me realise quite how opaque the Arbitration Committee is when it comes to how we manage our functionaries on the English Wikipedia. This is perfectly natural - the functionaries deal with those parts of Wikipedia that are hidden behind the scenes, either protecting very personal information in the case of Oversight, or using Checkuser to look for disruption around the projects - but it's not fair on the community who we try to be transparent with.

So, let's start with the basics. Who are the functionaries? Well, it's everyone on this list and it comprises some of the most trusted users on the project. These users have dedicated a significant amount of their lives to making a difference here. Many have been elected to the Arbitration Committee and the rest have been appointed as either CU, OS or both. For the former, you have to demonstrate your trustworthiness to the community in the form of an election where over a thousands community members vote, the latter need to demonstrate good judgement and technical knowledge so that Arbcom appoint them. From there, you need to sign a non-disclosure agreement to keep the private data private.

What about when things go wrong?

Ok, so we've got the most trusted group of Wikipedians together. Does that mean that these individuals never screw up? Absolutely not! The functionaries are not special people (sorry guys), they're dedicated Wikipedians and like every Wikipedian they're passionate about the project. They're also a product of the project's rules and ideals - which includes IAR. They're not homogenous, different individuals will make difference decisions. Sooner or later, there's going to be a mistake. The Arbitration Committee holds responsibility for dealing with those issues (as does the Ombudsman, but that's a different kettle of fish).

Inactivity

Certain hard-working arbs run reports and look for functionaries that are not meeting the activity thresholds. Those functionaries are contacted by email to talk about whether they feel they can bring themselves up to the threshold and are given the option to hand in the tools. Sometimes, if they regularly stay low on the reports, it no longer becomes an option.

CU or OS problems

Firstly, let's talk about CU or OS. We have some fairly strict policies around accessing private data which both these two groups follow, but beyond that, there is some leeway how rules can be interpreted and when the tool can be used. For example, if a 10 year old intentionally released personal info, it would be oversighted, if a 40 year old did, it probably wouldn't. But it gets a little bit more grey when you are talking about a 16-18 etc. The functionaries teams are largely self regulating, getting feedback from each other, and working together as a team through mailing lists. This means that little problems can be caught early, and individuals can "course correct".

What happens though, if the peer to peer feedback is ignored or if the subject doesn't take feedback well? Well, that's where the Arbitration Committee steps in. As a group, we discuss issues that are highlighted to us, or ones that we spot ourselves. Sometimes the committee contacts individual functionaries to get more information about why they took an action they did, sometimes we treat it as a teachable moment and give direct feedback about actions which an individual should not take in the future. In almost every case we are able to find an amicable outcome where the issue does not re-occur. That's how the system works...

... Until it doesn't. Every so often, the committee gives feedback and finds the functionary doesn't take it. It might be that they are spotted doing the same thing again, it might be that they actively refuse to take the feedback. And, of course, there's the worst situation, where the actions of a functionary are so egregious that feedback and learning exercises don't cut it. In those cases, it's with a heavy heart, the committee needs to remove the tools.

There's no good way to do that. Telling someone, who had become one of the most trusted individuals on a project that they are no longer considered trustworthy enough is always going to hurt. Telling them from a position of authority, especially since committee members are not likely to be the ones on the shop floor doing the hard work, is simply not going to be taken well. To make matters worse, with trust comes friendship and so the functionary whose tools are removed will instantly have their friends hurt too - and it will be the committee who takes the brunt of that anguish.

Arb problems

People in glass houses, eh? I'm pretty sure there is a higher proportion of "problematic" users in the annals of arbitrators than there is in the general Wikipedia base. Arbitrators screw up too. Of course they do, all they've got going for them is the popular vote! So, when one of the committee starts causing problems, it's a big deal. Yes, they can be voted out by the community at the end of their term, but that could be 2 years down the line and if private information is relevant, then we have big issues.

It's important that the arbitrators self regulate, and pick up issues with each other early on. Arbs should be very receptive to feedback, to stop themselves becoming that problem, because kicking an arb off the committee, well, that's difficult. It's difficult because a person will be hurting and it's difficult because you are disenfranchising a significant portion of the community who voted for them.

But, yes, let's talk about how things work. Ealy stages will be a single peer to peer committee member talking and giving feedback. Later stages might be a group feedback discussion on list. Very late stages (and if formal complaints come in), will include hiving off to a separate list (without the subject) to consider options. Currently, it would require 2/3 of arbs to remove a sitting one ( per policy)- a high bar when there are only 15 members. So, generally, we use the same checks and balances on the committee, amongst the smaller group.