Wikipedia talk:Request an account/Archive 6

This is an archive of past discussions about Wikipedia:Request an account. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 4

Archive 5

Archive 6

Creation limit

Hello, after noticing a user being preventing from creating more than four accounts/day here, I looked into the rate limit. It's currently set temporarily at 4 accounts per day since late 2018 as a security measure (phab:T212667). I'm not sure when it will be raised to six again.

Because we have such a backlog, I think it would make sense to allow new users at ACC to help out with more than 4 creations per day. There are two options we could take here:

Raise the local rate limit from 4 to, say, 10. We could apply this new limit only to extendedconfirmed users to prevent any abusive behaviour from IPs.
Automatically grant accountcreator permissions to new ACC users. This would allow them to bypass the limit entirely, but would also let them ignore the antispoof and title blacklist when making accounts.

Between the two, I think that option 1 makes the most sense for now. There is still probably value to letting new users to ACC get some experience before giving them full access. Any thoughts? -- Ajraddatz (talk) 20:15, 1 June 2019 (UTC)

NO, we must be able to verify the user knows how to handle similar account request, the ratelimit is not the issue. - FlightTime (open channel) 17:17, 2 June 2019 (UTC)

I agree that option 1 makes the most sense at this time. --TheSandDoctor ^Talk 20:21, 1 June 2019 (UTC)
We've never had much of an problem granting ACC users accountcreator access when their team approves it, WP:PERM is normally straight forward. I'm not sure what you mean by #2 though - how do you expect this "automatic" mechanism to work? And ultimately, with SUL isn't this more of a global issue then an enwiki issue? — xaosflux ^Talk 20:27, 1 June 2019 (UTC)

I just mean granting it to people when giving them access or on request. I know that in the past the accountcreator flag was quite guarded, but if it's no big deal these days then there would be less need for any change. Regarding global vs enwiki, a couple of years ago I floated the idea of moving the process to Meta and making it more of a global renamer-type thing, but it didn't go anywhere. FWIW, people can already bypass the four-a-day limit by making the new accounts on other wikis where they haven't hit the limit yet. With some 600 open projects, you could create 2,400 accounts per day if you were really dedicated. -- Ajraddatz (talk) 20:32, 1 June 2019 (UTC)

Ahh OK. I'm pretty much fine with anyone on the ACC tool team having account creator access; if they abuse it they can be degrouped, kicked out of the tool, blocked, etc. — xaosflux ^Talk 20:37, 1 June 2019 (UTC)

Yes, there has been very little problems (if any) with users getting the ACC flag, once the team has approved it. - FlightTime (open channel) 17:12, 2 June 2019 (UTC)

Option 1 should definitely be implemented, since 6 was already a low bar for users without the AC bit. I think enwiki is big enough to justify having need of a higher limit. No strong opinion on the second option, although if we're vetting users adequately enough, they should be trustworthy enough to gain the bit. Perhaps set a threshold of a week of activity and at least 20 requests, so we have a good idea of their ability to properly handle requests? — AfroThundr ^{(u · t · c)} 20:11, 3 June 2019 (UTC)

With regard to Option 2 (Opt1 seems clearly wise) - Most of Account Creator is folded into Event Co-ordinator, which is usually given as a temporary right. After they've had a week here, we could ask PERM to grant AC for a month (or whatever), both to see if they use it properly, but also if they use it at all. Nosebagbear (talk) 21:16, 3 June 2019 (UTC)
Upping the limit to 10 is a good start. --qedk (t 桜 c) 08:59, 6 June 2019 (UTC)
@Ajraddatz: - there seems to be consensus for option 1, at least, do we know who we have to ask to adjust? Will it need a VPT RfC? Nosebagbear (talk) 12:23, 14 June 2019 (UTC)

Ajraddatz - I believe so. If anything, it can't hurt. :-) ~Oshwah~^{(talk) (contribs)} 12:42, 14 June 2019 (UTC)

I think option 1 is the best solution here. ~Oshwah~^{(talk) (contribs)} 12:41, 14 June 2019 (UTC)

Sure, I'll set it in motion. If we're going to do it, I might as well ask both Nosebagbear (talk) 12:44, 14 June 2019 (UTC)

Wait time

User:Oshwah, does this make any sense to you? Drmies (talk) 17:39, 6 December 2019 (UTC)

Not Oshwah but there are currently 2126 requests, 611 of which are from 7 months ago. Praxidicae (talk) 17:43, 6 December 2019 (UTC)

The requests appear to be backlogged that far, unfortunately. ~Oshwah~^{(talk) (contribs)} 22:43, 6 December 2019 (UTC)

The backlog is reducing in quantity thankfully, but some of the oldest requests are still positively ancient. Fancy lending a hand? stwalkerster (talk) 01:24, 7 December 2019 (UTC)

Always happy to help. ;-) I apologize for my recent level of inactivity on this project. Life has kept me busy, and I've unfortunately been maintaining a "peak and valley" pattern of activity on Wikipedia throughout the second half of this year as a result. ~Oshwah~^{(talk) (contribs)} 10:01, 17 December 2019 (UTC)

We need better transparency for wait times.

Some reasons why people need to request an account require no research and should move to the front of the line.

Captcha and browser issues only require enough research to make sure the editor isn't also affected by an unacceptable username or blocked-IP issues. If they aren't, the account can be summarily created for him. Turn-around should be days not months.

Most username issues shouldn't require a lot of research or discussion, but a few will. For those that don't, turnaround should be in days not months.

IP address blocks will depend on the reason for the block, recent history of the block, and other issues and these can sometimes drag out.

If we don't already do it, we should inform editors within a few days about how long they should expect to wait, so they can affirm their request or cancel it.

We also need an automated report that will give people requesting an account some indication of how long it takes to clear the backlog.

An example report might be:

As of November 1, 2019, The backlog is over 2100 requests. 611 of them are from 11 months ago.

Of requests made between 7 and 8 months ago, X% were resolved within 3 days, X% within 1 week, X% within 1 month, X% within 2 months, ... and X% within 8 months, with X% unresolved.

Of requests made between 6 and 7 months ago, X% were resolved within 3 days, X% within 1 week, X% within 1 month, X% within 2 months, ... and X% within 7 months, with X% unresolved.

...

Of requests made between 1 and 2 months ago, X% were resolved within 3 days, X% within 1 week, X% within 1 month, X% within 2 months, with X% unresolved.

davidwr/(talk)/(contribs) 19:23, 17 January 2020 (UTC)

For the most part, all the trivial ones have mostly been handled already (except maybe for any in the last week or so, I've not checked the reports for a few days). We can probably pull together these sorts of stats fairly easily from the database. There's a large set of changes pending code-review (still!) at the moment, so I'm hesitant to push anything in ahead of that. Bug tracking and feature requests are handled on GitHub if you feel like making a formal feature request. :) stwalkerster (talk) 19:29, 17 January 2020 (UTC)

Hmm, perhaps instead of a single "backlog" number of "7 months" there should be a different messages, such as "For the 12 months prior to [some date more than 1 week ago], x% of requests were handled within 1 week. If your request is expected to take longer than one week, you will be notified and given an estimate of the delay." davidwr/(talk)/(contribs) 19:48, 17 January 2020 (UTC)

Note: I opened this thread after reading a thread on the Village Pump: Wikipedia:Village pump (policy)#Impact of IP blocking opened at 18:51, 8 January 2020 (UTC). Part of that thread was about the "signposting" which I took to mean the messages a user gets when he is IP-blocked and cannot create an account from that IP address. This discussion will probably eventually be archived in the current archive or the next one. davidwr/(talk)/(contribs) 19:55, 17 January 2020 (UTC)

@Davidwr: Does this give you the information you're looking for? It's just a snapshot of the status earlier today, and will require some interpretation especially given the tail off with the recent requests. The oldest request we currently have still open in the system dates back to May 2019. The first table is the last 12 months, so Jan 2019's data is partial. I've included the full dataset below as well for historical interest. stwalkerster (talk) 23:59, 17 January 2020 (UTC)

Source code

select
       period as "Data period",
       sum(total) as "Total requests",
       sum(l3d) as "Closed in 3 days",
       sum(l7d) as "Closed in 7 days",
       sum(l14d) as "Closed in 14 days",
       sum(l1m) as "Closed in 1 month",
       sum(l2m) as "Closed in 2 months",
       sum(l3m) as "Closed in 3 months",
       sum(l4m) as "Closed in 4 months",
       sum(l5m) as "Closed in 5 months",
       sum(l6m) as "Closed in 6 months",
       sum(l7m) as "Closed in 7 months",
       sum(l8m) as "Closed in 8 months",
       sum(l9m) as "Closed in 9 months",
       sum(l10m) as "Closed in 10 months",
       sum(l11m) as "Closed in 11 months",
       sum(l12m) as "Closed in 1 year",
       sum(g12m) as "Closed in more than 1 year",
       sum(open) as "Requests still open",
       sum(dropped) as "Requests dropped"
from (
    select 1 total
        , concat(extract(year from email_confirmed), '-', lpad(extract(month from email_confirmed),2,'0')) period
        , first_closed, email_confirmed , datediff(first_closed, email_confirmed)
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 0 and 3 then 1 else 0 end l3d
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 4 and 7 then 1 else 0 end l7d
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 8 and 14 then 1 else 0 end l14d
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 15 and 28 then 1 else 0 end l1m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 29 and 60 then 1 else 0 end l2m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 61 and 90 then 1 else 0 end l3m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 91 and 120 then 1 else 0 end l4m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 121 and 150 then 1 else 0 end l5m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 151 and 180 then 1 else 0 end l6m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 181 and 210 then 1 else 0 end l7m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 211 and 240 then 1 else 0 end l8m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 241 and 270 then 1 else 0 end l9m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 271 and 300 then 1 else 0 end l10m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 301 and 330 then 1 else 0 end l11m
        , case when valid = 1 and datediff(first_closed, email_confirmed) between 331 and 365 then 1 else 0 end l12m
        , case when valid = 1 and datediff(first_closed, email_confirmed) > 365 then 1 else 0 end g12m
        , case when first_closed is null then 1 else 0 end open
        , case when valid = 0 then 1 else 0 end dropped
    from (
         select
            eclog.timestamp email_confirmed
            , closelog.timestamp first_closed
            , case when closelog.action = 'Closed 0' then 0 else 1 end valid
        from log eclog
        left join log closelog ON closelog.objectid = eclog.objectid and closelog.objecttype = eclog.objecttype and (closelog.action like 'Closed %')
        left join (
            select min(maxlog.id) id
            from log maxlog
            where 1=1
            and (maxlog.action like 'Closed %')
            and maxlog.objecttype = 'Request'
            group by maxlog.objectid
            ) latestlog on closelog.id = latestlog.id
        where 1 = 1
            and eclog.objecttype = 'Request'
            and eclog.action = 'Email Confirmed'
           -- and eclog.timestamp > date_sub(current_timestamp(), interval 12 month)
    ) closedata
) f
group by period
order by 1;

Data period	Total requests	Closed in 3 days	Closed in 7 days	Closed in 14 days	Closed in 1 month	Closed in 2 months	Closed in 3 months	Closed in 4 months	Closed in 5 months	Closed in 6 months	Closed in 7 months	Closed in 8 months	Closed in 9 months	Requests still open	Requests dropped
2019-01	1048	83	17	9	12	64	41	420	262	4	0	0	0	0	136
2019-02	1616	158	22	15	39	77	227	388	317	172	5	4	0	0	192
2019-03	1762	111	39	47	28	243	299	26	165	129	409	37	0	0	229
2019-04	2375	177	10	6	95	741	95	183	11	5	644	153	6	0	249
2019-05	2261	142	23	39	181	82	624	70	28	29	105	293	133	283	229
2019-06	1348	202	26	7	14	317	4	122	28	30	90	75	0	295	138
2019-07	1412	128	65	155	187	9	2	131	153	97	88	0	0	243	154
2019-08	383	17	9	0	8	30	68	84	12	18	0	0	0	86	51
2019-09	373	58	13	13	11	54	82	13	14	0	0	0	0	80	35
2019-10	358	21	3	15	71	85	27	22	0	0	0	0	0	59	55
2019-11	316	72	23	36	28	46	13	0	0	0	0	0	0	66	32
2019-12	251	52	13	42	45	23	0	0	0	0	0	0	0	63	13
2020-01	201	28	15	17	0	0	0	0	0	0	0	0	0	132	9

Extended data

Data period	Total requests	Closed in 3 days	Closed in 7 days	Closed in 14 days	Closed in 1 month	Closed in 2 months	Closed in 3 months	Closed in 4 months	Closed in 5 months	Closed in 6 months	Closed in 7 months	Closed in 8 months	Closed in 9 months	Requests still open	Requests dropped
2009-10	186	179	0	0	0	0	0	0	0	0	0	0	0	0	7
2009-11	677	660	0	0	0	0	0	0	0	0	0	0	0	0	17
2009-12	587	569	0	0	0	0	0	0	0	0	0	0	0	0	18
2010-01	801	777	0	1	0	0	0	0	0	0	0	0	0	0	23
2010-02	785	755	0	0	0	0	0	0	0	0	0	0	0	0	30
2010-03	939	902	0	0	0	0	0	0	0	0	0	0	0	0	37
2010-04	1106	1079	0	0	0	0	0	0	0	0	0	0	0	0	26
2010-05	998	974	0	0	0	0	0	0	0	0	0	0	0	0	24
2010-06	768	742	0	1	0	0	0	0	0	0	0	0	0	0	25
2010-07	735	711	1	0	0	0	0	0	0	0	0	0	0	0	23
2010-08	752	735	1	0	0	0	0	0	0	0	0	0	0	0	16
2010-09	929	901	0	0	0	0	0	0	0	0	0	0	0	0	28
2010-10	860	828	1	1	0	0	0	0	0	0	0	0	0	0	30
2010-11	829	795	0	0	0	0	0	0	0	0	0	0	0	0	34
2010-12	476	451	1	0	0	0	0	0	0	0	0	0	0	0	24
2011-01	653	632	0	0	0	0	0	0	0	0	0	0	0	0	21
2011-02	716	693	0	0	0	0	0	0	0	0	0	0	0	0	23
2011-03	735	709	0	0	0	0	0	0	0	0	0	0	0	0	26
2011-04	662	625	4	0	0	0	0	0	0	0	0	0	0	0	33
2011-05	704	653	2	0	0	0	0	0	0	0	0	0	0	0	49
2011-06	651	619	3	0	0	0	0	0	0	0	0	0	0	0	29
2011-07	923	887	2	1	0	0	0	0	0	0	0	0	0	0	33
2011-08	973	924	0	0	0	0	0	0	0	0	0	0	0	0	49
2011-09	897	827	8	1	0	1	0	0	0	0	0	0	0	0	60
2011-10	794	752	1	0	0	0	1	0	0	0	0	0	0	0	40
2011-11	923	873	0	0	0	0	0	0	0	0	0	0	0	0	50
2011-12	683	646	0	0	0	0	0	0	0	0	0	0	0	0	37
2012-01	854	816	0	0	0	0	0	0	0	0	0	0	0	0	38
2012-02	763	717	0	0	0	0	0	0	0	0	0	0	0	0	46
2012-03	714	677	0	1	0	0	0	0	0	0	0	0	0	0	36
2012-04	654	622	3	1	1	0	0	0	0	0	0	0	0	0	27
2012-05	654	596	20	4	0	0	0	0	0	0	0	0	0	0	34
2012-06	658	615	5	1	0	0	0	0	0	0	0	0	0	0	37
2012-07	685	634	13	7	1	0	0	0	0	0	0	0	0	0	30
2012-08	674	615	13	2	0	0	0	0	0	0	0	0	0	0	44
2012-09	791	727	15	2	1	0	0	0	0	0	0	0	0	0	46
2012-10	781	721	12	0	3	0	0	0	0	0	0	0	0	0	45
2012-11	900	813	18	5	3	0	0	0	0	0	0	0	0	0	61
2012-12	2915	2748	11	1	0	1	0	0	0	0	0	0	0	0	154
2013-01	2575	2381	55	1	0	0	0	0	0	0	0	0	0	0	138
2013-02	1857	1615	114	7	0	0	1	0	0	0	0	0	0	0	120
2013-03	2094	969	768	179	23	0	0	0	0	0	0	0	0	0	155
2013-04	1404	1251	57	5	1	0	0	0	0	0	0	0	0	0	90
2013-05	879	718	73	25	15	0	0	0	0	0	0	0	0	0	48
2013-06	1116	781	177	49	34	1	0	0	0	0	0	0	0	0	74
2013-07	1198	1034	27	49	28	0	0	0	0	0	0	0	0	0	60
2013-08	1144	983	86	13	0	0	0	0	0	0	0	0	0	0	62
2013-09	1168	493	475	78	47	6	0	0	0	0	0	0	0	0	69
2013-10	1174	325	487	210	29	31	0	0	0	0	0	0	0	0	92
2013-11	1183	254	303	447	27	56	0	0	0	0	0	0	0	0	96
2013-12	978	557	274	40	21	12	0	0	0	0	0	0	0	0	74
2014-01	971	870	8	5	13	18	1	0	0	0	0	0	0	0	56
2014-02	1051	905	25	13	19	26	2	0	0	0	0	0	0	0	61
2014-03	1127	438	548	36	17	7	0	0	0	0	0	0	0	0	81
2014-04	676	489	136	4	0	0	0	0	0	0	0	0	0	0	47
2014-05	607	542	13	1	0	0	0	0	0	0	0	0	0	0	51
2014-06	404	381	0	1	0	0	0	0	0	0	0	0	0	0	22
2014-07	664	638	1	0	0	0	0	0	0	0	0	0	0	0	25
2014-08	864	813	3	2	0	0	0	0	0	0	0	0	0	0	46
2014-09	993	906	15	13	5	0	0	0	0	0	0	0	0	0	54
2014-10	1040	950	37	2	1	0	0	0	0	0	0	0	0	0	50
2014-11	1017	927	27	10	5	1	0	0	0	0	0	0	0	0	47
2014-12	1053	999	11	8	0	0	0	0	0	0	0	0	0	0	35
2015-01	1388	1342	4	0	0	0	0	0	0	0	0	0	0	0	42
2015-02	1477	1378	64	2	0	0	0	0	0	0	0	0	0	0	33
2015-03	1512	712	574	156	1	0	0	0	0	0	0	0	0	0	69
2015-04	1493	1254	142	2	0	0	0	0	0	0	0	0	0	0	95
2015-05	1457	835	180	358	2	0	0	0	0	0	0	0	0	0	82
2015-06	1107	411	348	261	2	0	0	0	0	0	0	0	0	0	85
2015-07	1162	1047	29	5	2	0	0	0	0	0	0	0	0	0	79
2015-08	1269	1114	37	35	0	0	0	0	0	0	0	0	0	0	83
2015-09	1780	1661	21	5	0	0	0	0	0	0	0	0	0	0	93
2015-10	1904	1800	4	1	0	0	0	0	0	0	0	0	0	0	99
2015-11	1716	1587	10	3	0	0	0	0	0	0	0	0	0	0	116
2015-12	1453	1343	3	2	0	0	0	0	0	0	0	0	0	0	105
2016-01	1494	1261	134	1	0	0	0	0	0	0	0	0	0	0	98
2016-02	1440	1357	1	1	0	0	0	0	0	0	0	0	0	0	81
2016-03	1446	1317	12	2	0	0	0	0	0	0	0	0	0	0	115
2016-04	1366	1266	2	0	0	0	0	0	0	0	0	0	0	0	98
2016-05	1953	1793	34	1	0	0	0	0	0	0	0	0	0	0	125
2016-06	1642	1521	14	3	0	0	0	0	0	0	0	0	0	0	104
2016-07	1457	1057	217	9	0	0	0	0	0	0	0	0	0	0	174
2016-08	1174	1058	16	0	0	0	0	0	0	0	0	0	0	0	100
2016-09	1347	1219	12	2	0	0	0	0	0	0	0	0	0	0	114
2016-10	1430	1243	34	0	0	0	0	0	0	0	0	0	0	0	153
2016-11	1549	363	626	365	0	0	0	0	0	0	0	0	0	0	195
2016-12	1441	414	238	630	1	0	0	0	0	0	0	0	0	0	158
2017-01	1726	210	209	820	282	3	0	0	0	0	0	0	0	0	202
2017-02	1299	1112	83	10	0	2	0	0	0	0	0	0	0	0	92
2017-03	1725	1094	376	28	26	12	2	0	0	0	0	0	0	0	187
2017-04	1277	578	156	340	25	6	0	0	0	0	0	0	0	0	172
2017-05	1362	949	217	90	2	0	0	0	0	0	0	0	0	0	104
2017-06	1186	701	186	108	27	5	0	0	0	0	0	0	0	0	159
2017-07	1145	462	133	418	4	0	0	0	0	0	0	0	0	0	128
2017-08	1056	660	252	32	5	0	0	0	0	0	0	0	0	0	107
2017-09	1276	916	173	33	36	1	0	0	0	0	0	0	0	0	117
2017-10	1618	1180	256	26	25	1	0	0	0	0	0	0	0	0	130
2017-11	1807	321	133	144	248	750	0	0	0	0	0	0	0	0	211
2017-12	1484	168	117	105	440	509	0	0	0	0	0	0	0	0	145
2018-01	1770	1107	229	116	86	38	0	0	0	0	0	0	0	0	194
2018-02	1560	455	93	199	126	504	12	18	2	0	0	0	0	0	151
2018-03	1792	179	44	60	101	1112	53	16	1	0	0	0	0	0	226
2018-04	1585	159	51	38	728	395	16	2	0	0	0	0	0	0	196
2018-05	1723	166	52	91	1155	60	17	0	0	0	0	0	0	0	182
2018-06	1361	405	154	269	387	43	2	0	0	0	0	0	0	0	101
2018-07	1668	1353	82	43	76	12	1	1	1	0	0	0	0	0	99
2018-08	1735	535	453	473	32	65	4	4	2	0	0	0	0	0	167
2018-09	1809	1451	48	61	87	27	18	6	3	0	0	0	0	0	108
2018-10	2040	809	156	549	222	69	14	17	0	0	0	0	0	0	204
2018-11	2131	418	47	87	547	671	108	15	0	0	0	0	0	0	238
2018-12	1745	151	59	35	57	234	717	289	3	0	0	0	0	0	200
2019-01	2251	205	36	44	63	91	317	612	582	4	2	0	0	0	295
2019-02	1616	158	22	15	39	77	227	388	317	172	5	4	0	0	192
2019-03	1762	111	39	47	28	243	299	26	165	129	409	37	0	0	229
2019-04	2375	177	10	6	95	741	95	183	11	5	644	153	6	0	249
2019-05	2261	142	23	39	181	82	624	70	28	29	105	293	133	283	229
2019-06	1348	202	26	7	14	317	4	122	28	30	90	75	0	295	138
2019-07	1412	128	65	155	187	9	2	131	153	97	88	0	0	243	154
2019-08	383	17	9	0	8	30	68	84	12	18	0	0	0	86	51
2019-09	373	58	13	13	11	54	82	13	14	0	0	0	0	80	35
2019-10	358	21	3	15	71	85	27	22	0	0	0	0	0	59	55
2019-11	316	72	23	36	28	46	13	0	0	0	0	0	0	66	32
2019-12	251	52	13	42	45	23	0	0	0	0	0	0	0	63	13
2020-01	201	28	15	17	0	0	0	0	0	0	0	0	0	132	9

@Stwalkerster: That is pretty much what I initially asked for, but after thinking about it, it is much more than what we need for our "new users." See my comment above dated 19:48, 17 January 2020 (UTC). Users who will be affected by the backlog really need an estimate of how long they will have to wait. Firehosing them with the data that backs up that estimate is going to be overkill. davidwr/(talk)/(contribs) 18:56, 21 January 2020 (UTC)

third reason

You get here from Wikipedia:Why create an account via Wikipedia:Why_create_an_account?#Blocked?. It makes sense to acknowledge that since we specifically encourage IP editors to sign up. Cheers CapnZapp (talk) 11:33, 20 February 2020 (UTC)

Confirmation

Confirming my doppelganger account creation request. Ref #287705 — BillHPike (talk, contribs) 16:15, 24 February 2020 (UTC)

Done ‑‑ElHef (Meep?) 16:51, 24 February 2020 (UTC)

Progress

The backlog in the main queue is down under 1,000! (Ok, at the moment it's at 999, but still...) ‑‑ElHef (Meep?) 21:20, 2 March 2020 (UTC)

Kudos to the ACC gang! Nosebagbear (talk) 21:25, 2 March 2020 (UTC)

Special kudos to ElHef, Dreamy Jazz, and JJMC89 who have all done over 50 requests in the last 28 days. If non-ACCers are interested in following how we're doing, there are some graphs here: [1] Though we're back to 1003 in the main queue now... stwalkerster (talk) 00:36, 3 March 2020 (UTC)

Thank you

Thank you ACC members that got the backlog to 0! --MrClog (talk) 17:08, 16 April 2020 (UTC)

Pinging JJMC89, ElHef, Mdaniels5757, Rich Smith, Stwalkerster among others who helped out reducing the backlog. Great job all! -- LuK3 (Talk) 18:41, 16 April 2020 (UTC)

Great job everyone! I started out with a backlog well over 4k requests, I never thought we'd get caught up this quickly! ‑‑ElHef (Meep?) 19:58, 16 April 2020 (UTC)

Awesome, thanks all! Now, let's try and keep the queue low! For those without tool access, there's a few stats pages which are still publicly accessible, including this one, which might be of interest to those giving kudos :D stwalkerster (talk) 20:38, 16 April 2020 (UTC)

This was fantastic work by each of you - it was the longest wikipedian backlog I'd seen when I first saw it, and bluntly I didn't think any significant reduction could be made, so that's seriously impressive. Nosebagbear (talk) 20:41, 16 April 2020 (UTC)

Yes, great job guys. You pulled off what seemed to be nothing short of an impossible task. Seriously impressive work. ~Swarm~ ^{sting} 03:20, 17 April 2020 (UTC)

Wow, I need to get my numbers up :) - - Rich^T|C|E-Mail 12:35, 17 April 2020 (UTC)

For those without tool access: here are some graphs for the last year, 3mo, 2 weeks, and 1 week. Mdaniels5757 (talk) 21:47, 17 April 2020 (UTC)

Confirmation

Confirming my doppelgänger account creation requests. ACC requests #294749 and #294750. ~SS49~ {talk} 15:46, 29 August 2020 (UTC)

Done ‑‑ElHef (Meep?) 16:03, 29 August 2020 (UTC)

Confirming request

I made a request that was replied to asking that #295813 be added here. Further response in email. Best, Usedtobecool ☎️ 07:16, 3 October 2020 (UTC)

Done ‑‑ElHef (Meep?) 12:07, 3 October 2020 (UTC)

Confirming Request

I am confirming my doppleganger request - ACC request #297460. P,TO 19104 (talk) (contribs) 16:39, 24 November 2020 (UTC)

Done ‑‑ElHef (Meep?) 17:10, 24 November 2020 (UTC)

Doppelgänger a/c conformation

@ElHef: Hello, and thanks for your quick response. Here's my confirmation from my main (current) account - SodhakSH (excuse the signature) - My ACC request number is #301091 and my e-mail is sodhak2227sh.wiki@hotmail.com. Regards, 🔥शब्दशोधक🔥 02:04, 13 March 2021 (UTC)

Done. ‐‐1997kB (talk) 13:49, 13 March 2021 (UTC)

Proposing this page be completely rewritten

This seems to be a page for people who are actually having a hard time creating an account, or for whom something has already gone wrong. We point people here from Wikipedia:Request directory. I don't think this how we want to present how much time and work it takes to request an account when we can instead just point them at Special:CreateAccount? And there's even an intervening page in between.

Should we rewrite this page to just address the problems some few people have requesting an account, and on the Request directory have two links, one to CreateAccount, the other to this page, renamed to something like Troubleshooting Account Creation? —valereee (talk) 15:33, 18 March 2021 (UTC)

This is pretty essential for users who are unable to use Special:CreateAccount and need to go through WP:ACC so I'm not really sure I see what you're getting at or what the problem is. VAXIDICAE💉 17:07, 18 March 2021 (UTC)

valereee, this isn't a troubleshooting page, but the landing page for people who have to go through the ACC procedure when they can't create an account themselves, usually because of IP (range-)blocks or CAPTCHA issues – the requests get vetted, CU may be used to confirm that we're not dealing with the block target, and we create if they're cleared. Given that the header currently points to Special:CreateAccount (This page is for requesting a Wikipedia account be created for you in the event that you are unable to create one yourself using the signup page.) and that the Wizard points there as an alternative at basically every turn, I think this is fine as is. Blablubbs|talk 17:24, 18 March 2021 (UTC)

@Blablubbs, @Praxidicae, but (hahahaha...just got the vaxidicae!) we're linking to it from Wikipedia:Request directory with simply:

Requesting an account – a place where users may request an account be created for them.

My concern is that we should be pointing people to CreateAccount unless they've already tried and failed and now need help. Pointing them there right off the bat just seems counterproductive. We even deal with that fact, pointing them through multiple pages to get them to createaccount eventually. Why not just offer createaccount right up front?

Maybe a change at request directory like:

Requesting an account – a place where users for whom Special:CreateAccount hasn't worked may request an account be created for them. —valereee (talk) 17:40, 18 March 2021 (UTC)

I think perhaps you might be missing the point of the process and how it works. It says "you can create an account for yourself" if a user winds up here, if that doesn't work, we don't need more hoops or bureaucracy to get them to ACC. There is no "CreateAccount" option for certain types of IP blocks, which tends to be what we're creating accounts for. "Unless they've already tried" is redundant and useless if, say, someone is on a blocked range. VAXIDICAE💉 17:42, 18 March 2021 (UTC)

valereee if you open an incognito window, turn on a VPN and try to create an account and you'll be able to see (and experience) why this is set up the way that it is. VAXIDICAE💉 17:44, 18 March 2021 (UTC)

@Praxidicae, well, I'll take your word for it. I just was very surprised when I clicked on request an account, thinking it would take me straight to createaccount, and discovered a very long page of instructions. We don't think someone might get here by accident, see the long list of instructions, and go 'screw it, creating an account on WP looks like an ordeal'? —valereee (talk) 17:59, 18 March 2021 (UTC)

@Valereee: This is more of a structural issue with how people wind up at ACC than it is a problem with ACC itself. It's also not just an issue with WP:RQ. Take a look at zzuuzz's comment near the end of this discussion. As I understand it, in large part this is why the ACC wizard was put in place last year, to provide some troubleshooting before actually having them make a request, and deflect some of the people who thought ACC was the "correct" way to get an account.

That said, I'm sure you're right that there are people out there that thought ACC was the place to be and got frustrated by a wall of text and walked away. I'd personally support a change to the ACC pointer at RQ along these lines: "A place where users having trouble creating an account may request an account be created for them." There's just plenty of other places that need similar overhauls. ‑‑ElHef (Meep?) 18:44, 18 March 2021 (UTC)

Confirming request

I am confirming doppleganger request - ACC #300447. power~enwiki (π, ν) 17:54, 2 March 2021 (UTC)

On hold pending completion of the rename request. ‑‑ElHef (Meep?) 19:10, 2 March 2021 (UTC)

Done ‐‐1997kB (talk) 03:08, 23 March 2021 (UTC)

Spoken version/instructions length

Given that part of the purpose of this page is to cover accessibility by helping out editors unable to complete a captcha, I'd think we'd want to create a WP:Spoken version of the instructions. But if we did that right now, the spoken version would probably be 15 minutes long. And it's really not accessible when you have to spend that long listening (or reading through) instructions to get an account. Could we simplify the instructions to make them short enough that users actually read them? {{u|Sdkb}} ^talk 02:03, 28 April 2021 (UTC)

Agreed. The wizard covers some of this material in a more friendly way before allowing a user to reach the request form, so maybe some of it could be trimmed from this page. the wub "?!" 20:48, 23 May 2021 (UTC)

What a difference a year makes

A year ago we finally knocked the main queue down to zero, where it still is today! One-year graph Two-year graph Kudos to JJMC89, Stwalkerster, Blablubbs, LuK3, AmandaNP, JavaHurricane, and everyone else who's worked to keep this under control! ‑‑ElHef (Meep?) 14:07, 17 April 2021 (UTC)

Great work to the ACC tool users, including CheckUsers and stewards. It's always nice to see the main queue with 0 requests so often. -- LuK3 (Talk) 03:11, 18 April 2021 (UTC)

Just noting that the links to the graphs are not working. Is this intentional? Dreamy Jazz ^{talk to me | my contributions} 20:58, 23 May 2021 (UTC)

Vaguely. I intentionally disabled the display of them a few weeks ago as part of debugging; I've not yet had chance to re-enable them. stwalkerster (talk) 22:57, 23 May 2021 (UTC)

ACC request confirmation

ACC request number #311043. Thank you. $8^talk2me 17:11, 5 November 2021 (UTC)