On 2/27/07, Rich Holton richholton@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