On Fri, Apr 3, 2009 at 8:47 AM, Robert Rohde rarohde@gmail.com wrote:
On Fri, Apr 3, 2009 at 2:30 AM, Brion Vibber brion@wikimedia.org wrote:
MZMcBride wrote:
Given that the Renameuser extension now uses the job queue for renames involving over 10,000 edits (and thus no longer locking the site for large renames), is there any technical reason not to give administrators the renameuser right?
Renaming a user who doesn't expect it would be very disruptive. This isn't something we'd really want to give out to every sysop.
I'd much rather see a sensible system for self-renames (with decent throttling, checks, etc)
I believe the immediate motivation for MZMcBride's request is actually a discussion on enwiki that there weren't enough trusted individuals to forcibly rename accounts containing sensitive information in their username. If that is the goal, then a self-renaming function would not address it.
To be honest, I don't really understand why one would use renaming over revision delete to hide bad account names, but some ArbCom members and similarly highly placed persons have stated that there are circumstances where renaming is currently preferred over revision delete.
That said, I'm also not sure why we couldn't trust sysops with this. Assuming the limitation is not technical (i.e. the servers won't explode) and renames are undoable (they are right?), then given a well-formed policy on renaming I'm not sure why giving this to all sysops would be particularly dangerous.
I certainly understand the segregation of checkuser and oversight, but renaming has never struck me as belonging to the same category of rights that need to be highly restricted.
-Robert Rohde