Wikipedia:Request an account/Guide
| This is the request an account guide | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
The Account Creation Interface is an application software hosted on Wikimedia Labs 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.
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. After you have addressed all the concerns in the email, you can reapply for access to ACC by sending an appeal email to the tool administrators. Your appeal should address all the concerns raised in the email explaining the reasons for your denial from ACC. Please do not create more than one ACC account for yourself.
Notes, terminology, and requirements
- Interface administrators (herein referred to as tool administrators or administrators) are not the same as Wikipedia administrators (herein referred to as sysops). Most Wikipedia sysops are not tool administrators.
- Tool accounts that have not been logged into for 45 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 for using the interface
To qualify as an ACC user, you must meet the following minimum requirements:
- You must be identified to the Wikimedia Foundation. Please complete the identification process and ensure that you are listed on the Identification Noticeboard before requesting access to ACC. Submitting a request to join ACC before you are listed on the Identification 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.)[note 1]
- You need a valid email address that you actively watch. (Signup: here) Tool policy change notices are sent out this way, and you are responsible for keeping up with them. [note 2]
- 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[note 3]
- 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.[note 4]
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
A relatively new feature of the tool is the ability to connect your tool account to your Wikipedia account. This is done 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, and existing users are strongly encouraged to do so. 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.
Interface documentation
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 marks 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.
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.
Buttons on the interface and what they do
|
|---|
In the header of every page, there are a number of links:
The IP Address links group contains the following links:
This section could take three forms, just a plain list of links if the request was made directly to the tool (almost never the case on the on Labs), or it could have come via a proxy or a set of proxies. For more information on how to interpret these, see this page.
The User name links group contains the following:
You should also check the username. Remember to keep username policy in mind when reviewing a name. Always do a Google search to see if it is the name of a company or organization, which may be considered promotional, indicate a conflict of interest and a violation of Username Policy. If the name is ambiguous, then you should take where the requester's IP Address geolocates to in relation to the relevant company, the requester's email address and the requester's comment into consideration. It is also important to check whether the requested username made any contributions on other Wikimedia Projects. This way you could see whether the requested name forms part of a global account or unified login — if so the account should not be created. When you are pleased with the request you can click the Create! link to create the account.
The Account creation link group contains the following:
The Request Status group contains the possible resolutions that can be given to a request:
bugs in the tool may replace certain non-Latin characters in a username with invalid characters when filling in the username field on Special:Userlogin. In such cases it is recommended that you attempt to manually copy and paste the name as it appears in the ACC interface into the username field.
The SUL Taken option should be used when the requested name is part of a unified login—such as described in the previous section. If the username is similar to that of somebody on another wiki then the Similar option should be used, and if the username is the same as somebody on another wiki then Taken should be used. When none of the above options describes the particular situation, you should use the Custom option. You would then be prompted for a custom email message that would be sent to the requester. The message you write will form the entire content of the email to the user; don't forget to sign your message with an adequate name. Note: All of these links perform an action on the request and do not link to the relevant policy. All resolutions except the Defer and Drop resolutions send an e-mail to the requester indicating what has happened to the request. If the request was already closed or deferred to account creators, then the Defer to account creators link becomes Defer to users, which returns it to the main queue.
The ban links is only available to the tool administrators and contains the following three ban links:
Ban links can be found in a separate section beneath "Request status" on the zoom page of a request or in the form of a dropdown button on the main interface beside requests in the request queue. Alternatively, tool admins can ban users and review the active ban list on the ban management page.
 Tool administrators can change other users' access to the interface via User management. Available options—which vary based on the target user's status, are as follows:
Before adding a template, please check that it takes a signature as a parameter, or not at all. This is to prevent the bot signing as itself, rather than the person who created the account. Also, please add the template to the list here, so should the template appear at TfD or something and gets deleted, such as what happened here, it is actually shown as used.
To alert to other users that a request is already being handled, you must reserve a request to see the full request (unless a tool admin). The tool will not allow you to handle a request which has been reserved by another user and will warn users if they attempt to reserve more than one request. Requests will be automatically unreserved when you close them, however, closed requests can be reserved. All currently reserved requests will show up on one of the statistics pages, accessible by clicking the Statistics link at the top of the page. |
General rules and policies when using the tool
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 [1]
- 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 do violate this rule, risk indefinite suspension, and possibility of their identified status being revoked. See this email for more information.
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.
Script usage
Using a script or other program to automatically handle requests in any way (includes reserving) is not taken lightly and will probably result in account suspension. Using an automated refresher, however, is generally OK, as long as the refresh time is considerate to the instance's resources (at most once a minute). Remember there is a live feed of requests on IRC, this may be a better place to watch than the interface.
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 rangeblock:
- 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 CheckUser-related reasons for the block, you must defer the request to CheckUsers.
- For non CheckUser-released blocks, refer to IP range blocks and Single IP blocks for further instructions.
- 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, 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 schoolblock).
Do not violate policy by release personally identifying information in a comment. See § Personally identifying information for more information.
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. If there is any rangeblock on the requesting IP (or any indication of sockpuppetry), defer the request to CheckUsers. Users creating accounts in such cases without consulting a CheckUser, may result in suspension.
Exceptions to this policy:
- You placed the block yourself, and you are sure the requester is not the block target.
- The rangeblock is placed on an Opera Mini IP range, and solely because of the fact that it is an Opera Mini IP range.
- Blocks that expressly ask ACC users to ignore the block (<!--- ACC Ignore. ---> is in the IP's block log summary).
- If the IP is blocked as
{{schoolblock}}or{{anonblock}}or blocked for simple vandalism, refer to § Simple vandalism and school blocks. - Blocks that do not have the "account creation disabled" parameter set.
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).
- If the IP is blocked as
{{schoolblock}}or{{anonblock}}or blocked for simple vandalism, refer to § Simple vandalism and school blocks. - If you have a request that you are going to decline or drop due to a single IP block, you need either:
- 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
- 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 CU, even if it's already been there.
Exemptions
The following are exemptions to the rules regarding deferring requests with blocks to CheckUsers:
Any rangeblock (affecting any kind of IP address) can be ignored only if any of the following are true:
- 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). - 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)
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 {{schoolblock}}. The fact that a blocked IP belongs to a school is not in itself an exemption.
In these cases, the request is likely due to a block that was not caused by the requester, and WP:AGF would apply. Otherwise, defer to CheckUsers.
Open or anonymizing proxies, web hosts, or Tor exit nodes
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. If the request's IP is confirmed to be an open proxy, the request should be closed as "Open Proxy". If there is anything in the block reason or which comes up in other checks and suggests sockpuppetry it must be deferred to CheckUsers instead.
If there is strong reason to believe that the IP is no longer an open proxy or web host a request should be made at WP:OP for the IP to be checked. Before making a request at WP:OP you should seek advice from an experienced ACC team member. Be extremely careful not to link the request (or any other information which could result in an IP to ACC Request or Username) at WP:OP to the ACC request as this would breach our privacy requirements and may get you suspended.
Username policy procedures
All username requests must follow Wikipedia's Username Policy. Please refer to this guideline for any policies and procedures that are not explicitly defined here.
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 OTRS 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) then to send it to OTRS to deal with.
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 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, or
- B. too similar to an existing local account.
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")
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 user name requests that are flagged as similar can be created only if the similar existing account is inactive. Similar existing accounts are considered 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 less 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 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 active regardless of the date of the account's creation, last contribution, or log entry.
If a similar existing account fails any of the requirements above, then the similar existing account is active. ACC requests with similar existing accounts that are active must be declined. Decline the request and use the Too Similar close email template. If the similar existing account(s) are inactive, you can go ahead and create 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 similarity(ies) between the requested account and existing similar account(s), and thus allow the requested account to be created.
Guidelines for closing requests
General notes
- When requester's 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:Userlogin, type in the username and click Email new password. This will reveal your IP to the requester, so try to avoid doing this. 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
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 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 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 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.
Tool administrators
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 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. You can see the current development team on this page.
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 Labs 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 having 'checkuser' rights, detected by OAuth.
If there is an urgent need to find an active CheckUser, consult IRC or this tool to see who has recently been active.
Notes
- ^ Anything longer than a couple of weeks probably merits a longer gap — longer blocks generally indicate more serious abuse.
- ^ The mailing list is where users requesting accounts from ACC often send emails when they need help, and it is also one of the primary discussion mediums for ACC (the other being the #wikipedia-en-accounts IRC channel.)
- ^ 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.
- ^ 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.
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.
- ^ See exception for § Open or anonymizing proxies, web hosts, or Tor exit nodes.