[WikiEN-l] Arbcom

FT2 ft2.wiki at gmail.com
Tue Oct 16 12:30:49 UTC 2007


Thoughts...

Some of the things holding this problem in place seem to center around:


1) "Firefighting" mentality

An arbcom (or indeed any body) that is perpetually rushed from case to case
will burn out, and will not have time to decide whether it's tackling things
as best they could be. There needs to be slack within the arb' system, a
110% load is going to render any long term thought impractical. This is a
major cause of problems in business management, and "management" of matters
in general, not just Arbcom.

This can in part be addressed by streamlining the arb process, so that cases
take less time (by delegation, by having evidence pre-digested, checked and
summarized by clerks and trusted admins). It can also be addressed in part
by changing the structure of the processes involved (pool of spare arbiters,
multiple circuits, looking at where slowdown happens in a case that's not
productive). It can also be addressed in part by recognizing time needs to
be made, when Arbcom is fresh, to consider measures to minimize the
predictable summer slowdown, rather than walking into it, and tracking the
situation and considering remedies (stepping outside the problem to view it
from outside). These and other ideas will all have strengths and weaknesses.
But each has the potential to help, and allocating time to their
consideration will allow a good balance to be chosen.


2) High expectations by the community

As referenced elsewhere, there is a high level of expectation. The cases are
more complex, often highly multiparty; the evidence is complex; arbitrators
have outside lives and pressures, and yet are expected to rule on these
complex cases rapidly and in a way that overcomes arbcom's own differing
views and satisfies everybody elses varying feelings. There is also
considerable work "behind the scenes" (emails and the like, reviews,
requests that nobody will take rulings on except from Arbcom, appeals, etc)
that most people don't see. The level of expectation translates into a heavy
duty job, that can take Wikipedians and burn them out, or expose them to a
never ending treadmill. It's not easy, and those willing to try deserve
respect.


3) Lack of communal coherence

The community size is such that decisions on process change are not easy to
gain consensus. RFA is one perennial example. The situation that everyone
can see problems but no agreement can be reached on change (until it is so
dire that everyone will agree on * something *) is not implausible. 

Against this, arbcom has an advantage that it essentially can set its own
processes, answerable to the judgement of its own members, within a fairly
wide remit. The problems that have dogged consensus reaching on other major
processes may be less an issue in this arena. It is probably necessary for
Arbcom to do this, since it's unlikely the community as a whole will reach
broad agreement in any reasonable time frame. 


4) Mixed sense amongst administrators what exactly the community has
delegated them to do.

I think this is more an issue than is commonly recognized. Wikipedia has a
flat structure for "unilateral rulings " - basically administrators (either
individually, in discussion, or via many processes), then arbcom. The flip
side is that the majority of cases need to be handled (* effectively *) by
administrators, because Arbcom is neither designed nor has the capacity or
role, to handle more than the very small number of exceptional cases.

In some cases where administrators have not felt "safe" to take firm action,
or are worried whether they will have communal support or be criticized and
"thrown to the lions", mean that a large number of disputes where clear
problematic conduct occurs, are not dealt with at this early stage, but grow
and fester. Inevitably more of these end up being more disruptive, drawing
more people in, and clogging Arbcom later on. Administrators may need
reassurance that they * do * have communal sanction to deal with problem
editors and problem disputes at an early stage, or when borderline conduct
only, is already visible. Often a small use of tools early on when there is
misconduct happening, can keep a dispute to a smaller scale before it gets
to be a major mess (eg, the effect of 3RR on revert warring). If admins do
not feel they will be supported to fairly but firmly address situations when
early stage misconduct is clearly occurring (low level stonewalling,
incivility, OR, pov pushing, etc... the kinds of things some admins are
reluctant to take action on), then this interferes with the communal
delegation of conduct handling to them, and it's likely a proportion of
these cases will escalate and inevitably clog up Arbcom a few months down
the line.


These four are obviously not all the issues, but taken together, they are
clearly matters that help to continue the problems described. 

Movement on, or reviews of, these will probably be helpful.


</thoughts>

FT2.




More information about the WikiEN-l mailing list