Wikipedia talk:Request an account/Archive 5

Addihockey's account creator proposal at VPP

see proposal at Wikipedia:Village pump (proposals)#ACC_e-mail feature. mabdul 00:26, 15 January 2012 (UTC)

request

hi

i want to ask you guys somthing

i creat an account befor maybe 5 or 6 months "i think " anyway i would like to creat a new account and remmber that i have another account .

please give me clear answer ,thakkkkkkkkkkkkkkksssssss

please help guys and thank you — Preceding unsigned comment added by 79.179.170.235 (talk) 18:59, 27 February 2012 (UTC)

yes you are allowed to create a new account as described here WP:CLEANSTART as long as you only use one of your accounts. Regards, mabdul 19:55, 27 February 2012 (UTC)

Hi

thank you but i need to tell me how to do a new account or at least a link ...

thanksssssssssssssssssss help pleaseeeeeeeeeeeeeeeeeeeee — Preceding unsigned comment added by 79.179.170.235 (talk) 20:19, 27 February 2012 (UTC)

Proposal - complete unified login for all eligible accounts

FYI

 – copied from Wikipedia:Village pump (proposals), mabdul 20:30, 27 February 2012 (UTC)

I have created a proposal at Meta, to complete unified login for all eligible accounts. Unified login is a relatively new feature to the WMF wikis, allowing each user to have a single combined account in every project. Users that only have an account on one wiki would extend that to all wikis, and users that already have accounts on multiple wikis would have them combined. It was initially an opt-in for existing users, but it is now done by default for all new users. This leaves us with three groups of users: those with UL, those that cannot complete UL because of a naming conflict on another wiki, and those with no conflict that have simply not completed the process. I am proposing that account unification be completed for all eligible accounts without requiring the user to take any additional steps. This would make UL the rule rather than the exception that it currently is, and bring us closer to the goals of universal watchlists, recent changes, interwiki page moves, etc. This would be especially helpful on Commons, which has so many images that were originally uploaded at another WMF wiki, enabling better attribution without interwiki links. I propose that it be carried out as a one-time process rather than a continuous automatic software process, allowing users to still adjust ULs as they see fit.

If you have any opinion one way or the other, please reply at the proposal at Meta. ▫ JohnnyMrNinja 01:01, 23 February 2012 (UTC)

Account Request extension, revisited

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hey guys. I've been speaking with Sumana Harihareswara, Brandon Harris and a couple of other WMF people about the ConfirmAccount extension, which was formally requested four years ago following a discussion here on enwiki. For those of you who weren't in the original discussion; ConfirmAccount is a MediaWiki extension that creates a new process for account creation, in which accounts are requested and authorised by someone with a specific user-right rather than merely created through the registration scheme. This is most useful in situations where the "normal" registration process doesn't work - for instance, when CAPTCHA issues make it difficult to fill out our standard form. This may sound similar to the Account Creation interface currently hosted on the Toolserver. In fact, the idea is that this extension would completely replace it, moving ACC functionality "in house" and clearing up the need to go off-site to use it.

Nothing was done at the time because of a dearth of developer time, and soon after, the ACC system on the toolserver was developed, which removed much of the need for this extension. However, it has been mentioned that:

with the current setup at [the toolserver] there is an external server dependency, an entirely separate user interface, a separate user auth and permissions system, and the possibility for unwittingly leaked data like IP addresses of users requesting accounts. This is undesirable and unacceptable.

Putting in the ConfirmAccount extension would completely clear up these issues, if they exist. However, we still (and probably forever will) have less developer time than we do things to do. The consensus reached in 2008 is now stale, and we need to know, broadly-speaking, if there is a strong feeling in the community that this extension should be enabled. We don't want to waste our time reviewing code for something that isn't wanted, when we could be working on other, necessary bugfixes that improve the editing and reading experience :).

So, TL;DR: I would be very grateful if people could indicate, in the sections below, whether they think this is necessary. If so, we can prioritise switching it on: if not, we won't. It is worth noting that the need to identify to the Wikimedia Foundation will still apply, and we will have to create a new user group; I imagine the process will work along the lines of "a user requests the permission, submits identification to the WMF, the WMF confirms the identity, a bureaucrat gives the user the appropriate user group status". Obviously, there's no reason that people who already use ACC and have identified shouldn't get this new right automatically. Okeyes (WMF) (talk) 12:58, 12 April 2012 (UTC)

Want the extension

1. tools:~acc is a bad hack. Most of the original authors later agreed with this. One or two were even granted commit access to MediaWiki's code repo to work on an extension to replace it. The tool is an unnecessary external server dependency, it has separate user authentication, it has data storage and management issues (IP addresses, e-mail addresses, and whatever other personal info gets input), etc. It's also become a mini-bureaucracy within Wikipedia. It should be in an extension. --MZMcBride (talk) 13:32, 12 April 2012 (UTC)

   Replied to this comment below. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)

2. An extension that does the exact same thing as the current system is already a big improvement because it does not have the disadvantages that the current system has. If we (as a community) send good feature requests to the developers it will be an ever bigger improvement. Von Restorff (talk) 13:34, 12 April 2012 (UTC)

   The proposed extension does not do the exact same thing as the current system, not really even all that close. It is more like stripping away every check and giving out accounts just because someone asks - who cares if they have a block or are banned or are a company looking to advertise or if the name conflicts with an account in FR and DE and IT languages, or if it is their 17th request of the day. delirious & lost ☯ ^~hugs~ 15:21, 12 April 2012 (UTC)

3. I used the toolserver version which was a lot better than the way the process used to be (mailing list, wiki page). The extension is overdue and would it would just make more sense now to have it built-in. Rjd0060 (talk) 16:23, 12 April 2012 (UTC)

Do not want the extension

1. I gather the resources that go towards ACC development do not overlap with the resources that go towards MediaWiki coding given one is Toolserver-based and the other is not. As long as the ACC developers are willing to continue to maintain it, we can avoid hitting up our more limited MW developing resources. The security/privacy risk is a concern, but the Foundation seems fine with it. MBisanz ^talk 13:35, 12 April 2012 (UTC)

   Re privacy, everyone with access to IP and email data on the current tool is identified to WMF and is supervised minute-by-minute by tool admins on IRC.   — Jeff G. ツ (talk) 04:01, 13 April 2012 (UTC)

2. Very very hesitant and opposed right now to switch. I've worked with the ConfirmAccounts extension offwiki, and it's not anywhere close to what ACC is. You can't leave comments, it's a one reviewer system (which is the same problem that came up on unblock-en-l), I don't remember much of a log of actions for this. Also the requested info on the extension by default contains very limited use for us. I basically want to see a good plan on this and a coding change before I support any MW extension on this. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)
3. The extension that is proposed is fundamentally useless for the objectives it is seeking to serve. Simon listed off many things that would need to be changed before he would support anything of this sort. I would simplify it to say that THIS EXTENSION is a NO, a new extension is a possibility. If we don't know that it is a person's 3rd or 23rd request for an account in a day (or ever) then there is no reason to refuse. If we don't get IP data then how would we know a person is not simply bouncing between hotmail yahoo gmail and a few others making multiple requests for accounts. If IP data is not available then we have no idea if there is a block in place and if there is a pattern of abusive behaviour existent from (possibly) the person now asking for an account. If the CU at ACC didn't have UA access they wouldn't be able to tell if the person who is the cause for a range block is now asking for an account.
   What MZM and Okeyes are pushing here is an extension that is a simple 'can i have an account? yes/no' and with no reason to say 'no' we would be compelled to create new accounts for community banned users, people wanting dozens of accounts to screw around with, and people who genuinely are having issues with the captcha. But we wouldn't have any idea who is who.
   A bad hack that works is better than a non-hack that is useless; revive when you have a useful extension to propose. delirious & lost ☯ ^~hugs~ 15:21, 12 April 2012 (UTC)

   Deliriousandlost, I'm not "pushing this" at all. I have no opinion either way; I was asked to gather more information on what the community felt, and have done so. Okeyes (WMF) (talk) 15:27, 12 April 2012 (UTC)

   I'm curious why such a bureaucracy has built up around account creation requests. Can you elaborate a bit further about this? I imagine there must be a reason. For example, you mention the ability of (bad) users to bounce between Hotmail and Gmail accounts, etc. as though it isn't possible for nearly any user to create a many accounts as they please right now at Special:UserLogin. It was my understanding that the original purpose of account creation requests was mostly as a means of bypassing the CAPTCHA (for users with disabilities) and others who had been wrongly blocked from account creation based on their IP. There are undoubtedly improvements needed to the current extension, but what about this whole process requires more than a simple yes/no interface for account approvals? --MZMcBride (talk) 16:44, 12 April 2012 (UTC)

   We have some very creative vandals. Once blocked, they have been known to try to create many accounts from one IP with one email address, from one IP with different email address, from different proxy IPs with the same email address, from different proxy IPs with different email addresses, with names similar to or identical to names on other projects and SUL, and/or promoting their websites and other globally unique intellectual property. Sadly, proxy IPs above include all AOL customers.   — Jeff G. ツ (talk) 18:22, 12 April 2012 (UTC)

   I am curious why you have such a fundamental hatred of the toolserver and why you persist until you get your way. This was a dead issue 3 years ago and you didn't like it so you re-opened it 19 months later and waited for someone to notice.
   Mostly it is to help those who have issue with the captcha but it also serves as a means to ask if a user name that someone isn't sure about would be acceptable. Victims of range blocks do come up fairly often. With restricting IP data we would be able to do shit all about it when they would come up. Occasionally the email address will hit on another request or 3 and unless you think giving someone a 4th account is a good idea then knowing is better than not. You are correct that someone can game the system in the short term by simply creating a few accounts each day for themselves. But doing so for themselves will associate those accounts with the IP address they use to create them. And they will get caught fairly easily. Not as many people think to have someone else create those collections of accounts for them but when they do try it it is nicer to catch it early rather than find oneself subject to a CU investigation because subsequent behaviour of seven accounts one created has linked them together and to you as their creator. And if those 7 accounts were created by 7 different people at ACC who had no means of knowing of any connexion betwixt them then there is the ultimate gaming of the system: various other people from a multitude of IP addresses creating a collection of accounts to be used in the long term for abusive purposes and no way to link them until the abusive behaviour was committed and no way of knowing just how many times we had been fooled. To go back to an earlier point, the causes for range blocks do tend to try to bypass them once in a while hoping we consider them simply another innocent victim. Since the range blocks are anonymous only if they can get an account from us they have succeeded in bypassing their own block. For that reason we have a few CU who have access to the UA data of the requests. If you are in favour of blocked users bypassing their blocks so easily and being puppets ourselves in helping people collect dozens of accounts then we could simply ignore all of that and grant accounts based on how we feel. Which seems to be what you want.
   Then there are the schools which have classes involving Wikipedia and say there are 20 students in the class and 18 haven't already got accounts then after 6 create an account for themselves the other 12 are left waiting for another day or two. Sometimes we get advance notice and sometimes we look at the requests and assess it as such a situation.
   If you hadn't walked away from it four years ago you might have some more understanding of what is done today at ACC. But hey, you gamed the bugzilla system in getting this all going again so congrats for being proof how easily manipulated things can be and for why the checks are a good thing. At least you were honest about it being you who was doing it. delirious & lost ☯ ^~hugs~ 18:25, 12 April 2012 (UTC)

   Yes, I hate the Toolserver so much I have an account there with a number of active bots and tools. Your post is riddled with such a mountain of factual inaccuracies and general nastiness that it simply isn't worth my time to reply to it in full.

   I've come across you a few times previously and I always considered you rather sensible and clueful. This reply of yours is simply shameful. :-( --MZMcBride (talk) 18:31, 12 April 2012 (UTC)

   No. Except for her opening and closing statements (which I won't comment on) she is actually quite right with several of the things that go on with ACC. If you take the time to actually look at it, then maybe we can get some where positive. -- DQ (ʞlɐʇ) 22:36, 12 April 2012 (UTC)

4. I don't want to repeat what others have already said, but, basically, the ACC interface works. It allows an account creator to run various checks to make sure he's not helping a wannabe spammer or a banned user trying to evade his sanction. That's why unless and until this interface allows for such checks, I'll oppose implementing it. Salvio ^{Let's talk about it!} 16:36, 12 April 2012 (UTC)

   What checks does Special:UserLogin provide against such bad users? Or put another way, how stupid would a wannabe spammer or banned user have to be to use the account creation tool rather than making their own account through the standard built-in form? --MZMcBride (talk) 16:53, 12 April 2012 (UTC)

   Per the lede at Wikipedia:Request an account, "In most cases, users can create accounts without assistance. However, where problems arise (such as with the CAPTCHA image or the desired username), users may request an account be created for them." Thus, Special:UserLogin only checks for CAPTCHA and similar/existing local usernames.   — Jeff G. ツ (talk) 18:11, 12 April 2012 (UTC)

   Special:UserLogin will note the IP addy used in creating the account though it doesn't display it. You make 6 that way and all 6 are easily linked. Create 6 more tomorrow from a different IP and those 6 are linked. Eventually the combination of the behaviours from the accounts will link them all together. But if you can get someone else or 3 other people to make those accounts for you it scrambles a bit of the association and makes linking them based on behaviour less likely. If they don't know of how easily caught they would be some do think going through ACC is the best way to get three dozen unassociated accounts which they can use to disrupt things for months to come. When they get caught on the second request most back off. There are ways to game ACC today but i don't think publicly going on record about how to do it would be a good thing. delirious & lost ☯ ^~hugs~ 18:25, 12 April 2012 (UTC)

5. I am opposed per all of the above in this section. The following links and checking functionality in the tool on the toolserver (as borrowed from Wikipedia:Request an account/Guide#IP_Address_links) would be lost:
   • Talk Page links to the IP's talk page (helps guard against vandals and block evaders)
   • Local Contributions links to the IP's contributions on the English Wikipedia (helps identify vandals and block evaders)
   • Deleted Edits link to edit counter showing deleted edits (helps guard against page creation vandals)
   • Global Contributions links to the IP's contributions across all Wikimedia projects (helps guard against vandals and block evaders from other projects)
   • Local Blocks links to the IP's block log on the English Wikipedia (helps guard against vandals and block evaders)
   • Local Range Blocks checks for any applicable IP-range blocks on the English Wikipedia (helps guard against vandals and block evaders)
   • Global Blocks links to the IP's global block log on Meta (helps guard against vandals and block evaders)
   • Global Range Blocks checks for any applicable global IP-range blocks or locally disabled global blocks (helps guard against vandals and block evaders)
   • Whois runs a WHOIS on the IP (helps guard against physical location and domain COI via correllation with Google results)
   • Geolocate Geolocates the IP (helps guard against physical location COI via correllation with Google results)
   • Abuse Filter Log shows all actions from the IP that tripped an Edit Filter (helps guard against vandals and block evaders)

   Also lost would be the granularity of the tool's responses to the requester, which currently include "Created! | Similar | Taken | SUL Taken | UPolicy | Invalid | Password Reset | Custom | Drop", as well as the specialization hierarchy of Users, Flagged Users, and Checkusers, the creation history for the IP and the email address, comments, IRC discussion, and mailing list discussion. I shall remain opposed until a proposed extension or other on-wiki fix has similar safeguards.   — Jeff G. ツ (talk) 17:24, 12 April 2012 (UTC)

   You're opposing because of the lack of a link toolbar? Do you understand that would take maybe a minute to re-create in the extension? --MZMcBride (talk) 17:41, 12 April 2012 (UTC)

   Not just the link toolbar, I just elaborated above.   — Jeff G. ツ (talk) 17:53, 12 April 2012 (UTC)

6. No thank you. ACC is a great system for many reasons mentioned above. ConfirmAccount is a great tool for small projects (I use it on mine) but, this is only because I don't need such a system in place, Also can you imagine the backlog this would create, Now not just the requests that are having problems creating an account but, now "All" new accounts would require review ? and if not then why break something that's working ? Mlpearc (powwow) 17:43, 12 April 2012 (UTC)

   Where did you get the idea that all new accounts would go through this process? Only a very limited number of accounts should be going through any supplemental account creation process (in an extension or on the Toolserver or anywhere). Most users should be creating their own accounts. --MZMcBride (talk) 17:47, 12 April 2012 (UTC)

   I'm sorry then, If all account creations are not going to go through ConfirmAccount (This is what this extension is used for) then why are we even talking about changing to it ? Mlpearc (powwow) 21:08, 12 April 2012 (UTC)

7. Oppose - we want to make it easier for good-faith editors to register, not harder. I'd support it if the extension were modified to only affect blocked users.--Jasper Deng (talk) 17:53, 12 April 2012 (UTC)

   Sorry, I'm not following this comment at all. What about this extension do you think makes it more difficult to register for an account? This is not intended as a replacement for the built-in registration form at Special:UserLogin, you realize? --MZMcBride (talk) 18:00, 12 April 2012 (UTC)

   I've seen this extension used before. Do you even know how this extension works? It explicitly asks for the disabling of anonymous account creation - the extension is intended to replace Special:UserLogin, and as a matter of fact it does. When I registered, I liked the fact that I was able to use my account immediately. This would be a waste of time for good-faith editors.--Jasper Deng (talk) 18:07, 12 April 2012 (UTC)

   Why do you believe the previous uses you've seen would match what's used here? As the documentation notes, you can re-enable account creation for all users using $wgGroupPermissions, which of course would be done here. I'm still not following your line of reasoning at all. --MZMcBride (talk) 18:12, 12 April 2012 (UTC)

   Huh? That would completely defeat the purpose of this extension. The point about the ACC process is to help blocked users, and I know there is a setting to allow blocked users, but I find it pointless to try something intermediate between normal account creation and fully requested creation because the extension isn't designed for that.--Jasper Deng (talk) 18:16, 12 April 2012 (UTC)

   The idea is to move the tools:~acc process back in-house, which has a number of benefits. You seem to have ignored those benefits in favor of railing against using an extension in a way you simply don't like. :-/ --MZMcBride (talk) 18:18, 12 April 2012 (UTC)

   ...and this extension won't do that. I know there are a number of benefits, but I cannot support the extension in its current form because it does not serve ACC's purpose of only doing requests for blocked users.--Jasper Deng (talk) 18:23, 12 April 2012 (UTC)

   "ACC's purpose of only doing requests for blocked users"? What are you talking about? I believe ACC serves more than just blocked users. Did you really intend to use "only" there? --MZMcBride (talk) 18:25, 12 April 2012 (UTC)

   Then why else would we have such a process? Legitimate users who aren't blocked (including on the IP level) can simply use Special:UserLogin without a hitch. If they have problems with CAPTCHA, they can also request, but I feel that we don't have a big enough audience to warrant that.--Jasper Deng (talk) 18:27, 12 April 2012 (UTC)

   AntiSpoof, TitleBlacklist, and ConfirmEdit are three exaples besides being blocked. [stwalkerster|talk] 18:31, 12 April 2012 (UTC)

8. So far, the arguments hold against the existing Toolserver ACC page, but not for converting to the CreateAccount extension. CreateAccount is not an on-wiki equivalent to ACC, but outdated and unsuited to our needs. In my view, only an extension (based or not on CreateAccount) that has all of ACC's features could be acceptable. AGK [•] 23:58, 12 April 2012 (UTC)
9. Not just now. While it would be a great advantage to move all this back onto Wikipedia and off the Toolserver - especially considering the Toolserver is about as reliable as a rock is soft lately - for the security of the site as well as the benefit of the requesting users, we need at least all of the functionality provided by ACC to be provided by this extension. Namely the email address (at least the domain, as in UTRS - this will indicate if it's a business address), useragent, IP address, links to other requests from the same IP and/or email, ability to discuss requests with other reviewers, etc. and so forth and on and on. With this information, we can prevent most of the sneakier sockpuppeteers from getting more accounts, and counsel editors with potential conflicts of interests regarding relevant guidelines and policies before they edit and risk getting blocked for spamming. Once it's clear that this functionality is available, I'd be all for adding an extension such as this. Hersfold ^(t/a/c) 00:07, 13 April 2012 (UTC)
10. Oppose - CA was designed for (a) standard smallish MediaWiki installs that have trouble dealing with spam accounts and (b) Citizendium. It would take a lot of work to get this polished and in to shape for this use case. We can't afford to take staff time on this. There is way more work that people as is. If toolserver volunteers are doing a decent job separately, then we can, and should, continue make use of that work. I'm not *terribly* worried about toolserver and privacy, though it's not ideal at the moment. Aaron Schulz 02:45, 13 April 2012 (UTC)

Discussion

• Good idea. Von Restorff (talk) 13:28, 12 April 2012 (UTC)

  Could you indicate how good/bad by elucidating or !voting? :). Okeyes (WMF) (talk) 13:29, 12 April 2012 (UTC)

• Of course. The toolserver workaround has major disadvantages (insecure, offsite, separate user auth and permissions system et cetera). We've used this dirty hack for a long time already. Let's fix it. Von Restorff (talk) 13:51, 12 April 2012 (UTC)

• It would be good to get it back onto Wikipedia, however before indicating my personal preference, I'd want to be sure that the extension was capable of performing as we would want it to. (I've not had chance to look at the extension specifically yet.) We'd want some way of at least the following: a) seeing the email address of a request (for cases such as marketing@somecompany.com ), b) seeing the IP address to check contribs/block log/etc, c) checkusers seeing the useragent, d) being able to check against the results of antispoof and titleblacklist, e) being able to close requests with different messages (upol, too similar, etc), f) make notes on different requests for internal use, g) a log of all actions, h) some way of marking a request as being dealt with. There's probably more, but that's what I can think of offhand. Without this, there is a strong possibility that accounts for known blocked malicious users would be created accidentally, and would be a step backwards. The current system is a bad hack, yes, but it's worked so far, and hasn't caused any major issues. [stwalkerster|talk] 13:56, 12 April 2012 (UTC)

  Good points :). I'll try and find out. Okeyes (WMF) (talk) 14:18, 12 April 2012 (UTC)

  Stwalkerster: I asked deliriousandlost this above, but regarding an example such as marketing@somecompany.com, wouldn't we presume that most such accounts are simply created through the standard Special:UserLogin form? I'm not sure why this extension is being held to such a high standard when it's really meant as a tool of last resort, isn't it? Most people should be creating their own accounts (and can do so with any kind of e-mail address they want—or none at all). Can you clarify what you view as the purpose of the account creation process? --MZMcBride (talk) 16:49, 12 April 2012 (UTC)

  To continue the example, spammy accounts are created as normal, but should a problem user spam enough to get the IP blocked (likely an autoblock), and we then get a request for an OK username from that IP, what's to say we aren't just creating an account for the spammy user? If it's a yes/no thing, then we're all but negating the affect of disallowing account creation on the Special:BlockIP in some cases. It's a tool of last resort, yes, but these data (read: these features) are needed, otherwise it's just going to cause more problems than it solves. At no point should we be directing users to ACC before directing them to Special:UserLogin/signup, but iff they are unable to create an account (for whatever reason, be it accessibility, technical issues, or otherwise), then they can come to ACC. It also gives us a chance to give a user a bit more of a helping hand with any possible issues that we may spot before they start even editing ("I just want to put my bio up" => mention N/COI etc), especially since they'd have (theoretically) had to jump through hoops already to even get an account. [stwalkerster|talk] 18:13, 12 April 2012 (UTC)

• It sounds like this request and what the extension actually do are different. Are we wanting to convert the old tool hack to an on-site method, or are we removing autonomy from non-account holders so that all accounts must go through this system? –meiskam (talk•contrib) 14:42, 12 April 2012 (UTC)

  The former; the extension would be implemented in parallel to the existing registration process, rather than to replace it. Okeyes (WMF) (talk) 14:52, 12 April 2012 (UTC)

• I have no idea what the extension capable of, If extension has all the features which ACC has, then I support extension or we can have both and see which suits better. But ACC is just awesome, thanks to Simon and Team. It would be a loss if we don't use anymore, I am sure most of them have sacrificed lots of time to built it. -- ɑηsuмaη ^{ʈ ᶏ ɭ Ϟ} 12:25, 13 April 2012 (UTC)

User rights

I have no strong opinion on the merits of this, but I do wish to register an issue which I've discussed with Okeyes off-wiki. Currently, there is an account creator user group, which is granted to non-admins who are active in the ACC process. Those with the account creator flag, and admins, are exempt from the new account limit (six, if I recall correctly). The ACC process, or the ConfirmAccount process if we do decide to switch, gives users access to non-public information, and they need to identify to the Wikimedia Foundation in order to get access to said information: you have to do this already to get access to ACC. Now, if this were brought back on-wiki, a user group would probably have to be used to specify users who can have access to the private information held in the ConfirmAccount system. This is where it gets slightly complex. I see a number of possible options:

1. A new user group could be created for "account confirmers" (or some better name), which would basically be anyone who currently has access to ACC. Account confirmers have access to the ConfirmAccount tool.
2. The existing user group, account creator, is co-opted and anyone who is a member of account creator can access the tool. Admins who are interested in doing ConfirmAccount work simply request this user right after identifying with the Foundation.

The latter of these two options is obviously simpler, but I would argue that whatever we decide, we need to allow admins that do not have the account creator flag, and are not active in ACC/ConfirmAccount and are not identified to the Foundation, to continue being able to create accounts without the daily IP limit. There is a clear and simple need for it in outreach work: editathons, GLAM etc. If you are introducing a roomful of new people to editing Wikipedia, often you need to be able to create lots of accounts for them all, and this is something admins can do without hitting the IP limit.

If ConfirmAccount means that admins who haven't identified and aren't active in ACC cannot create new accounts, I'd suggest that wider consultation with both the admin community and the wider Wikipedia community might be necessary. Changes to what admins expect to be able to do may have unforeseen consequences: for instance, do we know whether OTRSers create accounts? How about people who help on #wikipedia-en-help? What about campus ambassadors in the various education programs? I'd suggest whatever we do with ConfirmAccount, don't change the status quo of exemption from account creation limit for admins. (And, hopefully, this message will be completely unnecessary and overcautious. } —Tom Morris (talk) 13:52, 12 April 2012 (UTC)

I think there's a distinction to be made between user groups and user rights here. We could totally continue to have the IP-limit-exempt function remain linked into the "admin" group regardless of what happens to Account Creator as a group. Okeyes (WMF) (talk) 13:56, 12 April 2012 (UTC)

Oliver, I have no clue what the ip limit exempt function is...it could be one of two things, could you clarify please? -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)

Technically it's "noratelimit"; the function that allows for what Tom is talking about (creating 20+ accounts from a single IP, say) Okeyes (WMF) (talk) 14:51, 12 April 2012 (UTC)

Thanks, that clears it up :) -- DQ (ʞlɐʇ) 22:36, 12 April 2012 (UTC)

(ec) Admins have all the rights associated with accountcreator at the moment anyway, so while I see where you're coming from, for admins it's a non-issue. Other users however... [stwalkerster|talk] 13:58, 12 April 2012 (UTC)

I see the problem that if we model what ACC is going to do, that whole identification thing is going to be a huge hassle. Because only identified users would then be able to add the "new acc flag" what ever it is, and admins will have to not be able to see the data presented in the interface. In a way, then were going to need another user group of trusted users to add only those identified to the foundation. I'm going to poke Philippe and his team on this, but we need a clear draft on what is going to be visable and to whom, then who can add/remove that access, before we can even consider things. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)

• @MZMcBride: the issue you raise above about ACC having it's own bureaucracy is replicating right here. User flags. Just as it would at ACC. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)
  • LOL @ how true that is. delirious & lost ☯ ^~hugs~ 15:21, 12 April 2012 (UTC)
  • DeltaQuad: In some ways, yes. But I'm not the one advocating for a lot of additional user groups and user rights. I think the whole process should be used very rarely and should be much simpler. We already have a user system here. What I'd like to eliminate is the completely separate user system within this tool, as I think the benefit is nowhere near the cost. Most people should be creating their own accounts, shouldn't they? The number of requested accounts per day should be very low and it should only be a tool of last resort. Given the privacy implications of collecting e-mail addresses and IP addresses, some bureaucracy is inevitable, but there's surely a difference between re-using MediaWiki's infrastructure and completely duplicating it, no? --MZMcBride (talk) 16:51, 12 April 2012 (UTC)
    • Ok, so what your advocating for is a userrightless system, that needs people only identified to the foundation to access, or your going to take away the tools we actually have to fight vandalism and give legit people accounts. You have failed to comment on all the sockpuppets (that's the 1 of many issues) that could get through if everyone was "able to create their own account". Then there is also something called Collateral damage on our blocks where we catch innocent users, but without the data provided at ACC, we can only call it a guess, instead of an educated guess. This new "system" that is being proposed is a solution looking for a problem, when there is a problem with the solution already. Also I would like to mention the unblock ticket response system (UTRS) in which I am a developer at, and we are looking to be able to forward several of our requests for unblock (the collateral damage) into the hands of ACC people who know what they are doing. With us taking away ACC, that would eliminate that option and would force our administrators to take more time to review the dozens of appeals we get a day, and deal with what ACC easily deals with now. -- DQ (ʞlɐʇ) 22:36, 12 April 2012 (UTC)
      • "You have failed to comment on all the sockpuppets (that's the 1 of many issues) that could get through if everyone was "able to create their own account"." ← This is a joke, right? God help me. --MZMcBride (talk) 03:30, 13 April 2012 (UTC)

I've been asked to comment here - this is someone who used to be active with account requests several years ago but I'm no longer active. Personally I think it would be better to reduce bureacracy as much as possible - I know when I handled requests it was quite rare to see someone actually trying to abuse the system - most declined requests were because of simple mistakes or incomplete information and people rarely bothered to follow them up.

In my view the best solution would be for an account request to be accepted/declined immediately and automatically, so when someone tries to create an account all of the similar usernames are checked and if any have over x edits, most recent being y years ago (or some other algorithm defined in a mediawiki: page somewhere) then you get an error message saying to pick another name, otherwise it creates the account. Also audio captchas should be used. And the throttle on creations from one IP address should be removed and replaced with some sort of notification to checkusers for them to review. If there's abuse going on then the IP can be blocked.

Any usernames that violate policies can be handled like any other username, after they're created. If someone tries to create a username that hits a filter somewhere after all this then they should be told to just pick another username. They're probably used to getting this message as so many websites would need to reject a username for whatever reason when you try to sign up.

Obviously all this requires developer time but if developers are prepared to commit time to this then I think it would be the best solution. And it eliminates any risk of private information being leaked bacause no humans handle the requests. Tra (Talk) 17:25, 12 April 2012 (UTC)

• @MZMcBride: Maybe I'm not reading this right but didn't you just confirm what ACC is "it's really meant as a tool of last resort", yes it is to the prospective users where this is there last resort in getting an account ? Sorry if I misunderstood your meaning. Mlpearc (powwow) 17:57, 12 April 2012 (UTC)
  • I have no idea what you're asking here. I was saying that most users should be creating accounts on their own and that using any supplemental process (such as tools:~acc) should be a step of last resort. As such, requests made through this (or any other supplemental tool) should be very rare. --MZMcBride (talk) 17:59, 12 April 2012 (UTC)
• I agree with Tra. Mato (talk) 00:15, 13 April 2012 (UTC)

To elaborate, I'm not in support of the proposed extension - the ins and outs are not clearly explained in the proposal and from the comments it seems that many features will be lost. However there are, IMO, many problems with the current system: primarily, the treatment of personal/sensitive information; secondarily, the issues of beauracracy which Tra mentions above. Mato (talk) 00:34, 13 April 2012 (UTC)

I haven't noticed any bureaucracy at the ACC tool, especially as compared to how it works at WP:PERM here on the wiki. People request access and it's usually granted without ceremony unless the person has limited experience on wiki or appears to be hat collecting. Access to the tool is as easily revoked and if you can provide a reasonable explanation access is once again easily given back. There is actually very little fanfare at the ACC tool as far as I can tell; we just process requests all day sometimes ask around if we get a tricky one. As for privacy, we've all identified to the foundation, which is more than admin have to do. — Bility (talk) 01:22, 13 April 2012 (UTC)

I wasn't referring to bureaucracy relating to getting access, I was referring more to how so much is handled manually when it would be possible to do it automatically. For instance, someone posted a list in bold of links they would want to see added. Many of these relate to blocks - surely the simplest solution would be to reject the request automatically if they're blocked from en.wiki and let them through if they're not? I also don't agree with checking for any prior vandalism on the ip before the account is created - it could have been anyone doing it and it would be better for people to be judged by the edits they make under their account. Tra (Talk) 02:45, 13 April 2012 (UTC)

@ Tra, I have been involved with ACC for little over two years on a daily basis and have created over 1600 accounts and I have never denied a request on IP vandal editing alone, It takes a much bigger red flag(s) for any user at ACC to even consider doing that. Mlpearc (powwow) 03:11, 13 April 2012 (UTC)

That's pretty much my point - that if requests cannot be rejected based on an ip's contributions then I'm ok with that. Tra (Talk) 09:41, 13 April 2012 (UTC)

I too was referring to all the checks done on requests; and how some are unnecessary. With regards to privacy, I think identifying to the foundation counts for rather little. I strongly think that full email addresses should NOT be exposed to tool users - it's unnecessary. IP blocks could be determined automatically and possibly eliminate the need for the IP to be displayed for the tool user, especially in situation where all block logs are clean. Mato (talk) 20:20, 13 April 2012 (UTC)

Step by Step

Ok I've read the various pages, and this discussion.

I'd like a bit more concrete data:

• 1.) which options would be set on Wikipedia (and other WMF wikis)? For example, would this be limited to bureaucrats?
• 2.) There seems to be a difference of opinion whether the tool server is the same as this extension. What would be the difference?
• 3.) Someone above said this will replace the regular account creation process as well? (self creation through the log-in page) How and why?
• 4.) How is this related to userrights? (The discussions above appeared a bit of a jumble to me.)

(I know some of this has been touched on here and there, but trying to figure this out as a cohesive whole). - jc37 05:27, 13 April 2012 (UTC)

Parallel?

How exactly would the extension and tool work in parallel? Randomly? CAPTCHA one way and blocked IPs another way and similar/identical usernames a third way?   — Jeff G. ツ (talk) 13:55, 13 April 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

FYI

We're A/B testing a new account creation page for a few weeks starting today. There should be no impact on the requests workflow, but please speak up on the relevant thread if something does seem wonky. Steven Walling (WMF) • talk 22:03, 4 October 2012 (UTC)

Too difficult to create username

User talk:Jimbo Wales and Wikipedia:Village pump (technical) have sections with the same heading and the details are there. Basically the similar name filter is too tight and we may be losing editors.--Canoe1967 (talk) 23:02, 20 April 2013 (UTC)

ACC needs help!

Hello everyone, I'm DeltaQuad (also known as DQ), an account creation interface administrator and developer. Recently, our project has had an increased backlog in getting accounts for new users. Our numbers are currently above 250 people waiting for accounts on the English Wikipedia. If you could even spare a moment to do a few requests a day to help us clear this backlog. If this interests you and your willing to help, and you match the following description, then please do apply! Ideal users are:

• Identified to the Wikimedia Foundation
• In good standing with no recent blocks
• Understand and being able to apply the username policy
• Have worked with new contributors
• Have a good at dealing with a situation even while in a dispute
• The full list of requirements

We have a very friendly team to help you get started and we also have an IRC channel. If you have any questions for us or about the process, feel free to ask at the talkpage. If you can help out, we would greatly appreciate it. For the ACC Administration and Development Team, -- DQ (ʞlɐʇ) 23:20, 18 March 2013 (UTC)

Any way to find out if my application went through? Should I reapply? Applied 2 Apr after ID and such but no feedback, positive or negative. Thanks, DocTree (ʞlɐʇ·cont) Join WER 17:24, 11 April 2013 (UTC)

• Identified, and applied. More than willing and able to lend a hand for as long and as hard as I'm needed. -T.I.M^(Contact) 19:15, 11 April 2013 (UTC)
  • I would love to help out, and am not opposed to identifying, however I'm afraid I may not meet all of the other requirements. I was indefinitely blocked for a total of 29 hours about 3 weeks ago for "disruptive editing." That may disqualify me; however, I can make a print-out of the username policy to become fully familiar with it (I'm sure it is mostly common sense), I've worked with many new contributors as a host for WP:TH and I assist where I can on WP:HD, WP:VPT, and WP:AfC. As a steward and administrator on other wikis who has completed interpersonal communications classes in college and has a fairly firm grasp of the conflict resolution model, I would consider myself at least decent at dealing with a situation even while in a dispute. I've not yet looked at The full list of requirements, but if my block 3 weeks ago wouldn't disqualify me from helping at this time, I would be happy to. Thank you for your time. Technical 13 (talk) 22:14, 21 April 2013 (UTC)
    • We take each user into consideration on a case by case basis. (As noted by the comment "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.") I can't say which way I would lean, as I have not fully read your situation yet with your block, but it would require discussion amongst tool admins. A big part of it will be how you handled your unblock request and what the "disruptive editing" was, since we are a customer service front, and working under stress is sometimes what happens here. Feel free to submit the request if you would like to assist, you will at least be in the system either way, but I doubt an overnight decision will happen. -- DQ on the road (ʞlɐʇ) 00:32, 22 April 2013 (UTC)
      • That sounds fair enough. I'll familiarize myself with the policies mentioned above and likely apply in a day or two once I've had a chance to become acquainted with the policies and get myself added to the identified list. Thank you for your prompt reply. Technical 13 (talk) 01:31, 22 April 2013 (UTC)

Account creator permission usage

Hello everyone, I have started a discussion at WT:PERM regarding the use and assignment of the account creator flag. I thought I would let the people affected by this know. -- DQ on the road (ʞlɐʇ) 01:31, 22 April 2013 (UTC)

Account creation form redesign

Cross-posting my request for feedback on the form's new design for account creators. Steven Walling (WMF) • talk 22:21, 3 May 2013 (UTC)

Small interface enhancment

FYI: with the next MediaWiki release, bug 47686 will be fixed, meaning the account creation interface will no longer show the email field as "(optional)" when you check "Use a temporary random password and send it to the email address specified below". Steven Walling (WMF) • talk 19:36, 8 July 2013 (UTC)

Request an account process needs help 2013

Hello everyone, I'm Callanecc, an administrator on account creation interface. Recently, our project has had an increased backlog in getting accounts for new users. Our numbers are currently over 250 people waiting for accounts on the English Wikipedia. If you could even spare a moment to do a few requests a day to help us clear this backlog, that would go a long way to encouraging new editors to participate with an account. If this interests you and you're willing to help, and you match the following description, then please do apply! Ideal users are:

• Identified to the Wikimedia Foundation or are willing and able to identify
• In good standing with no recent blocks or other sanctions
• Understand and are able to apply the username policy
• Have worked with new contributors
• Keep personal information confidential
• Please see the full list of requirements for more information

We have a very friendly team to help you get started, we also have a private IRC channel where you can ask questions or get help with difficult account requests. If you have any questions for us or about the process, feel free to ask at the talkpage. If you can help out, we would greatly appreciate it. For the ACC team,

I don't understand. Why on Earth is this necessary? Why can't the people just keep trying until they get a CAPTCHA that works or something? Wnt (talk) 17:06, 11 December 2013 (UTC)

Assuming you're referring to the request an account process; captcha is probably one of the least likely reasons that someone would request an account rather than create it themselves. There are plenty of reasons that people can't create a legitimate account but would like to, like schoolblocks, proxy blocks, or the requested username being similar to an inactive account. Samwalton9 (talk) 17:41, 11 December 2013 (UTC)

This is absurd. Let's start with "too similar" -- I didn't even know there was such a criterion - I doubt anyone would care if you changed it. Given that half the people on en.wikipedia sign their posts with some bogus name that isn't their username we have much more significant sources of confusion to contend with"! I don't see where the criteria for "too similar" are listed, but if they're onerous, let's relax them. If they're reasonable (Cyrillic "a"...) then don't offer the service. Problem solved, no volunteers needed. Optional: start a log of inactive usernames. Any account not logged into within a year, with under 15 edits globally, gets recycled. To satisfy the CC license we have the software automatically put a copy of the account history in a logfile, and log the change of status ('account destroyed') to the history.

Schoolblocks/rangeblocks: expire them sooner, or tell people to log in somewhere else. For proxies, my skimming of the guideline is that you tell them to FOAD already, so there's nothing doing there anyway.

I never heard of this mechanism before today, but it seems like this bureaucratic makework will absorb as many volunteers as are thrown at it and always be hungry for more. Wnt (talk) 20:28, 11 December 2013 (UTC)

Similar accounts are caused by Antispoof, we can not change that at all since it is a global Wikimedia thing which is needed for the global unification system. Sometimes those blocks are hardblocked, therefore when we create their accoutns we also follow up IPBEs etc to make their editing experience better and such. Saying 'Sorry, create an account somewhere else' is extremely bad for editor retention. For the final comment, I am not going to say anything about that. John F. Lewis (talk) 20:38, 11 December 2013 (UTC)

I don't like the "etc." in the Antispoof documentation, but if it's all stuff like omicron for o, then allowing these similar but not identical accounts seems like a bad practice. Either you should have an automated way to expire and delete inactive accounts with few edits entirely, or else you should keep people from using similar names in every case. Allowing for the possibility that we may eventually run into two accounts later on with such an invisible difference between them is just bad policy. Especially if someone deliberately searches for expired accounts to hack their passwords and cause mischief. Wnt (talk) 21:27, 11 December 2013 (UTC)

What about User:WnT ? Mlpearc (open channel) 21:36, 11 December 2013 (UTC)

Personally, I think that's recognizable, and I wouldn't care if it existed. But I ran through quite a few possibilities before I found a three-letter name that I could register, and whatever the rules would be, I'd have to put up with them, even if it meant going to four. The key point is, if we agree on some technical mechanism to prevent confusion, subject to whatever arguments they may have about the extension over at MediaWiki, we shouldn't poke holes in it.

To give an example, suppose I were a reporter and I'd been aware of Antispoof before the great username merge between the projects. Why, I could have registered two or three names similar to every present, former, and candidate Arbcom member on en.wikipedia, on other projects! Left two or three edits each, and kept them around inactive, like Baldur's mistletoe, just waiting for the day some juicy salacious press case involving a school shooter or child predator. Then copied the real ArbCom member's userpage for my own, and left a message on some other arb's site - sorry, my webmail is down for days, can you send me all the stuff that was mailed out about the XXX case (just use emailthisuser...)? You see what I mean? So no, let's not deliberately create similar account names - we should be trying to get rid of those that currently exist whenever feasible. Wnt (talk) 17:59, 12 December 2013 (UTC)

• Cal, I'm still interested and as far as I know my "application" is still active in the tool. Dusti was going to add me to the tool once my time since block exceeded six months, but he seems to have gone AWOL, and I am are at seven or eight months since that event now. Let me know if you're interested. Thanks. Technical 13 (talk) 00:22, 12 December 2013 (UTC)

Age Restriction

Hi there-- do I need to be over 18 to be identified to Wikimedia Foundation, or to be an account creator? I'm very interested in helping with this project if I'm allowed to, however, I am below 18 years old. I am willing to identify myself to WMF.

Thanks! -Newyorkadam (talk) 06:31, 17 January 2014 (UTC)Newyorkadam

Hi Newyorkadam, the requirements for gaining access to the actual account creator interface is you need to be over 18 and identified to the Foundatiom per the Access to nonpublic data policy. The main reason for this is that account creators on the interface have access to non public information about the request or such as their email and IP address. The account creator right is usually give to participants after they have been involved for the process for some time. I hope this answers your original questions, John F. Lewis (talk) 07:54, 21 January 2014 (UTC)

Hi John, thanks for the reply, I understand. Thanks :) -Newyorkadam (talk)Newyorkadam

So I hear we have a backlog...

Hi there everyone, it's me again. I used to roll around these parts as an Account Creator, but I'll settle for being able to help out for just six shots at a time until I'm back up to full speed. Just re-enable access for the user of my name and I'll see what I can do to help! Cheers. -TIM^(Contact)/_(Contribs) 03:39, 8 May 2014 (UTC)

 Done Please follow the procedure for mailing list and IRC channel access, thanks. John F. Lewis (talk) 05:24, 8 May 2014 (UTC)

Helping out with ACC

Hey, so I used to help out with ACC quite a while ago, and I'd like to help out again. Here is my confirmation and link to identification. My account is under the same name as my username (Parent5446) and is currently disabled for inactivity. If there's anything I need to do, just let me know. The IRC channel is private so I wasn't sure whether there is a public one I need to go to in order to register. — Parent5446 ☯ ^{(msg email)} 23:59, 2 July 2014 (UTC)

Semi-automating removal of account creator right

Please see WT:PERM#Automating procedural removal of account creator rights — MusikAnimal ^talk 19:04, 15 September 2015 (UTC)

Request an account process needs help 2015

Hello everyone, I'm John F. Lewis, an administrator on Wikipedia's account creation interface. Recently, our project has had an increased backlog in getting accounts for new users. Our numbers are currently over 400 people waiting for accounts on the English Wikipedia. If you could even spare a moment to do a few requests a day to help us clear this backlog, that would go a long way to encouraging new editors to participate with an account. If this interests you and you're willing to help, and you match the following description, then please do apply! Ideal users are:

• Identified to the Wikimedia Foundation or are willing and able to identify,
• In good standing with no recent blocks or other sanctions,
• Understand and are able to apply the username policy,
• Have worked with new contributors,
• Please see the full list of requirements for more information.

We have a very friendly team to help you get started, we also have a private IRC channel where you can ask questions or get help with difficult account requests. If you have any questions for us or about the process, feel free to ask at the talk page. If you can help out, we would greatly appreciate it. For the ACC team, John F. Lewis (talk) 18:02, 29 May 2015 (UTC)

@John F. Lewis: Email sent to the list. Sam Walton (talk) 19:16, 29 May 2015 (UTC)

Received and approved. Follow the usual instructions for mailing list and IRC access and I'll unsuspend your account now. Thanks, John F. Lewis (talk) 19:18, 29 May 2015 (UTC)

Just as a note (not suggesting any changes here), I used to be very active in WP:ACC, but that's when it was a wiki-based system. Moving to an email-based system (and presumably to a web-form-based system since) was good for privacy, but it meant a sufficient amount of extra complexity that I just gave up on the whole thing (and eventually ended up drifting away from Wikipedia, because it was my major area of admin activity). Back then, it was something simple and quick that anyone could do (both admins and non-admins were needed for technical reasons; I had a non-admin sock User:ais523 non-admin at least partly for that purpose). Nowadays, WP:ACC/G is listing a set of restrictions on account creation that are more reminiscent of RfA than anything else, and so I'm not particularly surprised that you're having problems finding people to go through the account creation system.

The process would likely be a lot less backlogged if you could find some way to reduce or remove the process creep. (In particular, I'm not entirely convinced there's even a need to see nonpublic information to be able to perform a decent chunk of account creation requests; the only reason we used to need it was to set the email address of the new account, and I can easily imagine some web-based system that could handle that without ever showing the account approver the information.) --ais523 05:46, 11 October 2015 (UTC)

The account creation form unfortunately does display the email and it is required to be passed on the form which in any sense would have it displayed in any API calls. IP information is also extremely helpful and in fact a staple for users on the tool as checking for proxies (per m:NOP) or range blocks (e.g. checkuserblocks, schoolblocks, vandalismblocks, oversight blocks and so on) allow users to gain and insight and assess accounts before going a head with creation. The information can also support in make case-by-case decisions such as someone wants the username 'Bill Thompson' and they have a wikipedia page stating they're a governor of an area, email and IP information allows the person working on the request to decide whether or not they are said person or not. John F. Lewis (talk) 19:28, 11 October 2015 (UTC)

The problem with IP/rangeblocks isn't something I'd thought of (basically because the old process required a wiki edit, and thus if you were blocked you wouldn't have been able to make a request in the first place). I assume that WP:ACC is nowadays more about letting people create an account through an IP block, than it is about overriding AntiSpoof (which is what it used to be mostly for), in which case it's sort-of turning into a second UTRS. --ais523 22:34, 12 October 2015 (UTC)

I am willing to help out with account creation if you still need help. Let me know if you think I qualify. Sheriff | ☎ 911 | 03:09, 24 February 2016 (UTC)

Template for deletion

A template relevant to this project, {{acc}}, has been nominated for deletion. The discussion can be found here. Your input is appreciated. Primefac (talk) 16:08, 20 December 2016 (UTC)

Note

I don't know how to better communicate this to the ACC team. ticket:2017021510019971 verifies identity for [ACC #193642]. Let me know (probably by email, since I can't go into great detail on-wiki) if you have any questions. ~ Rob₁₃^Talk 14:13, 7 July 2017 (UTC)

I already mentioned this to BU Rob13 on IRC. See Wikipedia:Request an account/Guide#Real names relating to famous, popular, etc. persons for the process. In this case the request cannot be reopened, so the requester must complete a new account request with the OTRS ticket number included in the comments field. The ACC team can be emailed at accounts-enwiki-llists.wikimedia.org. — JJMC89 (T·C) 15:31, 7 July 2017 (UTC)

Two-month backlog, reporting this as a problem to Village pump

• Wikipedia:Village_pump_(technical)#Failing_"request_an_account"_process

I advocate in favor of more automation in whatever cases possible to relieve the pressure on this task. The backlog is bad, there is no reason to think things will get better, and things will likely get worse in the future. We should change something. Blue Rasberry (talk) 13:02, 12 February 2019 (UTC)

Does anyone care?

Sorry for the inflammatory header, I'm not meaning to attack anyone, but as someone who just re-joined ACC, I'm appalled at the situation. I thought that I could help grind down the backlog. But, after a few attempts at moderate grinding, I keep coming back the next day to see the backlog larger than before. I was actually what I thought was a fairly active account creator back in 2010, when it was hard to even reserve requests before somebody else. Since re-joining, I've already handled over half the number of requests I had handled in the first half of 2010, in only a couple of days. But it seems I'm not even making a dent in the backlog. What the hell happened? Why are there no volunteers? Have there been any efforts to fix the situation? Is it even worth trying to resolve, or should we just scrap the process? This task really isn't even difficult. It doesn't take a rocket scientist to do this job. If anything, it's grunt work. But the only people I've seen involved have been other administrators. Why isn't anyone helping us? ~Swarm~ {talk} 05:58, 28 February 2019 (UTC)

• Blue Rasberry's VP thread from this month is already in the archives. Before that, nobody has commented here since 2017? What is going on?? ~Swarm~ {talk} 05:59, 28 February 2019 (UTC)

  One or two people can't dent in backlog, I have tried that in past and if you stop few days it's the same again. What we need is more people handling requests daily, as if anybody take a rest for few days requests stays under control. ‐‐1997kB (talk) 08:39, 28 February 2019 (UTC)

  I'm willing to handle a dozen, or two dozen, requests daily. I will sacrifice my time to make a difference, no problem. But, if it appears no one else is doing so, it's pretty demoralizing. There is little incentive for investing hours into the backlog, when it feel like you are the only one who is trying to help out. So, if the issue is as simple as a lack of volunteers, then how can we resolve this simple issue? ~Swarm~ {talk} 08:51, 28 February 2019 (UTC)

  Maybe try giving access to all the admins? like we have for CU now. Daily we receive ~70-80 requests so 10-12 people should be regularly processing them in order to keep it backlog free. ‐‐1997kB (talk) 10:25, 28 February 2019 (UTC)

  1997kB, since when do we give admins checkuser access? cymru.lass (talk • contribs) 21:47, 6 March 2019 (UTC)

  Cymru.lass, I meant like CU's are given access to tool for CU tasks, similarly if we give access to admins to help us keep it backlog free, but as Swalkersock mentioned, all of admins doesn't have meta:Access to nonpublic personal data policy signed so it is the reason we can't do this. ‐‐1997kB (talk) 03:19, 7 March 2019 (UTC)

That is correct. They would have to read and sign the Confidentiality agreement for nonpublic information before they could be given any access to the ACC tool user interface. ~Oshwah~^{(talk) (contribs)} 20:45, 10 March 2019 (UTC)

• Could I ask why ACC isn't already open to every admin? Nosebagbear (talk) 14:02, 4 March 2019 (UTC)

  Nosebagbear, a user's user rights on-wiki aren't really involved in the user approval process here. Granted, being an admin definitely helps, but the main sticking point to blanket granting this to all admins is the requirement to sign the meta:Access to nonpublic personal data policy, and that requirement is non-negotiable amongst the community. To answer your questions Swarm, everyone started redirecting people to ACC a lot more than they did in the past. Many block templates now point here where previously they didn't, and many more people suggest it as an alternative. At the same time, interest in ACC has somewhat waned, so we have fewer active people and many more requests. Indeed, few people comment here; most discussion of process matters occurs on the mailing list, but that's fairly rare too. Discussion about specific requests is limited to the tool itself or IRC normally. stwalkerster (sock | talk) 14:25, 4 March 2019 (UTC)

  @Stwalkersock: - cheers for explaining, I did rewrite my initial comment as I suspected there was something I was missing - though thinking about it makes sense. I can see that required signing makes sense. Personally it feels that there are more people signed on the policy than was the case, but actually getting that limited pool to work on ACC is the tricky step, I suppose. Thanks again. Nosebagbear (talk) 14:29, 4 March 2019 (UTC)

  Well, those who are legally able to sign (which, if I recall correctly, is a declaration you are 18 or age-of-majority, whichever is greater), and are willing to legally agree to it can sign - it's not a case of "only those listed can do ACC", it's actually "if you want to do ACC, you must sign". And yes, it has been said several times before that organising volunteers to work on something specific is akin to herding cats... stwalkerster (sock | talk) 14:51, 4 March 2019 (UTC)

• I'm very eager to help here, but I've been waiting for about a month now(? - bad with dates but it has been a hot minute) to get approved to use the tool. I've signed the agreement and all my ducks are in a row, but upon attempting to log in to familiarize myself with the tool, it says my application is still pending review. Pinging tool administrators that I know of for visibility: Oshwah, DeltaQuad, JJMC89. Cheers, cymru.lass (talk • contribs) 21:22, 6 March 2019 (UTC)

  This is totally my fault. I had DQ do the root things and then I never approved your account. Thanks for taking care of it, DeltaQuad. — JJMC89 (T·C) 03:20, 7 March 2019 (UTC)

  Heh I don't even remember doing the root things. Either way, I independently reviewed the request and things you'll make a good fit. -- Amanda (aka DQ) 03:24, 7 March 2019 (UTC)

  DeltaQuad, JJMC89, thank you both!! I'm a little bit swamped today but I'm looking forward to getting started with the process cymru.lass (talk • contribs) 15:39, 7 March 2019 (UTC)

I'm glad to see that this has been resolved. :-) ~Oshwah~^{(talk) (contribs)} 20:45, 10 March 2019 (UTC)

Following on from what User:Stwalkerster said above, I'm a big believer that people should only be directed to a volunteer account creation service as a last resort. I've gathered a list of places where people are most commonly directed here. Only Template:Schoolblock and Template:ConsentBlock offer vaguely realistic advice. People without an account should not be told to request one, they should be told to find alternative ways to create one, if they can, even if it's at a later date. So in addition to the big bold message at the top of Wikipedia:Request an account, I think these all need tweaking somehow:

Help:I have been blocked
If you have never edited Wikipedia before and/or do not have an account, consider requesting one at Wikipedia:Request an account
MediaWiki:Cantcreateaccount-text
To request that an account be created for you, please follow the instructions at Wikipedia:Request an account
MediaWiki:Torblock-blocked
In order to edit through Tor and from IP addresses running Tor exit nodes, you will need to request an account
MediaWiki:Acct creation throttle hit
If you would like to request an account be created for you, follow the instructions at Wikipedia:Request an account.
Template:CheckUser block
If you do not have an account and wish to bypass this block, an account can be created to allow you to edit. In general, these blocks only prevent users who are not logged in from editing; once you are logged in, the block will no longer affect you in any way. Please request an account under your preferred username
Template:School block
[if] you are unable to create an account elsewhere, you can request one by following the instructions at Wikipedia:Request an account
Template:Anonblock
If you are currently blocked from creating an account, you may follow the instructions at Wikipedia:Request an account to request a username
Template:Rangeblock
If you do not currently have an account and wish to bypass this block, an account can be created to allow you to edit
Template:Rangeblocked
If you don't have an account, you can request an account

-- zzuuzz ^(talk) 15:44, 15 April 2019 (UTC)

• @Zzuuzz: - while it's not ideal, in the sense of we play the cards we're dealt, I think you may be right. I would also like to add OTRS to the list - the advice given on emails should match up.

However, it's such abroad list that I'd suggest diverting this to WP:VPP, ping the individuals here and getting a proper proposal to amend the 1st step resolution for most of these going on it - rather than starting a dozen different discussions. Nosebagbear (talk) 15:50, 15 April 2019 (UTC)

If someone would restore my ACC flag and reinstate my tool access, I can work on the backlog for a few weeks. (please ping me if you do) - FlightTime (open channel) 19:31, 15 April 2019 (UTC)

 Done — JJMC89 (T·C) 04:11, 16 April 2019 (UTC)

Thanx (i think) :P - FlightTime (open channel) 05:24, 17 April 2019 (UTC)