|This page documents an English Wikipedia guideline. It is a generally accepted standard that editors should follow, though it should be treated with common sense, and occasional exceptions may apply. Changes made to it should reflect consensus; when in doubt, discuss your idea on the talk page.|
This page consists of guidelines as to how bureaucrats approach requests at Wikipedia:Changing username/Simple and Wikipedia:Changing username/Usurpations. Renames are a matter of discretion and bureaucrats may depart from the guidelines where there is good reason to do so.
- 1 Guidelines applicable to all renames
- 2 Additional guidelines for usurpation requests
- 3 Handling SUL conflicts
- 4 Notes
- 5 See also
Guidelines applicable to all renames
When changing usernames is probably appropriate
- Present name is a policy violation. Where a user's present name violates the username policy, renames should usually be performed.
- Privacy reasons. If a user wishes to stop using a personally identifying username (e.g. their real name or a name connected to it) this request should usually be performed. It should be noted, though, that the rename log will contain a permanent record of the name and that total privacy is only possible by creating a new account. See also m:Right to vanish.
- Eliminating SUL conflicts. It is generally helpful if users are known by the same name across Wikimedia projects. With single login implemented, renames and usurpation are the best way to achieve this.
- Personal preference. If a user would simply prefer another username, and there is no common sense reason (or reason listed below) to decline the request, renaming is typically appropriate.
- Trivial renames. The software prohibits users who are not administrators and account creators from creating usernames that add only spaces or capitalisation changes to an existing username. These may be performed even for brand new users.
When changing usernames is probably inappropriate
- Arbitration restrictions. If a user is currently restricted by Arbitration Committee rulings, renaming might cause confusion. Generally, approval should be sought from ArbCom before renames are performed in these cases.
- New username is a username policy violation. If the target username violates the username policy to the extent where their new username would be blockable, the rename will not be performed.
- Too many previous username changes. Changing usernames puts a lot of strain on the server, causing watchlist lag and even possibly causing a database lockdown. If there's no evidence that a user will stick with the new username, performing the rename is probably not a good idea.
- Confusing requests. If the request is so confused that the person requesting it may not be aware of the consequences, or has listed several different and confusing requests, asking them directly what they would prefer before renaming them is a good course of action.
- Controversial renames. When there are many editors opposing the rename (for good reason), it is apparently a controversial issue. It would probably be better to gain consensus for it first at the appropriate venues (by discussing changes to the username policy on its talk page, bringing it up at the village pump, etc.).
- Target username has edits to another WMF project. This would cause a further conflict for SUL and deprive the person who currently has the desired claim to the name globally of the opportunity to unify their login (see #Handling SUL conflicts).
Additional guidelines for usurpation requests
As a pre-note, remember, for usurpations, if User:xyz is usurping User:abc, it is necessary to rename "User:abc" to "User:abc (usurped)" to vacate the abc name for xyz.
When usurping is probably appropriate
- Deleted edits are now reallocated during renaming. As such the presence of deleted contributions by the target account is not, in most cases, a bar to usurpation.
- Both accounts are owned by the same person. If the user can demonstrate that the target account belongs to them (usually by confirming the request while signed in as that account) usurpation requests can be performed immediately regardless of the presence of edits by the target account. This also covers situations where the requester creates the account they wish to be renamed to, erroneously believing this necessary to the rename process.
- Target username consents. If the target account consents to the usurpation, the request can be performed immediately regardless of the presence of edits attributed to the target account. This should only be done if confusion will not result (the target account should not be a well-known user).
When usurping is probably inappropriate
- Target account objects to usurpation. Forced usurpations are not performed. If the target account registers an opposition to usurpation, the request will not be performed.
- Target username has edits. If the target username has good faith edits which were not immediately reverted, and the account owner has not explicitly consented to the rename, then usurping is generally not approved except to resolve SUL conflicts, when this may be done as a matter of discretion.
- Target username is too new. If the target username was created recently, usurpation is probably premature. It is expected that the target username will have existed for at least 6 months.
- Account requesting usurpation is not established. To ensure that good use is made of popular usernames, usurpation is reserved for established users. It is expected that an account requesting usurpation will have existed for several months and made non-trivial contributions to the encyclopedia. This requirement is typically waived where the request is to eliminate an SUL conflict, as described below.
Handling SUL conflicts
An SUL conflict (or Single Unified Login collision) exists when the same name is used on two or more Wikimedia projects by different users.
If a single-user login has not yet been created, the user with the most edits holds the "claim" to the SUL, and other users with the same name will be unable to create an SUL account with that name. If a single-user login has been created, unattached accounts owned by others will hinder cross-project work by the SUL owner. The global account browser may be used to check for SUL conflicts and determine the owner or claimholder.
In order to reduce the frequency of SUL conflicts as well as enhance collaboration and foster good will across the various Wikimedia projects, English Wikipedia bureaucrats will typically process requests to "usurp" unused or inactive local accounts made by SUL owners expediently and with relaxed consideration.
For the same reason, bureaucrats will typically decline to process requests by local users that would create new SUL conflicts or have the effect of allowing a local user to take over the claim from an active user on another project, even if the SUL account has not yet been created.
While renames are ultimately subject to bureaucrat discretion, a few rough guidelines are used to determine whether to grant a particular request by a local user where the name already exists on another project:
- Has the SUL already been created?
- Has the other-project user been active in the last year?
- Has the other-project user made more than 25 edits per year of inactivity?
- Does the other-project user appear to have worked on multiple projects?
- Does the other-project user have regular gaps in their editing that suggest they will be back eventually?
If the answer to one or more of the above is "yes", the request will likely be declined with a suggestion to gain consent of the other-project user.
- Except if the usurpation is for SUL unification and the target has no (or no significant) edits to articles - per Wikipedia:Bureaucrats' noticeboard/Archive 10#Modification of usurpation practice for SUL requests