User:ElHef/sandbox/ACCG

Things to work on

• Introduction
• Everything under closing
• The volunteer page
• OAuth stuff
• Accounts for minors
• Email buttons
• Diffs from later guide updates [1] [2] [3] [4]
• Go through initial removals for admin stuff that might need added back to ACCP

Introduction and General Stuff

• The Account Creation Interface is an application software hosted on Wikimedia Cloud VPS that is used to facilitate account creation requests on the English Wikipedia. This guide describes accepted practices in handling requests that are submitted to the tool. Users who wish to participate in this process must apply for access pursuant to the required qualifications that are listed in this guide. New interface users should read this page thoroughly and experienced users should periodically check for updates.

• 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.

• Please remember that account creating is not a race! The requests that end up in the ACC 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. 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.

Please note: 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.

• 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.

• 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.

Personal information

The ACC tool contains personal information which is subject to the privacy policy of the foundation. The term "personal information" is defined in the privacy policy and includes, but is not limited to IP addresses, email addresses, and real names.

No personal information may be shared in any venue, including within the interface itself (such as within the comments of a request). It is also prohibited to share information about a block that could allow the IP to be found in the block logs, or information that could create a link between a request or username and any other element of identifying information (even if you're not directly sharing specific pieces of personal information).

Users who violate this rule risk immediate and indefinite suspension from the ACC tool, as well as the possibility of their confidentiality agreement being revoked and the inability to sign the confidentiality agreement in the future. The Foundation treats the ACC tool as seriously as they do the Checkuser tool, as the interface contains similar data to what is available to Checkusers. See this email for more information.

The following are exceptions to this rule:

• Email communication with a requesting user may include their name and email address (but no other personal information, including IP addresses).
• The accounts-enwiki-l and enwiki-acc-admins mailing lists and the #wikipedia-en-accounts IRC channel are relatively secure so personal information may be discussed there if needed. However, exercise good practice; if you don't need to share it, then don't do so - linking to a request (thus allowing other ACC users to access the information themselves) is usually sufficient.

Script usage

Using a script or other program to automatically handle requests in any way (includes reserving) is prohibited. 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 ^connect 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 monitor new requests instead of using automatic page refreshing tools in the interface.

Advanced tool users

Tool administrators

Main page: Wikipedia:Request an account/Procedures

Account Creation Interface administrators (herein referred to as tool administrators or administrators) are not the same as Wikipedia administrators (herein referred to as sysops) or Wikipedia interface administrators (herein referred to as intadmins). Most Wikipedia sysops and intadmins are not tool administrators.

Tool administrators are experienced and trusted ACC users who can access the User Management screen, which allows them to approve or decline new ACC tool users and promote, demote, and suspend existing ACC tool users. They can also edit interface messages, ban and unban requesters who have abused the ACC process, and break reservations of requests reserved by other users (among other things).

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 appeal a suspension or denial from ACC, 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, FastLizard4, and AmandaNP. 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 and Stewards

CheckUsers and Stewards with a tool account have access to CheckUser-only information and basic administrator capabilities on the tool in order to carry out duties relating to requests requiring a CheckUser. This ability is granted by having the 'checkuser' role assigned by an administrator.

If there is an urgent need to find an active CheckUser, consult IRC or this tool to see who has recently been active.

Flagged users

The term "flagged user" is used frequently in this guide and in the ACC interface. It refers primarily to users with the Account Creator role, and also includes users with roles containing the same abilities (such as sysops and bureaucrats with ACC interface access). See Wikipedia:Account creator for details on the relevant technical abilities of flagged users.

Navigating the Interface

After logging in, you will be taken to the ACC interface home page - the Requests page.

The Requests page, showing active requests in the Open Requests, CheckUser, and Proxy queues. Note that the site notice is being displayed.

Top links

In the header of every page, there are a number of links:

• Requests: returns you to the Requests page (home page)

• Meta:
  • Logs: shows recent activity within the interface
  • Users: shows all users with access to the interface, categorized by status
  • Search: allows a search of the ACC interface logs (not Wikipedia's creation logs)
  • Statistics: shows statistics about the ACC interface and its users

• Admin:
  • Ban Management: allows administrators and CheckUsers to ban or restrict usernames, e-mail addresses, and IP addresses from requesting accounts (users can view this screen with private information redacted)
  • Close Email Management: standardized e-mails which are sent to the requester of a new account when a request is closed (users can only view the emails)
  • Welcome Template Management: allows you to choose a template to use to automatically welcome the users you create (see LINK)
  • Job Queue: shows the background jobs involved in automatic (OAuth) creation and welcoming of new accounts (see LINK)

• Jump to request ID: enter a request ID number here to jump straight to the Zoom page of that request

• Your User Name (on the far right side):
  • My statistics: shows your statistics for tool activity
  • Edit preferences: update your email address, email signature, default account creation mode (manual vs. automatic), and tool theme (light vs. dark)
  • Change password: please choose a strong, unique password to protect the security of your tool account
  • Configure multi-factor credentials: set up or modify multi-factor authentication for your tool account. The ACC tool currently supports TOTP and YubiKey OTP. ACC users are strongly encouraged to use MFA to improve the security of their account.
  • Un-hide site notice: displays the site notice at the top of the page if it has been hidden
  • Guide: opens this guide
  • Username policy: Links to WP:UPOL
  • Similar account flowchart: A basic flowchart showing how to handle similarly named accounts
  • Chat: Join #wikipedia-en-accounts ^connect
  • Mailing list: Links to the accounts-enwiki-l info page, to access the mailing list archives and your list settings
  • Logout

The Requests page (home page)

The Requests home page displays the queues of active requests:

• Open requests - requests that can be worked on by any ACC user.
• Flagged user needed - requests needing account creator rights.
• Checkuser needed - requests needing CheckUser attention.
• On hold - requests that are waiting for something, often a response from the requester. Requests here will have notes explaining the situation.
• Proxy check needed - requests needing to be checked by those with proxy experience.
• Steward needed - requests needing to be checked by a steward.
• Job queue - requests that have been reviewed and are queued for automatic creation. Requests should disappear from this queue within a few minutes. This queue is hidden when empty.
• Hospital - requests that have failed automatic creation and need manual intervention. This queue is hidden when empty.

Queues containing active requests will show a number next to their title, such as Open requests 11. To view the requests in a queue, click on the title of the queue to expand it. To work on a specific request, click on the green Reserve button. You will be marked as handling the request and be provided with personal information of the requester and the ability to create/decline/drop the request as appropriate following the guide below. Clicking on the blue "Zoom" button (with a magnifying glass icon and the request number) will open a summary of the request without showing personal information. You cannot create the account or decline the request from this view.

The Requests page also contains a list of the last five closed requests, each with a Zoom button (to view the request) and a Reset button (to re-open a request that was closed in error).

Handling Requests

Screenshot of the internal interface when viewing a request reserved by the currently logged in user.

NEED A NEW SCREENSHOT WITH CURRENT BUTTONS. Preferably one from a non-admin. Screenshots of ban buttons and ban interface should go at ACC/P.

After reserving a request, you will see the Details page for that request. This will include the requester's e-mail address, IP address, the requested username, the date of the request, and a number of links to track the status of the request and provide you with additional information about the request.

When handling a request, it's important to perform all checks on the request. If you find one issue with a request, there may be more than one, so it's best to gather all the data before deciding how to close a request.

Managing your reservation

To alert other users that a request is already being handled, you must reserve a request to work on it. As long as a request is reserved, no other ACC user can work on it. Your reservation is automatically released when the request is closed or deferred. The following Detail page links manually change your reservation:

• "Break reservation": Releases your reservation so another user can handle the request
• "Send reservation": Assigns the request directly to another user that you specify. When taking this action, make sure the other user is aware of the assignment; the interface does not notify them automatically.
• "(reveal to others)": This is a link that can be shared with other tool users to allow them to see the details of a request that you have reserved, without breaking your reservation.

You should typically only reserve one request at a time unless you are working on multiple requests at once (for example, if there are multiple requests from the same user or e-mail address). The interface will warn you if you if you have more than one request reserved.

If you are actively working on a reserved request and it's taking some time to handle (generally, more than an hour), please leave a comment on the request describing the delay to let other users know that you haven't forgotten about it. If you need to go offline without completing a request, please break your reservation so that another user can complete the request (unless you have good reason to keep it reserved - leave a comment). Requests reserved for a long time may have the reservations broken by a tool admin, especially if no comment was left.

Deferring the request

Use the Defer button to move the request to a different queue (leaving it active), bringing it to the attention of users with the correct permissions or knowledge to handle the request. If you have the request reserved, this will automatically break your reservation. When deferring a request, you should generally leave a comment with the reason for the deferral. A request can be deferred to Users, Flagged Users, On Hold, Checkusers, Proxy Check, or Stewards.

Comments and the Log

The log within each request begins with the comment made by the requesting user (if they chose to make one), and documents the history of the specific request. The requesting user cannot see comments left in the request log. Comments are only visible to tool users, and can be further restricted to Checkusers and/or administrators by clicking the lock icon next to the "Save" button. Do not share personal information in the comments of a request. If the requesting user left personal information in their comment, contact an administrator (preferably by IRC, or by emailing the admin's mailing list if you're not active on IRC) to redact the information.

The requester's comments and any other comments left by other ACC users should be taken into consideration when processing a request. If there is a comment from another ACC user requesting or suggesting an action and you wish to do something different, you must explain in a comment. Comments from administrators or checkusers acting in that capacity may not be ignored unless there is another logged comment from a tool admin or checkuser that specifically permits it. Discussion on IRC is not sufficient.

Multiple requests from an email/IP address

When a request is reserved, the interface automatically checks for other requests from the same IP address or email address. If multiple requests are detected, you will see a number on a red background next to the IP address and/or email address in the Details at the top of the request. Information on the additional requests will be displayed at the bottom of the page under "Other requests from (address)".

• If there are multiple open requests (but no closed requests) from the same email address: Perform the usual checks on the IP address and all usernames. If multiple requests could be created, send a custom email to the requester 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. Defer all of the requests from that email address to On Hold.

• If there are multiple requests from the same email address, but one has been closed as created: Drop the remaining open requests.

• If there are multiple requests from the same IP address (but different email addresses): Shared IP addresses are common. If the address is dynamic or otherwise obviously shared (for example, a school, library, residential or mobile/cellular service provider), continue handling the request (though be sure to check for active blocks). If the address is static or you're uncertain, defer all of the requests from that IP address to Checkusers.

• If there are a large number of requests from an IP address assigned to a school: The "Educational Event or Student Edit-A-Thon" template (listed under the Custom button) may be appropriate. This defers the request to On Hold, and asks that the instructor contact us. This is only intended for use when there have been many requests in a fairly short period of time. Single requests from a school address should be handled as normal. Most multiple requests should be handled as noted above. If you aren't sure if this applies to your situation, please ask a tool administrator for guidance.

Tool administrators have the ability to ban email addresses, IP addresses, or usernames from requesting accounts in cases of clear abuse. If you think that an email address or IP has requested multiple accounts abusively, please inform a tool admin for further action. In and of itself, making multiple requests is not grounds for a ban.

Checking the IP Address

The IP Address data can appear in a few different ways. The most common by far is to see a "trusted" IP address and an "origin" IP address. This shows that the request has been routed through a trusted server, and shows the true origin of the request. Trusted addresses are ignored (and do not have links to be checked). Checks are performed on the origin address, and any other untrusted addresses which may appear (essentially, any address that has links to be checked should be checked). For more information on how to interpret this section, see this page.

A good first step is to check the IP's talk page. This tends to present a good summary of what to look out for when performing other checks. Don't rely on information here to close a request, but warnings, block notices, or other information shown here (if any) can steer you toward more specific, relevant checks to perform first.

Specific checks on the IP address fall into three main groups: Contributions, blocks, and proxy checks.

Contributions

• "Local Contributions" links to the IP's contributions on the English Wikipedia
• "Deleted Edits" links to the Edit Counter tool showing the IP's deleted edits (among other information)
• "Global Contributions" links to the IP's contributions across all Wikimedia projects
• "Abuse Filter Log" shows all actions from the IP that have tripped an edit filter

When reviewing the contributions it's important to remember that many IP addresses are dynamic and/or shared, so it's rare to find a problem severe enough to decline a request based on contributions alone. This information is more useful in combination with other checks. For example, vandalism around the time of the request in combination with a block may need to be reviewed by a Checkuser (see LINK).

Things to look for are vandalism and other non-constructive editing, locally and globally, around the time the request was made (within roughly 72 hours). Contributions outside of this timeframe are unlikely to be related to the request and are typically ignored. If there are a large number of deleted edits and you're not a sysop, consider requesting help from an ACC user who is also a sysop (preferably on IRC).

Blocks

• "Local Blocks Log" links to the IP's block log on the English Wikipedia (does not check for rangeblocks)
• "Active Local Blocks" checks for any active IP blocks on the English Wikipedia (including active rangeblocks, but not expired blocks)
• "Global Blocks" links to the IP's global block log on Meta (does not check for rangeblocks)
• "Active Global Blocks" checks for any active global IP blocks (including active rangeblocks, but not expired blocks)
• "Rangeblock finder" checks for expired and current rangeblocks which apply to the IP (note that /32 blocks are the same as single IP blocks)

Use these tools to review the block history of the IP address, including any applicable rangeblocks. As with reviewing contributions, the most important information to review is what blocks were in place at the time of the request. For requests that have been open for a long time, blocks placed after the request should be checked as well. Expired blocks can show a pattern in certain cases, but are unlikely to be related to the request and are typically ignored.

Single IP blocks are commonly used to block single users (such as a residence or network with one public IP address). Rangeblocks 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.

If you are uncomfortable or uncertain with the blocks or block history of any request, the safest choice is to defer the request to Checkusers.

Blocks to Defer

Blocks meeting one (or more) of the following criteria should be deferred to the indicated queue. When deferring a request, please include a brief comment on the reason for deferral. Do not put any personal information in a comment. See LINK for more information.

1. For checkuser-related reasons for the block, you must defer the request to Checkusers.
2. Blocks with {{blockedproxy}}, {{webhostblock}}, {{colocationwebhost}}, or {{zombie proxy}} as the reason should be deferred to Proxy Check (unless you are capable of confirming that the block reason is still valid yourself).
3. Global hard blocks (i.e. blocks without the "anon. only" parameter set) should be deferred to Stewards.
4. Any block that doesn't meet any of the criteria to be deferred or ignored should be deferred to Checkusers.

If you discover a block that requires the request to be deferred, you should still run the rest of your checks before deferring the request. If there are other issues that would cause you to decline the request (such as a WP:UPOL violation or a similar username) then you should decline the request for that reason.

If a request has blocks that meet more than one of these criteria, defer the request to the first applicable queue on this list. (For example, if a request has blocks tagged with both {{checkuserblock}} and {{blockedproxy}}, the request should be deferred to Checkusers first.)

Blocks to Ignore

A block can be ignored only if one (or more) of the following criteria is true. In these cases, the request is likely due to a block that was not caused by the requester, and WP:AGF would apply. If you find a block that you think should be ignored but doesn't exactly meet any of the criteria listed here, explain in a comment and either break your reservation so another ACC user can review the request, or defer to Checkusers.

• You placed the block yourself, and you are sure the requester is not the block target.
• The block expressly asks ACC users to ignore the block (<!-- ACC ignore --> is in the IP's block log summary).
• The block does not have the "account creation disabled" parameter set.
• The block is an {{anonblock}} or {{schoolblock}}, 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 fact that a blocked IP belongs to a school is not in itself an exemption.
• The block is for disruptive editing with no further details. (If in doubt, ask a tool admin or an experienced ACC user.)
• The block is placed on an Opera Mini IP range, and solely because of the fact that it is an Opera Mini IP range.

Declining or dropping requests due to block history

If a request reveals through personal information or a comment that they may have been blocked on an existing account, decline the request as "LOCAL block target - appeal" (for most local blocks) or "Promotional username block - appeal" (if the account was blocked due to a promotional username). This gives the requester information on how to appeal the block on their existing account through their talk page and UTRS. Requests clearly made in bad faith by blocked users can be dropped, and should also be brought to the attention of a tool administrator as the user may need to be banned from making future requests.

Requests that need to be declined or dropped due to a block of the IP address are usually closed by experienced ACC users working in queues such as Checkusers or Proxy Check, and handling requests in these queues is beyond the scope of this guide. If you don't have the appropriate technical experience and/or user rights, defer the request to someone who does. If you close such requests on your own (for example, by creating or declining requests due to open proxy) you take full responsibility for your actions, and may be suspended from use of the ACC tool if you handle requests incorrectly.

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

1. 100% sure that this is the only person using the IP address. Identifying an IP as static is not sufficient, as multiple users may be connected from the same IP; or
2. Approval from a Checkuser or tool administrator which is documented on the tool, before you carry out any action.

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

Proxy

• "Whois" runs a WHOIS on the IP address
  • "(alt)" uses whois.domaintools.com instead of the Toolforge tool.
• "Project Honeypot" tracks IP addresses that have been involved in various forms of email fraud
• "StopForumSpam" tracks IP addresses that have been used to post spam or register bad accounts on forums
• "IP Check" provides extra data about an IP address from a number of sources

In many cases, open or anonymizing proxies are already blocked from editing (see WP:PROXY). Any request from an IP address that is blocked with {{blockedproxy}}, {{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. Information on performing proxy checks is beyond the scope of this guide. If there is anything in the block reason or which comes up in other checks that suggests sockpuppetry, defer to CheckUsers instead.

The above checks can be used to indicate that there may be a proxy involved, but if there is no proxy block in place, these checks should be viewed with skepticism as they 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 for a non-blocked IP address, you should 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).

If the request's IP is confirmed to be an open proxy, the request should be declined as "Open Proxy" or "Open Proxy (Webhost)", whichever is more applicable. Requests stating that editing via a VPN is necessary should be declined as "IPBE for VPN".

Checking the Username

The Username links group contains the following (all links point to the English Wikipedia unless noted otherwise):

• "User page": links to the user page of the requested account
• "Creation log": links to the account creation log for the requested account
• "Global Rename log": links to the rename log on Meta to see if the requested account has been used previously and renamed
• "Special:CentralAuth": links to MediaWiki's global user manager to check for similar usernames
• "Local Username list": links to the user list on English Wikipedia to check for similar usernames
• "Global username list": links to the global account list to check for similar usernames
• "Wikipedia mainspace search": searches Wikipedia mainspace (articles) for the requested username
• "Google search": searches Google for the requested username

The checks performed here will help you determine two things:

1. Does the requested username violate the username policy?
2. Is the requested username too similar (or identical) to an existing or previously-used (renamed) account?

Username policy

All requests must comply with Wikipedia's Username Policy in order to be created. Always do Google and mainspace searches to look for issues that aren't immediately obvious – for example, the name of a notable person, a company or organization, or an offensive slang term you don't know. Take all information into account when performing your checks, including things such as the requester's email address, any comments they left, where their IP address geolocates to, etc.

• If the name cannot be used for technical reasons (such as containing invalid characters # / | [ ] { } < > @ % : , ) decline the request as "Invalid". Do not use this for usernames with non-Latin characters as these are allowed.
• If the name implies shared use (but doesn't exactly match the name of a company), decline the request as "Shared Username".
• If the name exactly matches the name of a company and cannot represent an individual, decline the request as "Company Name as Username".
• If the name is the real name of a specific, identifiable, living notable person (and there is no indication it has been verified through OTRS), decline the request as "Notable Person". As a general rule, the person should be notable enough to have a Wikipedia article, and the name specific/identifiable enough that the request is likely to be an attempt at impersonation. If the request does have OTRS verification information, see § Notable people and OTRS verification.
• If the name violates the username policy but doesn't fit any other decline reason, decline the request as "UPol Generic Violation" (though consider sending a custom message if the violation isn't obvious).

Requests should only be declined as a username policy violation where there is a clear violation – remember to assume good faith. If you are in doubt, either leave a comment and break your reservation to allow another ACC user to check it, or create the account and watch its contributions, reporting it to WP:UAA if necessary (as you would with any other user).

Blacklisted usernames

Blacklisted username warnings can appear in the "Username data" section of the request and/or when attempting to create the account (example). To determine whether a blacklisted username can be created, it's important to know why the username is blacklisted. Many are fairly obvious, but each case is different. If the request violates the username policy, it should be declined as noted above. If all checks pass, blacklisted usernames will need to be created by a flagged user. If you are not a flagged user, make a comment that you have completed the checks and defer the request to flagged users. See also § Creating the account.

Notable people and OTRS verification

If the requested username is the real name of a notable person and the request does indicate that the requester's identity has been verified through OTRS (for example, by including the OTRS ticket number in a comment), an ACC user with OTRS access must review the request to ensure that the OTRS ticket contains sufficient proof of the requester's identity and that the email addresses on the ACC request and the OTRS ticket match. This review must be noted in the request comments by the OTRS user before the account can be created – simply listing the OTRS ticket number in the request is not enough.

Once the ACC request has been positively tied to the OTRS ticket, perform all other standard checks, and if everything looks good, create the account. After the account is created, ask an OTRS user to add the {{Verified account}} template to the new user's talk page as soon as possible (or add it yourself, if you are an OTRS user). You can contact an OTRS user directly, or ask at WP:OTRSN or #wikimedia-otrs ^connect.

Current ACC users with OTRS access

• AntiCompositeNumber
• Callanecc
• Cameron11598
• Clarkcj12
• CodeLyoko
• Dane
• DeltaQuad
• FlightTime
• GorillaWarfare
• JJMC89
• Jamesofur
• KrakatoaKatie
• Matthewrbowker
• Oshwah
• Ponyo
• TheDragonFire

Similar and identical usernames

The Username checks and the "AntiSpoof results" section of the request will help you discover if the the requested username is a perfect match to an existing or previously-used (renamed) username, or similar to one or more existing usernames. Certain usernames must be handled as noted below. Beyond these specific cases, determining whether a username is similar is a judgment call for the ACC user handling the request. If you're not sure, ask for help on IRC and/or leave a comment in the request and defer to Flagged Users.

• If your checks show that the requester was able to create an account for themselves – for example, if an identical username was created within hours of the request, or a similar username was created after the request and is editing areas that the request mentioned – drop the request with a comment saying the account was self-created. (There's no need for us to contact them about their account creation request when they've already created the account.)
• If the requested username is 100% identical to a username that currently exists on Wikipedia, decline the request as "Taken (Standard)". If there is any difference in the username (whitespace, capitalization, use of symbols or punctuation, etc.), then the requested username not a perfect match (but may still be similar).
• If the requested username trips the AntiSpoof extension (either in the "AntiSpoof results" section of the request, or by the MediaWiki software returning an error message when attempting to create the account), any conflicting username is similar – follow the flowchart below. These are requests that are nearly identical to an existing username but differ with capitalization or the use of symbols or other letters that could resemble the spelling of the existing account (e.g. "Jοhn Doe" vs "Jóhn Đ0e" or "Johndoe").
• If the requested username is 100% identical to a username that was used by another user before that user was renamed (this will appear in the Global Rename log), the renamed account is similar even though the new username may be completely different from the requested username – follow the flowchart below.

Similar account flowchart

Similar account flowchart

If you've determined that the requested username is similar to an existing username, the requested username can be created only if all similar existing accounts satisfy 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 at least one (1) but fewer than fifteen (15) contributions to the English Wikipedia, the similar existing account must:

• Have been created over one 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 English Wikipedia logs over one (1) year ago.

If the similar account has made fifteen or more contributions or otherwise fails to meet these criteria in any way, decline the request as "Too Similar", no matter when the similar account was created or last used.

If all of the requirements above are met, continue to check the request. If all other checks pass, the account will need to be created by a flagged user. If you are not a flagged user, make a comment that you have completed the checks and defer the request to flagged users. See also § Creating the account.

Creating the account

Once you have reserved a request, performed all checks, and decided that the account should be created, you are ready to create the account. The interface supports both manual creation of accounts, and automatic creation of accounts via OAuth. Automatic creation is in the process of being slowly rolled out, so may not be available to you yet.

Manual creation

Click the "Create account" button to open the MediaWiki account creation form to create the account. The username and email address 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 create the account, go to Special:PasswordReset, type in the username, and click "Reset password".)

If a message appears stating that there are similar usernames, see § Similar and identical usernames. If a message appears stating that the username has been blacklisted, see § Blacklisted usernames. Accounts with these messages can only be created by a flagged user. Flagged users can use the "Ignore spoofing checks" and "Override the title blacklist if it matches" checkboxes to override these messages as needed.

In rare cases, bugs in the tool may replace certain non-Latin characters in a username with invalid characters when filling in the username field on Special:CreateAccount. In such cases, you should manually copy and paste the name as it appears in the ACC interface into the username field.

Once you have successfully created the account, return to the interface to close the request (link this).

Automatic creation

Add stuff from stwalkerster

Closing the request

Creating accounts

• "Created!": Once the account has been manually created, this option closes the request, sends an email to the requester to notify them, and automatically welcomes the new user on their talk page (if enabled; see LINK).
• "Create and close as Created!": Automatically creates the account via OAuth, closes the request, sends an email to the requester to notify them, and welcomes the new user on their talk page (if enabled; see LINK).
• The dropdown arrow next to "Created!" and "Create and close as Created!" offers additional templated emails to send to the requester. Other than sending a different email message, these options function identically to the button they are attached to.
• "Manual / Use my Wikimedia account" radio buttons: Toggles between manual and automatic creation of the account, if available.
• "Skip automatic welcome on account creation" switch: If automatic welcoming is enabled, choosing this option will prevent automatic welcoming for this request only.

The Request Status group contains the possible resolutions that can be given to a request. Note that these are not links to policies - all options here will perform an action on the request, and options under Created, Declined, and Custom will send an e-mail to the requester.

• To inform the requester that the account was created:
  • "Created!" if you were able to create the account.
  • "Long response time" if you were able to create the account, but it took a long time (due to additional checks, backlog, etc.) Includes an apology to the requester for the delay.
  • "COI risk" if you were able to create the account, but you suspect the requester has ties to a famous person or company and presents a COI risk. Includes links to WP:BPCA, WP:PSCOI, and WP:PROMOTION.

• 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".

Although the ACC interface allows any user to reserve and decline requests in the "Flagged user needed" queue, only ACC users with the account creator or sysop userright have the technical ability to override the AntiSpoof check and create the account. If all other checks pass (and you are a flagged user), create the account and check the "Ignore spoofing checks" box on the account creation page to tell the MediaWiki software to ignore the similarities. If you are not a flagged user, make a comment that you have completed this check and defer the request to Flagged Users.

If a request reveals through personal information or the comments field that they may have ties to a company or other entity but the username policy is followed, 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)

Declining a request

• Decline to inform the requester that you are unable to create the account. Pick from one of the following reasons:
  • "Too Similar"
  • "Taken (Standard)"
  • "UPol Generic Violation"
  • "Invalid"
  • "Password Reset" if you have sent a password reset email to a similar username, because it was created recently and appears to belong to the requester. Note that if it was created very recently (e.g. a few minutes after request) you can assume that the requester managed to create it and Drop the request, after commenting an explanation Figure out where to put this
  • "Open Proxy"
  • "Notable Person"
  • "Shared Username"
  • "LOCAL block target - appeal"
  • "Promotional username block - appeal"
  • "Registered ISP Email or New range (When authorized)" should only be used by a checkuser or with their direct approval. MORE??
  • "GLOBAL block - appeal" if the request relates to the user wanting to appeal a global block Need more details here
  • "Company name as username"
  • "Disposable email address" if the request uses a disposable email address Add this to email checks when written
  • "Open Proxy (webhost)"

Sending a custom e-mail

• Custom allows you to write a custom e-mail to the requester when none of the above options describes the particular situation. You can start from a blank e-mail, or preload one of the other e-mail templates and modify it as needed. You can choose which action to take after sending the e-mail - no action (just send the e-mail), close as Created, close as Declined, or Defer to another queue. Custom emails are logged in the request and CCed to the mailing list.

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

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-llists.wikimedia.org mailing list. 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-llists.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-adminsgooglegroups.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 personal 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 serious 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.

Drop

• Drop closes the request without creating an account or notifying the requester. This should be used with caution. Common reason to do this is when the requester has created an account for themselves since the request was made, or a request clearly made in bad faith that should simply be ignored.

To go elsewhere

MAKE THIS SECTION A SEPARATE PAGE (ACC/Volunteer or somesuch)

Registering for use After meeting the qualifications below, you must register here before handling requests using the interface. Your request must be approved by a tool administrator and if approved, you will receive a notice on your talk page. In the event that your request is denied, you will receive an email explaining why. Notes, terminology, and requirements Account Creation Interface administrators (herein referred to as tool administrators or administrators) are not the same as Wikipedia administrators (herein referred to as sysops) or Wikipedia interface administrators (herein referred to as intadmins). Most Wikipedia sysops and intadmins are not tool administrators. 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 for using the interface To qualify as an ACC user, you must meet the following minimum requirements: You must sign the confidentiality agreement for access to nonpublic information per Wikimedia Foundation policy. Please ensure that you are listed on the access to nonpublic personal data policy noticeboard before requesting access to ACC. Submitting a request to join ACC before you are listed on the access to nonpublic personal data policy noticeboard will likely result in an administrator rejecting your request, requiring you to submit an appeal by email once you have been listed. You have a clean block log or if you have had a block it must not be recently placed (preferably not within 6+ months, depending on length of block.) You need a valid email address that you actively watch that must be subscribed to the mailing list. (Signup here after being granted access to the interface.) Tool policy change notices are sent out this way, and you are responsible for keeping up with them. You have no recent editing restrictions, had disciplinary action enacted upon yourself (i.e. Arbitration Committee sanctions and editing restrictions) or a history of abuse. You must have read, understood and agreed with the ACC guidelines. Your account on Wikipedia must be at least 6 months old and have at least 1500 edits. You have a solid grasp of Wikipedia's policies and guidelines, Wikimedia Foundation's privacy policy and show yourself to be a knowledgeable user. You need to be able to accept/acknowledge constructive criticism. You are allowed only one account in the tool and should not apply for more than one. You need to wait a reasonable amount of time before appealing an account decline or suspension decision. Also excessive appeal requests without taking enough time to properly consider and address the original deny reason will not be considered. You must connect your account to your Wikipedia account during signup. This list is not exhaustive, but are the primary reasons tool admins consider when looking at a request for an account. 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. If you previously requested to join ACC but were declined, please submit an appeal by emailing the tool administrators. Please do not create more than one ACC account for yourself. Connection to your Wikipedia account When registering for the ACC tool, you will be asked to connect your tool account to your Wikipedia account using the OAuth protocol, which gives the tool rights to perform certain actions on Wikipedia on your behalf. Currently, the connection is only used to gain a cryptographically signed identity ticket from Wikipedia verifying that you have control of an account on Wikipedia. You can see the information in the identity ticket from your tool preferences. All new users are required to connect their tool account to Wikipedia. Future updates to the tool may use more features of OAuth, at which point further permissions may be requested. You can manage the permissions available to the tool at Special:OAuthManageMyGrants.

See also

• Wikipedia:Request an account/Procedures
• Wikipedia:Technical restrictions on usernames
• Template:ACCbarnstar; the ACC barnstar!
• Template:ACC-access; welcome message for user's whose ACC accounts have been approved.