On 2/27/07, Rich Holton <richholton(a)gmail.com> wrote:
FWIW, I think that decreasing the average workload of
the "hyperactives"
should be a major priority. The quality of their work will improve, the
number of fatigue-related problems will decrease, and there may be less
hesitation in de-sysopping one of them.
I wholeheartedly agree. One thing that jumps out from the list of
deleters that geni posted
(<http://en.wikipedia.org/wiki/User:Dragons_flight/deleterlist> if you
missed it) is that about a third of the 840 admins listed have not
made a single deletion in the last 500,000. Hardly an example of
leveraging of the long tail!
This is not to say that these admins aren't doing their jobs. Indeed,
Charles Matthews and Mindspillage are both in the first screenful of
0.00% admins, and both are quite busy enough with more important
things than deletions. :-) However, there might be plenty of admins
(and non-admins, for that matter) who wouldn't mind doing a few
deletion-related tasks a week, even if (especially if?) they don't
want to focus on deletion full time.
What might work is to have a process similar to jury duty: have a
registry of volunteer admins who are assigned a very small, manageable
number of tasks randomly by bot once per week. This would clear
backlogs, and take a lot of the pressure off the current top workers
to clear backlogs. Anyone who screws up, of course, would be stricken
from the list of volunteers in minor cases, or could face desysopping
in cases of flagrant error.
The coding of the assignment bot is certainly beyond any of my skills,
but there are other other processes that currently rely on an
overworked core of regulars who tend to burn out, which could be
improved by introducing capable but non-daily-regular editor input.
These are (I believe not coincidentally) the same processes that are
most frequently described as "broken": !votes in RFA, AFD, and to a
lesser extent the other xFDs.
By explicitly balancing more of the editors' load, we can prevent
various bad things like burnout and criteria drift that result from
overwork at the core.
Implementation of any of this would, of course, require some (mostly
social) shifts in the affected process(es), but as this is not a
finished proposal, I will assume that the community is smarter than I
am and is capable of ironing out most bugs beforehand.
--Michael Noda