Last modified: 2013-06-18 16:28:50 UTC
Bureaucrats on enwiki go through almost a thousand renames per month. We're thinking of making the Renaming function an integrated feature that is accessible through the "my preferences" tab. The immediate advantage would be preventing non-logged in users from making a request. On the interface page, this is what I envision: ------------------------------ New name: [Textbox] Reason: [Textbox] Automatically recreate old account [checkbox] (to prevent a Grawp-like situation.) (Note: Should be unchecked if renames are done for privacy concerns) Place a request (button) ------------------------------- Mediawiki then checks the following: 1. Place a warning if restricted characters are present, or if the change is to do with just underscores or first letter caps. 2. Will the current account be detached from SUL? YES => Warning to user 3. Is the requested name similar to existing user? == YES => Warning to user (that the request might be denied) 4. Is requested username available? == NO => Warning to user AND 1. If requested username not available, does requested username have 0 edits? == Yes => Display usurp instructions. Make the user confirm, and place the request at CHUU 2. If requested username not available, does requested username have <10 (edit: an arbitrary number) edits to mainspace? YES => place it on CHUU. Clerk or Crat can evaluate the criteria. 5. If warnings, user needs to confirm a go-ahead. Finally 1. Display the request on CHU 2. Display the block log of user and Display rename history 3. Places a Google search link. (to check if the username is a commercial enterprise.) Additional details are available here: http://en.wikipedia.org/wiki/Wikipedia_talk:Changing_username#Change_to_CHU_process
If this were implemented, I'd rather not use WP:CHU as the target place for processing requests. Rather, a new specialpage would probably be best.
Agreed. A special page would be the best option. Can the priority of this request be increased? The number of renames is over a 1000 per month, and there are a number of bad requests which unnecessarily consume time.
*** This bug has been marked as a duplicate of bug 15212 ***