FAMEPedia:Request an account/Guide

The Account Creation Interface is an application software hosted on Miraheze Cloud VPS that is used to facilitate account creation requests on FAMEPedia. 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 FAMEPedia administrators (herein referred to as sysops). Most FAMEPedia sysops are not tool administrators.
 * 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 FAMEPedia 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: This list is not exhaustive, but are the primary reasons tool admins consider when looking at a request for an account.
 * You must sign the confidentiality agreement for access to nonpublic information per Miraheze 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 FAMEPedia must be at least 6 months old and have at least 1500 edits.
 * You have a solid grasp of FAMEPedia's policies and guidelines, Miraheze 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 FAMEPedia account during signup.

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 FAMEPedia account
The tool will prompt you to connect your tool account to your FAMEPedia account. This is done using the OAuth protocol, which gives the tool rights to perform certain actions on FAMEPedia on your behalf. This is primarily used to gain a cryptographically signed identity ticket from FAMEPedia verifying that you have control of an account on FAMEPedia. All tool users are required to connect their tool account to FAMEPedia, but the additional permissions are optional.

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

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

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



In the header of every page, there are a number of links:
 * Top links
 * Requests: returns you to the request queue
 * Meta:
 * Logs: shows recent activity
 * Users: shows all users with access to the tool, categorized by status
 * Search: allows a search of the ACC logs (not FAMEPedia's creation logs)
 * Statistics: shows statistics about the ACC tool and the users of the tool
 * Admin: (view only)
 * Ban Management: allows an admin to ban and shows all active bans
 * Close Email Management: which are sent to the requester when the request is closed
 * Welcome Template Management: which are posted to the requester new talk page after it is created
 * Site Notice Management: (admins view only) edit the site notice banner at the top of the page
 * User management: (admins view only) where interface users can be approved, blocked, promoted to admins or demoted to users
 * Job Queue: view the list of pending background jobs, including user creations and welcomes
 * Jump to request ID: Enter a number here to jump to a specific request
 * Your User Name: on the far right side – allows you to change your settings:
 * My Statistics: shows your statistics for tool activity
 * Edit Preferences: such as your email address, email signature, link account to FAMEPedia
 * Change password: Change your tool password
 * Configure multi-factor credentials: Configure two-factor authentication
 * Guide: Opens this guide
 * Username Policy: Links to FP:UPOL
 * Similar account flowchart: A basic flowchart showing how to handle similarly named accounts
 * Chat: Join

The IP Address links group contains the following links:
 * IP Address links
 * Talk Page links to the IP's talk page
 * Local Contributions links to the IP's contributions on FAMEPedia
 * Deleted Edits link to edit counter showing deleted edits
 * Global Contributions links to the IP's contributions across all Miraheze projects
 * Local Blocks Log links to the IP's block log on FAMEPedia
 * Active Local Blocks checks for any applicable current IP blocks on FAMEPedia
 * Global Blocks links to the IP's global block log on Meta
 * Active Global Blocks checks for any applicable current IP blocks or locally global blocks
 * Rangeblock finder checks for expired and current rangeblocks which apply to the IP
 * Whois runs a WHOIS on the IP
 * (alt) uses whois.domaintools.com instead of the Toolforge tool.
 * Abuse Filter Log shows all actions from the IP that tripped an Edit Filter

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 Cloud VPS), 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:
 * User name links
 * User page: A link to the user page of the requested account
 * Creation log: A link to check the creation logs of the requested account
 * SUL: A link to check the existence of the requested user name on other Miraheze projects
 * Special:CentralAuth: A link to MediaWiki's global user manager
 * Username list: A link to the user list to check for similar account names
 * FAMEPedia mainspace search: A link search FAMEPedia based on the requested account name
 * Google search: A link to Google, which searches occurrences of the requested account name on Google's search index

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 Miraheze 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 in "manual" mode: In an automatic mode ("Use my Miraheze account"), these two buttons are replaced with a single button ("Create and close as Created!") which creates the request in the background, and closes the request with the chosen message.
 * Account creation link
 * Create!: A link to create the requested account – which will open up FAMEPedia for you to actually create the account. See further instructions below at Guidelines for Closing Requests.
 * Created! if you were able to create the account. Note the arrow to the side which allows you to choose a more-specific template.

If more than one mode is available to you, you will see a set of radio buttons allowing you to choose the mode to use. If you have automatic welcoming enabled, you will see a switch to disable automatic welcoming for this request only.

The Request Status group contains the possible resolutions that can be given to a request:
 * Request Status
 * Decline if you are declining to create the account
 * Too Similar if it is too similar — see below for details
 * Taken (Standard) if the username was already taken (but if the username was created a very short while after the request — for example a few minutes after — then you can assume that it is the same user, and Drop the request instead)
 * UPolicy if the requested username violates the username policy
 * Invalid if it contains bad characters—such as  # / | [ ] { } < > @ % :, or double spaces between names. Do not use this for usernames with non-Latin characters as these are allowed. Also note that in some 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: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.
 * Taken (SUL Finalization) if the username is already a part of a SUL account.
 * 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
 * Open Proxy if the requester made the request from a known open proxy
 * Notable Person if the requested username appears to represent a notable person
 * Shared Username if you requested username violated Shared Username provision of Username policy
 * Block target – appeal if the request relates to the user wanting to appeal a block


 * Custom close the request and send a custom email to the user.
 * Defer if you were unable to complete the request and need to defer it to another queue
 * Defer to users often used by CheckUsers or admins to return the request to the normal user queue for further processing and checks
 * Defer to flagged users if a user with the accountcreator permission needs to handle the request
 * Defer to checkusers if the request needs to be checked by a checkuser before continuing
 * Defer to on hold places the request in a separate queue pending further information from the requester or admin
 * Defer to proxy check if the request needs to be checked by a user with proxy experience before continuing
 * Drop if the request is a bad request, or needs to be closed in a way which does not send an email to the requester. You should usually comment to ensure others know why you dropped a request. Sometimes a ban accompanies a drop, see below

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
 * One for banning the IP address.
 * One to ban the e-mail address.
 * One to ban the requested account name.

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:
 * Access
 * Count — Checks the edit count of users needing approval.
 * Approve — This allows newly registered users to log in and use the interface.
 * Decline — This declines a request from a newly registered user, preventing them from logging in and using the interface.
 * Rename — Rename a user's interface account.
 * Edit — Edit a user's email address and on-wiki username.
 * Edit roles — Edits the roles granted to a user, such as whether or not they are a tool administrator.
 * Suspend — The equivalent of a block on FAMEPedia. It is issued by a tool administrator and prevents the target user from logging in.
 * Unsuspend — The equivalent of unblocking someone. Undoes suspension and allows the user to resume using the interface.

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.
 * Welcome template management

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. If you need to collaborate with another user on a request, you can use the link titled "reveal to others" to allow other tool users to see the data on the request without needing a reservation.
 * Request reservation

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.

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

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

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 #FAMEPedia-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.

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 FAMEPedia'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.
 * For IP addresses that are globally hard (not anon. only) blocked (regardless of single IP or rangeblocks), you should defer the requests to Stewards 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, 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 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 Miraheze's privacy and data retention policies). See 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 who create accounts from requests that are in such cases and without consulting a CheckUser risk account 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 ( is in the IP's block log summary).
 * If the IP is blocked as or  or blocked for simple vandalism, refer to, unless the block was placed with a CheckUser Block note in the block log.
 * 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 or  or blocked for simple vandalism, refer to, unless the block was placed with a CheckUser Block note in the block log.
 * 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 or, 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 ( 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 or. 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 FP: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.

Requests stating that editing via a VPN is necessary should be referred to FP:IPECPROXY.

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 similiar 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 FAMEPedia'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 FAMEPedia'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 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 FAMEPedia 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 OTRS to deal with.

Once OTRS 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 OTRS ticket number provided as a request comment, or by the requester sending in a new request and including the OTRS ticket number in the request comment. However, the request must not be handled until someone with OTRS access has verified in the request comments that the OTRS ticket contains sufficient proof of the requester's identity and is tied to the ACC request (if you have OTRS 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 OTRS ticket match). 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. If you create the account successfully and are an OTRS user too, add the OTRS identity template to the top of the new user's talk page, including the OTRS ticket number tied to the ACC request. If you are not an OTRS user but still created the account, please as soon as possible ask an OTRS user to add the OTRS identity template to the new user's talk page – possible venues for making this request include the OTRS Noticeboard, on IRC, or contacting an OTRS user you know directly. Remember to include the name of the user you just created and the relevant OTRS ticket number in such a request!

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

Current ACC users with OTRS access
~riley · Alex Noble · AmandaNP · AntiCompositeNumber · Blablubbs · Dane · DannyS712 · ElHef · GW · JJMC89 · KrakatoaKatie · L235 · LuK3 · Matthewrbowker · Mdaniels5757 · Operator873 · Oshwah · Ponyo

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 FP: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 FAMEPedia'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 FP:ISU as well as takes the opportunity to link them to FP:COI, FP:PROMO and more relevant policies or guidelines.

Username conflict procedures
FAMEPedia 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 FAMEPedia (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 Miraheze Projects instead of simply creating a local login to one Miraheze 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 ~ to the end in order to make them unique across all Miraheze 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 FAMEPedia. 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 accounts are determined to be both unestablished and inactive. Similar existing accounts are considered "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 FAMEPedia, 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 FAMEPedia, 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 FAMEPedia logs over one (1) year ago.


 * If the similar account has made fifteen (15) or more contributions to FAMEPedia:
 * 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.

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 flow. If you are unsure, contact a tool admin or place the request in the Steward queue.

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.

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. FP:BPCA, FP:PSCOI, and FP: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 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 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,.
 * 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
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. 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 FAMEPedia 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.