Last modified: 2007-03-29 20:05:36 UTC
So, for example, we see see "User:Thing that goes on feet" create a new user on 2006-06-20 07:38:17, make no contributions for over a week, and suddenly do nearly 100 moves from 2006-07-01 13:46:01 to 13:52:55. That's right, as many as 4 moves per second! So, I propose 2 things: No bot or editor or administrator should be able to do more than 1 move per minute. Just reject them. That should be easy to do in software. No bot or editor should be able to do more than 1 edit per 20 seconds. Just queue the edit until the time has elapsed. Of course, administrators should be able to go faster, as they may be hurrying to fix a problem. Heck, these days I often have to wait half a minute to see the response anyway. But I've noticed "edits" at a rate of 2-3 per second from "normal" editors at times, and when confronted they've claimed they aren't using a bot. Maybe not, but slow them down enough that others can notice the changes and react in human time frames.
There's support for rate limiting various actions in the code, but I was informed that, somewhere along the line, it was switched off on Wikimedia wikis due to incompatibilities with our shared memory caching system/opcode cache. If this is correct, then we're going to need to look into a complete rewrite of most of it.
I've been advised that the rate limiting code works. Requests to alter the thresholds should be made in the same vein as other configuration requests.
