Jump to content

Wikipedia:Request an account/Guide

Add links
Page semi-protected
From Wikipedia, the free encyclopedia

This is the request an account guide
Shortcuts

This page is the standard operating procedure manual for ACC tool users and ACC tool administrators.

If you're looking to request a new account, click here to be redirected to the correct page.



The Account Creation Interface (or ACI) is an application comprised of software that is hosted on the Wikimedia Cloud VPS, and is used to facilitate account creation requests on the English Wikipedia. Editors or users who are unable to create a new Wikipedia account themselves (either due to technical reasons or because their IP address is blocked) can instead use this interface in order to request the creation of an account to be performed on their behalf and then provided for them to use.

This is done by navigating to the account request application form page, filling out all of the required fields, and submitting the Account Request Application (or ARA) for review. From there, a qualified Wikipedia editor with the ability to handle submitted ARAs (referred to as an ACC Tool User) will evaluate and review it for any issues or concerns. After thoroughly reviewing the request and the information provided, and (if applicable) after any questions asked by the ACC Tool User have been addressed and answered by the submitter, the ACC Tool user will approve the request, create the account on behalf of the submitter using the information provided in the ARA, and send the credentials for the account to them.

This page serves as the official Account Creation Interface Standard Operating Procedures Manual (or ACC Standard Operating Procedures, ACC SOP, or simply the ACC guide page), and describes accepted practices, detailed instructions, relevant policies, and required steps and actions that must be followed in regards to the proper access and use of the Account Creation Tool User Interface (or ACC Tool User Interface). This includes, but is not limited to: the proper and correct handling, evaluation, scrutiny, and closing of ARAs (or requests) that are submitted using the Account Request Application Form webpage, and the proper and appropriate access and handling of all non-public information that is provided anywhere within it.

All ACC Tool Users and ACC Tool Administrators are required to review, understand, and reference – as well as obey, follow, fully complete, and remain within compliance of all instructions, processes, steps, procedures, and other requirements detailed and specified on this page – at all times. In addition, All ACC Tool Users and ACC Tool Administrators are required to obey, follow, and remain within compliance of all Wikipedia policies and guidelines specified on this project at all times. These requirements are strictly enforced and are a condition of holding ACC Tool User or ACC Tool Administrator permissions on the Account Creation Interface.

Introduction and prerequisites

This section provides important information, details, requirements, and instructions for editors who are interested in joining the project as an ACC Tool User, or who are registering an ACC tool account in order to access the interface as an approved ACC Tool User.

Terminology

It is important for new or prospective ACC Tool Users to familiarize themselves with the common ACC terms are used throughout Wikipedia ACC pages, the Account Creation Interface, the internal Tool User Interface, and in internal and external communications between ACC team members and outside editors and users. The common ACC terms used throughout the interface are listed, defined, and detailed below:

  • ACC - Refers to the entire Wikipedia request an account project and process in its entirety, including the software and application interface, all relevant Wikipedia pages, communication mediums, internal tool users and administrators, and all policies and guidelines associated with the project. Set as the primary shortcut on Wikipedia for navigating to Wikipedia:Request an account[note 1], this initialism became a widely and loosely used term throughout this and other related pages involving the request an account process. Unless the text specifies a specific area following the use of the term "ACC"[note 2], the initialism can be loosely referred to as the entire project as a whole.
  • Account Creation Interface (or ACI) - The application software hosted on Wikimedia Cloud VPS that is used to facilitate account creation requests on the English Wikipedia. This includes the web interface for users to request an account, the ACC Tool User interface, and all of the source code involved.
  • Account Request Application (ARA, or simply Account Request, ACC request, or Request) - The official request submitted by a Wikipedia user or editor to have a Wikipedia account created for them and on their behalf by filling out the account request application form webpage (see next term below).
  • Account Request Application Form (ARA Form, or simply the ACC form page or ACC form) - The externally hosted ACC webpage that editors or users must navigate to in order to fill out the required information and submit to the internal ACC Tool User Interface (see definition below) as an Account Request Application, so that it can be evaluated and approved by an ACC Tool User.
  • Account Request Submitter (or simply the Submitter or Requestor) - The editor or user who submitted the current Account Request Application for evaluation and approval using the Account Request Application Form webpage, and hence is requesting an account be created for them and on their behalf.
  • ACC Tool User Interface (Tool User Interface, or simply ACC Tool User page or Tool User page) - The internal ACC web interface accessed by ACC Tool Users in order to process and handle Account Request Applications (or ACC requests) that are currently open and needing review and closure. ACC Tool Users also use this interface to change internal account settings and access internal statistics, graphs, and other internal ACC functions and tools. It is accessed by ACC Tool Users by navigating here.
  • ACC Tool Account - An ACC project account that's created and registered by using this page on the Account Creation Interface to fill and submit the required information. ACC Tool Accounts generally refer to any ACC project account, regardless of its status or the level of access it has to the ACC Tool User Interface (if any).
  • ACC Tool User (ACC Tool User, or simply Tool User) - Any editor or user who has met all of the requirements listed on this page below, has been approved by an ACC Tool Administrator following a request to join the project as an ACC Tool User, and has an active ACC Tool User account in good standing – and hence currently has ACC Tool User-level access to the internal ACC Tool User Interface.
  • ACC Tool Checkuser (ACC Checkuser, or simply Checkuser) - Any editor or user who currently has Checkuser permissions on the English Wikipedia, as well as a current ACC Tool User account in good standing. All current English Wikipedia Checkusers have presumed approval and access to the ACC Tool User Interface as ACC Tool Users, but are also granted access to additional information that allow Checkusers to review and evaluate open Account Request Applications that have been deferred to them for further examination.
  • ACC Tool Steward (ACC Steward, or simply Steward) - Any editor or user who currently has global Steward permissions across all public Wikimedia projects. Just like with all English Wikipedia Checkusers, all Stewards have presumed approval and access to the ACC Tool User Interface as ACC Tool Users, but are also granted access to additional information that allow Stewards to review and evaluate open Account Request Applications that have been deferred to them for further examination.
  • ACC Tool Administrator (ACC Tool Admin, or simply Tool Admin)[note 3] - Any current ACC Tool User in good standing with access to the ACC Tool User Interface, but who has also been designated and appointed as an experienced ACC project leader and evaluator. They are granted access to additional tools, settings, and Account Request Application information on the ACC Tool User Interface, and are also tasked with additional responsibilities, such as managing ACC Tool User account approvals, controlling permissions and access to the internal ACC Tool User Interface, auditing and reviewing closed Account Request Applications for compliance, completeness, and correct handling, imposing appropriate warnings, reprimands, and remedies in response to ACC policy or process violations, and suspending ACC Tool User accounts and revoking ACC Tool User Interface access following a period of inactivity or ACC policy or process violations by ACC Tool Users. They also have the ability to ban ACC Submitters from being able to use the Account Creation Interface to submit Account Request Applications following reports of abuse or repeated submissions made in bad faith.
  • Account Creation Interface Standard Operating Procedures Manual (ACC Standard Operating Procedures, ACC SOP, or simply the ACC guide page) - Refers to this page, which all ACC Tool Users and ACC Tool Administrators are required to review and understand when performing any ACC Tool User or ACC Tool Administrator tasks, as well as obey, follow, fully complete, and remain within compliance of at all times. Compliance with the requirements stated on this page is strictly enforced and are a condition of holding ACC Tool User or ACC Tool Administrator permissions on the Account Creation Interface.
  • Tool accounts that have not been logged into for 90 days will likely be suspended due to inactivity (this is for security purposes). If your account becomes suspended due to inactivity, simply contact a tool admin in order to regain access again.
  • Despite the similar names, you do not need the "account creator" right to use the account creation interface. This is an entirely separate permission from being granted access to the interface itself. Your rights as a regular Wikipedia editor are sufficient to create accounts in normal situations. After gaining experience using the account creation interface, you may wish to apply for the "account creator" right which lets you handle more complex cases and override certain limits.

Qualifications and requirements

Shortcuts

This section lists, describes, and details each of the requirements that must be completed before requesting ACC Tool User access, as well as each of the minimum requirements that must be met in order for any ACC Tool User requests to be considered for approval.

Editors must complete all of the following requirements listed below before requesting ACC Tool User access:

For an open ACC Tool User access request to be considered for approval, editors must meet all of the following minimum requirements below:

  • Have a Wikipedia account that is at least 6 months old and has made at least 1500 edits.[note 7]
  • Have a completely clean block log or a clean block history for at least six months to one year.[note 8]
  • Have a completely clean sanction or editing restriction record or a clean sanction or editing restriction history for at least one year.[note 9]
  • Have a demonstrable history of solid knowledge and understanding of Wikipedia's policies and guidelines and Wikimedia Foundation's privacy policy, and that show themselves to be knowledgeable users.
  • Have a demonstrable history of remaining positive and civil while under pressure, and that show themselves to be able to accept/acknowledge constructive feedback and criticism.

This list is not exhaustive, but detail the important primary qualifications and experience that ACC Tool Administrators consider when reviewing an open ACC Tool User account request for consideration of approval.

Finally, the acceptance of requests are subject to the opinions of tool administrators based on the demonstrated trustworthiness, competence of the candidate, and the apparent need for more users.

ACC tool account registration

After satisfying all of the qualifications and requirements listed above, you must create and register a new ACC Tool account here if you don't already have one. When your registration is complete, your ACC Tool account and user information will then added to the list of open ACC Tool User access requests. You must then follow the instructions below in order to connect your ACC Tool account with your Wikipedia account.

Connection to your Wikipedia account

The tool will prompt you to connect your ACC Tool account to your Wikipedia account. This is done using the OAuth protocol, which grants the ACC tool with permission, as well as the necessary rights, to perform certain actions on Wikipedia, and on your behalf. This is primarily used to gain a cryptographically signed identity ticket from Wikipedia verifying that you have control of an account on Wikipedia. All tool users are required to connect their ACC Tool account to Wikipedia, but granting any additional permissions that are not necessary for completing this process are optional. This process must be completed before an ACC tool account can be approved for ACC Tool User access.[note 10]

You can see the information the tool stores about your on-wiki identity from your tool preferences.

Approval and access

If your ACC Tool User access request is approved by an ACC Tool Administrator, you will be notified of the approval through a message that's sent to the email address that you used to register your ACC Tool account, as well as a new message that's left on your English Wikipedia account's user talk page.

Declined access requests and appeals

If you have an ACC Tool account where the request for ACC Tool User access was declined, you need to submit an appeal by completing this form in order to have your ACC Tool account reviewed as an ACC Tool User access request again. Please wait a reasonable amount of time before appealing an account decline or suspension decision. In addition, excessive appeal requests without taking enough time to properly consider and address the original reasons that resulted in denial of your request will not be reviewed again or given consideration. Please do not create a duplicate new ACC Tool account, or create more than one ACC Tool account for yourself.

ACC tool user interface

Main interface – with no current requests. Note that the site notice is being displayed.

After logging in, you will see the main interface (see screenshot) — which displays a list of:

  • Open requests
  • Flagged user needed – requests needing account creator rights.
  • Checkuser needed – requests needing CheckUser attention.
  • On hold – generally requests where we are waiting on feedback from someone, typically the requester, but sometimes from a tool admin or sysop.
  • Proxy check needed – requests needing to be checked by those with proxy experience.
  • Last 5 closed requests – list of last five closed requests with zoom and reset buttons.

Request categories which need to be worked will show a number next to their title, such as Open requests 2. To view the two requests, click on Open requests. To work on a specific request, click on the green Reserve button. You will be marked as handling the request and be provided with personally identifying information of the requester and the ability to create/decline/drop the request as appropriate following the guide below.

Automatic creation of accounts and welcoming

The two different interfaces - manual creation, and automatic creation via OAuth

The tool supports both manual creation of accounts, and automatic creation of accounts via OAuth.

To support automatic creation of accounts, you must have the "High-volume editing" and the "Create accounts" grants enabled (this is the default). As of March 2021, this is also gated behind a separate tool user role during the process of slowly rolling this functionality out.

You should see a set of radio buttons next to the account creation buttons on the View Request page which allows you to choose a method to create the account - either manually (using the existing process), or automatically. You can choose your default method of account creation in Preferences, under "Account Creation Method". Automatic creation handles the creation of the account as part of closing the request, so for automatic creation all you need to do once you have decided to accept the request is choose a close type.

In the background, the tool will queue up the request to be created and closed - you will see the request move to the "Job queue" status, and a creation job will appear in the "Job Queue" page, accessible from the "View job list" button above the request log. If you need to cancel the creation for whatever reason, resetting the request will cancel the queued jobs. There will be a slight delay between queuing a request for creation and the actual creation taking place - depending on the exact time the request was queued, this will likely be between two and four minutes.

Custom closes also support automatic creation. To use automatic creation with a custom close, choose the "Create account & close request as created" option under "Action to take".

In case of a creation failure (for example if an AntiSpoof hit is detected) the request will be deferred to a "hospital" queue and an announcement will be made by the bot on IRC. If this happens, you can check the jobs to discover why the creation failed, and handle this manually. The most common cause of failure is an antispoof or title blacklist hit - the tool will not attempt to resolve this for you; fallback to manual creation is required.

Welcoming

The tool can now also automatically leave users you create a welcome template. While this functionality existed several years ago via a bot, the usage of the bot was deprecated in preference to the current system which uses your account via OAuth.

To support automatic welcoming, you must have the "High-volume editing" and the "Create, edit, and move pages"[note 11] grants enabled (this is the default). You must also choose a welcome template from the "Welcome Template Management" page - if the template you want to use is not listed, please contact a tool admin to add it for you.

Once you have chosen a template, every user you create via the tool will have their user talk page created with that welcome template. Additionally, a new switch will appear beside the creation button allowing you to skip the welcome for this specific request.

In case of a welcoming failure (for example if the user does not exist or the user talk page already exists), a job failure will be noted in the job queue, and an announcement will be made by the bot on IRC. If this happens, you can check the jobs to discover why the welcoming failed, and handle this manually.

General rules and policies when using the tool

Reviewing and processing open Account Request Applications is not a race! The account requests that are received and listed on the ACC Tool User interface are accounts which couldn't have been created under normal circumstances. Please keep this in mind and react thoughtfully. It happens sometimes that one is in the middle of a situation and one doesn't know what action to take. Just ask in the ACC IRC Channel for help in situations such as these: #wikipedia-en-accounts connect.[note 12] There are always other interface users online who are willing to assist you. In case you do not get a satisfactory response, and do not know which course to undertake, it is better to defer the request to other users rather than to undertake a wrong course of action. If you ask for help, you will need to provide (to non-admin users) the link shown on the 'zoom' page to the other user to allow them to see the private data.

If you seem to rush through a request (for example, by not performing all the checks listed below), you may lose access to the tool. It is essential that all the checks are performed to ensure that accounts are correctly created or declined.

Personally identifying information

The ACC tool contains personally identifying information and is subject to the privacy policy of the foundation. It cannot be shared outside of the interface.

Personally identifying information includes, but is not limited to:

  • IP addresses[note 13]
  • Email addresses.
  • Real names.

In order to comply with Data retention policy:

  • Email communication must be limited to their name and email address, other information including IP address or other personally identifying information is prohibited.
  • Within the interface, no identifying information should be shared in the comments of a request.
  • Outside of the interface, no identifying information should be shared in any venue. See also § Messages outside of the interface.

Additionally, any action that might produce the following is prohibited:

  • Excessive information about a block that could allow the IP to be found in the block logs.
  • Information that could create a link between a request or username, and any other element of identifying information.

Users who violate this rule and share any personally identifying information outside the ACC tool interface risk immediate and indefinite suspension, as well as the possibility of their identified status being revoked.[note 14]

Reservations

If you reserve a request and then need to go offline without completing the request, please break the reservation beforehand, so that another user can complete the request, unless you have good reason to require the request to be handled by yourself, in which case you must leave a comment. If you do not do this, the request will remain reserved and cannot be created by other users; a tool admin may forcefully break the reservation if you have left no indication as to why you need to keep the request reserved.

In addition, if you are actively working on a request that you have reserved and it's taking some time to handle (generally, more than an hour), please leave a comment on the request indicating that you are working on it and what the issue delaying handling of the request is. This informs other users and admins that you are busy on the request and that you haven't forgotten about it.

In cases where a user has had a request reserved for a long time and they have left a comment explaining the long reservation time, a reasonable effort should be made to contact them before the request is broken. However, requests reserved without explanation for a long time may be broken by an admin without warning, especially if the user holding the reservation can't be found or reached quickly on IRC.

Script usage

Using a script or other program to automatically handle requests in any way outside that which the tool provides (includes reserving) is prohibited. If you are found to be using automation of any kind or if evidence strongly supports the probability that you are doing so, you risk account suspension for violation of this rule. Using an automated add-on or script to refresh the tool interface page, however, is allowed. The refresh time must be considerate to the interface's resources and kept to as low of a rate as possible. Please keep the rate to once a minute maximum. The #wikipedia-en-accounts channel on IRC contains a live feed of new requests and changes made to them by tool users. This feed is the preferred method to view and monitor than using the interface and any automatic page refreshing tools.

Guidelines for processing requests

Checking for multiple requests

You should check for multiple requests from an IP address or an email address. To do so, click on the request ID button or click on "Zoom" in the list of last 5 closed requests, or go to the logs and click a request number. At the end of the request line—like you see normally for all open requests, you will see the UTC date and time the request was submitted. Farther down the page you would also see a list of other requests—if any, from that IP address or e-mail address.

If there are multiple open requests (but no closed requests) from the same email address, it's possible the user wanted to change their requested username. Place all the requests from that email address on hold, and send an email to the user informing the user of Wikipedia's policy on multiple accounts, listing the usernames of the requests we have received from them, and asking which one they would prefer. If there are multiple requests from an email but one of them has been recently closed as created, it's probably safe to drop the remaining requests.

Please keep in mind that shared IP addresses are common. If you have multiple requests from the same IP addresses but different email addresses, and the IP is static, defer to CheckUsers; if it's dynamic or otherwise obviously shared (for example, from a residential or mobile/cellular service provider, or an obviously shared IP like a school or library), continue handling the request (though ensure that you check for on-wiki blocks in this case).

Multiple requests to the tool are only grounds for a ban from requesting accounts in cases of clear abuse. If you have reason to think that an IP or email address has requested multiple accounts abusively, please inform a tool admin for further action. In and of itself, though, multiple requests for accounts are not grounds for a ban from ACC.

In cases where there have been a large number of requests from an IP address assigned to a school or other educational institution, especially if each request has a different email address, there is a "Educational Event or Student Edit-A-Thon" custom close template that by default defers the request to "On-Hold". This close is only intended for use in the case when there have been a large number of account requests from an IP assigned to a school, and we need more information about the desired usage of the accounts. For single account requests, use of the account as part of a school assignment or other educational use is not in and of itself grounds for a request to be rejected or held. If you aren't sure if the "Educational Event or Student Edit-A-Thon" custom close applies to a situation, please ask an ACC admin for guidance.

Blocked Network and IP Address Procedures

Please keep these points in mind when dealing with requests made from any kind of blocked IP address or range:

  • You should run the other checks first. If there are other reasons that would warrant denial from a blocked IP request, such as a username policy violation or similar username, then you should decline the request for that reason.
  • For IP addresses that are locally blocked, refer to § Local IP blocks for further instructions.
  • For IP addresses that are globally blocked, refer to § Global IP blocks for further instructions after checking any local blocks.
  • If you attempt to verify attributes on your own, such as creating or declining requests based on open-proxy, shared-IP use, etc., you take full responsibility for your actions.
  • If you are uncomfortable or uncertain with any request, the safest choice is to defer the request to CheckUsers.

When deferring a request to CheckUsers, Stewards, or proxy check, please include a brief statement on the reason for deferral. This is especially true if you are ignoring part of the guide (such as deferring an older school block).

Do not violate policy by adding any personally identifying information in a request comment – it's generally treated the same as if you did so outside of the interface (due to Wikimedia's privacy and data retention policies). See § Personally identifying information for more information.

Local IP blocks

Unless otherwise noted in this section, blocks for CheckUser-related reasons, you must defer the request to CheckUsers.

IP range blocks

These are blocks that affect a range of IP addresses, rather than just one. This is typically done to partially or completely block networks that can operate using more than one public IP address.

Any range block (affecting any kind of IP address) can be ignored only if any of the following are true:

  • The block is an {{anonblock}} or {{school block}}, or is for "simple" vandalism with no specific target (i.e., no specific subject or topic is the target of the vandalism) and there is no vandalism within the prior 72 hours of the request being entered at ACC.
  • The block is for disruptive editing with no further details (but if in doubt, ask a tool admin or an experienced ACCer)
  • The block is explicitly tagged as being ignorable by ACC (<!-- ACC ignore --> in the block reason)
  • The block does not have the "account creation disabled" parameter set.
  • The block is placed on an Opera Mini IP range, and solely because of the fact that it is an Opera Mini IP range.
  • You placed the block yourself, and you are sure the requester is not the block target.
  • The block is a soft (anon. only) CheckUser block for spam and there are no spam concerns from the request.

Any hard (not anon. only) CheckUser block for spam should be declined with the Registered ISP Email or New range email template.

If there is any other range block on the requesting IP (or any indication of sockpuppetry), defer the request to CheckUsers. Users who create accounts from requests that are in such cases and without consulting a CheckUser risk account suspension.

Single IP blocks

These are blocks that are made to a single IP address, and is commonly done to block single users (such as a residence or network with one public IP address).

Single IP blocks can be ignored if there is a non-recent (i.e., older than 72 hours) block for "simple" vandalism with no specific target (i.e., no specific subject or topic is the target of the vandalism). This includes blocks with the reasons of {{anonblock}} or {{school block}}. The fact that a blocked IP belongs to a school is not in itself an exemption.

If you have a request that you are going to decline or drop due to a single IP block, you need to either:

  • be 100% sure that this is the only person on the IP – identifying an IP as static is not sufficient, as multiple users may be connected from the same IP; or
  • have approval from a CheckUser or tool admin which is documented on the tool, before you carry out any action.

If you do not have either of these, then defer it to CheckUsers, even if it's already been there.

Global IP blocks

Check for and address local blocks first.

  • Blocks that do not have the "account creation disabled" parameter set can be ignored.
  • For IP addresses that are globally hard (not anon. only) blocked (regardless of single IP or range blocks), you should defer the requests to the Stewards.
  • Soft (anon. only) global IP address blocks (regardless of single IP or range blocks), can be ignored unless it is believed that the requester is the block target or the block reason is unusual. If in doubt, ask an ACC tool administrator, or defer the request to the Stewards.

Open or anonymizing proxies, web hosts, or Tor exit nodes

Any request from an IP address that is blocked with {{blocked proxy}}, {{webhostblock}}, {{colocationwebhost}} or {{zombie proxy}} as the reason should be deferred to the proxy check queue unless you are capable of confirming that the block reason is still valid yourself. If the request's IP is confirmed to be an open proxy, the request should be closed as "Open Proxy". If there's any indication in the block reason, or if anything comes up in other checks, that suggests that the IP address or range was used for sockpuppetry abuse, the request must be deferred to CheckUsers instead.

Soft (anon. only, with or without account creation disabled) P2P proxy/VPN blocks (e.g., {{blocked p2p proxy}}) can be ignored.

Requests stating that editing via a VPN is necessary should be referred to WP:IPECPROXY using the IPBE for VPN email template.

If there is no block indicating that an IP has been blocked as a proxy, be very careful about using the IP Check service on Toolforge or similar services. These services are frequently incorrect in determining proxy status. While other suspicious network activity may be occurring, unless the IP is static, it rarely indicates anything negative towards the user filing the request.

If you are going to defer to proxy check, have evidence not including the IP Check Service, any site listed on the IP Check Service, and any "proxy checker" website. Proper deferrals include a port number that can be tested for proxies or evidence that the ISP provides access to its own servers (web hosting, cloud services & data storage, colocation & IP transit).

Username policy procedures

All username requests must follow Wikipedia's Username Policy in order to be created. Please refer to this guideline for any policies and procedures that are not explicitly defined here. Creating accounts that violate Wikipedia's username policy will result in account suspension depending on the severity or blatancy of the username violation. Repeated violations of this rule will result in account suspension.

Real names relating to famous, popular, etc. persons

Where the requested username is a real name relating to famous, popular, etc. person the requester's identity needs to verify through the VRT system. The standard in the username policy is that the name or nickname has to relate to a "specific, identifiable" person. In terms of a test for ACC they should be notable enough to have a Wikipedia article; however, having an article doesn't necessarily mean that they are specific and identifiable and that there is a likelihood that someone is trying to impersonate them. If you believe that they are specific and identifiable and that them having the name may cause confusion, you will need to close the request as "Notable Person". If you aren't sure whether the above test is met, consult with a tool admin or experienced user, it is better to create the account in good faith (remembering that they can be blocked) than to send it to VRT to deal with.

Once VRT has verified the identity of the requester, the requester will be sent back to ACC, either by the request being reopened (if possible) with the VRT ticket number provided as a request comment, or by the requester sending in a new request and including the VRT ticket number in the request comment. However, the request must not be handled until someone with VRT access has verified in the request comments that the VRT ticket contains sufficient proof of the requester's identity and is tied to the ACC request (if you have VRT access, you may do this check yourself; just make a note in the request's comments that you verified that the ticket contains sufficient proof of identity and that the email addresses on the account request and the VRT ticket match). Once the ACC request has been positively tied to the VRT ticket, perform all other standard checks, and if everything looks good, create the account. If you create the account successfully and are a VRT user too, add the {{Verified account}} template to the top of the new user's talk page, including the VRT ticket number tied to the ACC request. If you are not a VRT user but still created the account, please as soon as possible ask a VRT user to add the {{Verified account}} template to the new user's talk page – possible venues for making this request include the VRT noticeboard, #wikimedia-vrt connect on IRC, or contacting a VRT user you know directly. Remember to include the name of the user you just created and the relevant VRT ticket number in such a request!

A request containing a VRT ticket number in the comments is not sufficient proof of identity – the validity of any mentioned VRT tickets must be verified by an ACCer with VRT access, with such verification logged in the request comments, before they are accepted!

Current ACC users with VRT access

Promotional usernames

Requested usernames should only be declined as a username policy violation where it is clear that they are – remember to assume good faith. If you are in doubt, create the account and watch it. If it is engaging in promotional editing, report the user to WP:UAA (as you would with any other promotional username and editing).

Shared usernames

If a requested username implies shared use, the request is to be closed because Wikipedia's policy on usernames state that they should not be shared between more than one individual. If you come across a request that implies such, close the request as not created utilizing the "Shared Username" option. This directs them to WP:ISU as well as takes the opportunity to link them to WP:COI, WP:PROMO and more relevant policies or guidelines.

Username conflict procedures

Wikipedia will not allow you to create an account if the requested user name:

A. is a perfect match of an existing global account,
B. too similar to an existing local account, or
C. previously used by another user.

This section will explain the procedures and policies when handling requests that meet one of those two situations.

Perfect match

A perfect match conflict occurs when the requested user name is 100% identical to a username that already exists on Wikipedia (this includes capitalization and use of symbols). If you discover that the requested username is a perfect match, then you must decline the request.

Starting in April 2015, all new accounts that are created result in the creation of a Unified Login across all Wikimedia Projects instead of simply creating a local login to one Wikimedia Project site. To prepare for this process change, all local accounts created before April 2015 whose username was taken on another project were automatically renamed, adding ~<Home Project Site> to the end in order to make them unique across all Wikimedia Projects (see the announcement here to learn more). If the requested username was previously taken but was systematically renamed as part of the preparation for SUL Finalization rule change, it will appear as a log entry and list a username such as "RequestedAccount~enwiki" in the User Page and User Creation Log.

  • If the account is taken because someone else has created an account with the exact name first, decline the request as "Taken (Standard)".
  • If the account is taken because it is taken but systematically renamed as part of the preparation for the SUL Finalization process change, decline the request as "Taken (SUL Finalization)".

If the requested account is taken, but has a different casing ("Apple" versus "APPLE") or otherwise just appears very similar (not an exact match), then refer to the "Too similar" guidelines below.

Too similar ("Flagged user needed")

Similar account flowchart

A Similar Username conflict occurs when the requested user name is similar, but not 100% identical, to another username that exists on Wikipedia. This typically occurs with requests that would normally be a perfect match to an existing account, but differs with capitalization or the use of symbols or other letters that could resemble the spelling of the existing account (i.e. "Jοhn Doe" vs "Jóhn Đoe" or "J0hn Doe"). These "similar" requests will trip the AntiSpoof extension, and flag the request for additional scrutiny under a separate queue ("Flagged user needed"). Although the ACC tool allows any user to reserve and decline requests in the "Flagged user needed" queue, only ACC tool users with the account creator flag are able to override the AntiSpoof check and create the accounts.

ACC requests that are flagged as similar can only be approved if all similar existing accounts are determined to be both unestablished (have less than a total number of local edits, global edits, and log entries) and inactive (no edits or log entries have been made within a certain time period from today). Similar existing accounts are considered both unestablished and inactive only if they meet all of the requirements in the Similar Account Flowchart, or meet all of the requirements listed below:

If the similar account has made zero (0) contributions to the English Wikipedia, the similar existing account must:
  • Have been created over six (6) months ago.
  • Have fewer than fifteen (15) total global contributions.
  • Have made their last global contribution over six (6) months ago.
If the similar account has made fewer than fifteen (15) contributions to the English Wikipedia, the similar existing account must:
  • Have been created over one (1) year ago.
  • Have fewer than fifteen (15) total global contributions.
  • Have made their last global contribution over one (1) year ago.
  • Have made their last log entry in any Wikipedia logs over one (1) year ago.
If the similar account has made fifteen (15) or more contributions to the English Wikipedia:
  • The similar existing account is considered established, and the ACC request cannot be approved (see below). The similar account's activity is irrelevant.

The ACC request cannot be approved if a similar existing account fails any of the requirements above, and hence is considered to be either established for having 15 or more global contributions, or active because their last edit or log entry was made too recently. Decline the request and use the Too Similar close email template.

If all similar existing accounts meet the requirements and hence are unestablished and inactive, the ACC request can be approved and you can proceed with creating the account (provided you are a flagged user). If you do not have the account creator flag, you must break your reservation to allow a flagged user to create the account. Creating such an account should only be done after you have conducted all relevant checks required for any new account request. In order to create the account, you must check the "Ignore spoofing checks" box on the account creation page. This tells the MediaWiki software to ignore any similar existing accounts that are identified and create the account anyway.

Previously used by another user

AntiSpoof will also trigger when attempting to create an account with a username that was used before another user was renamed.

Do not override this unless the renamed account could be ignored per the § Too similar flow. If you are unsure, contact a tool admin or place the request in the Steward queue.

Temporary Russian Wikipedia queue

For the time being, the Russian Wikipedia is directing account requests to ACC for handling in some cases like CAPTCHA issues. In the medium-term future, once multi-domain support (currently in development) is built in ACC, these will be directed to a separate, isolated ACC domain with requests being handled by volunteers from the Russian Wikipedia and not visible to English Wikipedia volunteers. Until then, however, the requests are being directed to the main application with English Wikipedia requests, but the requests will be directed to a separate "Russian Wikipedia requests" queue.

These requests should be handled in the same way as all other requests, following the guidelines outlined in this document, except that requests should be reviewed from the perspective of the Russian Wikipedia (e.g., consulting ruwiki's block log instead of enwiki's), and if an account is created it should be manually created on ruwiki instead of using the built-in OAuth account creation. Likewise, please exercise increased caution when evaluating these requests and use common sense, but there are otherwise no special handling requirements.

For additional context, please see this comment on the GitHub issue.

Guidelines for closing requests

General notes

  • When requesters fill out the request an account form, they are given the option to fill a "Comments" field. Any context added is shown in their request, and should be taken into consideration when processing a request.
  • If the exact wording of the documentation prevents you from creating an account that you feel should be created, leave a comment explaining why, and break the reservation for someone else to create.
  • If your check of the "Creation log" shows that the user created the account themselves, just drop the request, as they don't need to be confused with any of our other messages. Please leave a comment saying they created the account themselves, so that other users know why you dropped the request.
  • The requesting user can not see any comments left in the request itself, all comments there will only be visible by other tool users (or only administrators if you choose to mark the comment as "Admin only").
  • On "creates" where there are no issues with the request such as vandalism, similar names, etc. there is no need to leave a comment like "Everything looks good with this request".
  • If there is a comment on the request asking for, or suggesting, an action and you wish to do something different you must justify this in another comment. If the comment is from a tool admin or CheckUser acting in that position, there must be another comment from a tool admin or CheckUser respectively authorizing you to ignore it. Discussion on IRC is not an excuse, it must be documented on the tool.

Block evasion

If a request reveals through personally identifying information or the comments field that they may have been blocked on another account, proper procedure is to close the request as not created by using the "Block target – appeal" option. This allows the requester to get information on how they can appeal the block on their existing account either through the form of requesting on their talk page, or if unable, emailing the UTRS.

COI risk

If a request reveals through personally identifying information or the comments field that they may have ties to a company or other entity but the username policy is followed, proper procedure is to close the request as created by using the "COI risk" option. This directly invites the requester to read our relevant policies or guidelines on conflict of interest or promotion. (i.e. WP:BPCA, WP:PSCOI, and WP:PROMOTION)

Creating accounts

Once you have reserved a request, and decided that the account should be created, click the Create! link next to the desired username. This will bring you to the MediaWiki account creation form. The name and email will be filled in automatically and the "Use a temporary random password" option will be automatically selected. Do not deselect this option and type in a password. If you do accidentally type in a password and click Create Account, go to Special:PasswordReset, type in the username and click Reset password. Make sure you are logged-in to avoid disclosing your IP to the requester. If a message appears – stating the username is forbidden (example here), defer the request to an account creator who can override the Title blacklist using the "Ignore the blacklist" option. Once an account has been created, click Created! next to the request on the ACC tool.

Custom closes

All custom closes should end with an email signature. It is recommended that you add this to your preferences so it is automatically appended to any request closures you perform. If you do not, then you must add your signature at the end of your message every time you custom close a request.

Messages outside of the interface

Important things to note:

  • If you need to ask the requester a question or confirm information to continue with the request, either click the "Custom" button or click the arrow beside "Custom" to select a standard email template to preload. While waiting for a response, please defer the request to the "On hold" section.
  • Unless you are a tool admin, all requests sent from the interface carbon copy (CC) the accounts-enwiki-l@lists.wikimedia.org mailing list. If the content of your email is sensitive and shouldn't be sent to the mailing list, consider asking a tool admin to handle the request instead.
  • If you are responding to an email sent to the mailing list by a requester, make sure you select "reply all" or manually carbon copy (CC) the accounts-enwiki-l@lists.wikimedia.org mailing list. If you believe the email should not be sent to the ACC mailing list, or if it relates to the actions of tool users, you should carbon copy it to the tool administrator's mailing list, enwiki-acc-admins@googlegroups.com.
  • If you are emailing the mailing list to communicate with other tool users, please list "LIST ONLY" in the subject and text fields to make it clear that the communicate is only to other tool users and not a requester.
  • The mailing lists and IRC channel are relatively secure so personally identifying information may be discussed there. However, exercise good practice; if you don't need to share it, then don't do so – linking to a request is a good way to avoid discussing IP addresses and emails without naming them.
  • Releasing any kind of private information supplied from the ACC tool, the ACC or admin's mailing list, or the ACC or admin's IRC channel outside of those places is an extremely serious violation and will result in an indefinite suspension. Also, the Foundation takes the tool as seriously as they do with the checkuser tool, as our interface contains similar data available to tool users. Breaching this rule may result in the loss of identified status at meta and the inability to identify in the future. See this email for more information.

Tool administrators

Main page: Wikipedia:Request an account/Procedures

Tool administrators (tool admins) are trusted users who can, among other things, edit interface messages (using the Edit! buttons in Message management and Template management), and have access to a fifth option invisible to other users, User management, which allows them to approve, promote, demote, and suspend users. However, abuse of these tools is not tolerated, and the interface is not a toy.

Administrators, in addition to the main mailing list all users are subscribed to, have a private mailing list for discussion of administrative issues of the tool. Any user who wants to report an anomaly with the handling of a request, or otherwise has information they would rather share privately with only the tool admins should send an email directly to that mailing list at enwiki-acc-admins [at] googlegroups [dot] com. Please be patient, as depending on the issue, it may take us a day or two to get back to you.

A list of tool administrators can be found on the tool user list here

Interface developers

The interface developers are the team who have commit access to the tool, and as such can modify the latest development version of the tool in the code repository. If you want something to be changed or added, or find a bug, you can contact one of them, but it's probably better to file a bug in the bug-tracker on GitHub.

The tool roots are stwalkerster and FastLizard4. They have access to the server that runs the tool, and are the only people who can modify the configuration of the tool, and update the tool to a new version. The tool roots also act as the liaison between the Cloud Services administrators, and the rest of the tool users. The tool developers and roots reserve the rights to modify the tool as necessary, and to remove access to the tool for any reason as they see fit.

CheckUsers

CheckUsers on Wikipedia will automatically be granted CheckUser-only information and basic administrator capabilities on the tool in order to carry out duties relating to requests requiring a CheckUser. The tool ability is granted by a tool root or another checkuser granting you the "checkuser" role within the user management area.

If there is an urgent need to locate and contact a CheckUser who is currently online and active on Wikipedia, you can do so by requesting the attention of a checkuser on IRC, or by using this tool or this tool to locate a checkuser who is online and currently editing Wikipedia so that you can reach out to them.

Notes

  1. ^ Short for account creation.
  2. ^ An example is the "ACC page" which usually refers to the Wikipedia main ACC page, or the "ACC guide page" which refers to this page.
  3. ^ ACC Tool Administrators are not the same as English Wikipedia Administrators; editors or users who are designated as ACC Tool Administrators should not be presumed to also be English Wikipedia administrators and vice versa.
  4. ^ This is a Wikimedia Foundation policy requirement due to the nonpublic information that ACC Tool Users have access to in order to review and evaluate open Account Request Applications.
  5. ^ Any submitted requests to join this project as an ACC Tool User will be rejected by an ACC Tool Administrator if this requirement hasn't been completed first. If your ACC Tool User access request was rejected for not meeting this requirement, you can submit an appeal in order to have your ACC Tool User access request reviewed again after you've signed the agreement and have been added to the list of users on the nonpublic personal data policy noticeboard page.
  6. ^ After being approved as an ACC Tool User, your email address must be subscribed to the ACC mailing list by signing up here. Notifications regarding changes to the ACC Standard Operating Procedures are sent to all ACC Tool Users using this medium, and all ACC Tool Users are responsible for keeping up with them. The ACC mailing list is the communication method that Account Request Submitters typically use in order to ask the team for help, and is one of the primary discussion mediums for ACC project members (the other being the #wikipedia-en-accounts IRC channel).
  7. ^ Cases of new accounts being created due to lost passwords etc will be considered on a case-by-case basis — be sure to let us know, probably by email to the mailing list.
  8. ^ ACC Tool Administrators can require a longer clean block history from a user before considering their ACC Tool User access request for approval. The exact length of time required is set at the sole discretion of the ACC Tool Administrators, determined on a case-by-case basis, and can change or completely disqualify a user from consideration for approval depending on the nature and severity of any blocks that are found in the user's account history, as well as any other information found that is deemed to be relevant.
  9. ^ Users who have a history of repeated sanctions or editing restrictions, or been subject to more than one different sanction occurrences in the past, may be required to have a longer clean history depending on the severity or circumstances. This is especially true for users that have been found to have violated any of their sanctions, bans, or editing restrictions while currently in effect, had disciplinary action enacted upon themselves in response to a violation of a sanction or restriction, or have a history of any kind or level of abuse.
  10. ^ Failure to complete this step will result in your account being declined, as we cannot prove the connection between your registration, and your Wikipedia account. If you accidentally cancel the OAuth authorization process, you can restart the linking by logging in to the interface using the password you specified during signup and continue the authorization process.
  11. ^ This is quite a wide group of permissions to grant, but unfortunately it is the only one which allows creation of talk pages (createtalk).
  12. ^ If you are not using webchat, you must connect to Libera Chat using TLS.
  13. ^ See exception for § Open or anonymizing proxies, web hosts, or Tor exit nodes.
  14. ^ See this email for more information.

See also

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Request_an_account/Guide&oldid=1316179312"