Wikipedia talk:Request an account/Archive 6

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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

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 periodTotal requestsClosed in 3 daysClosed in 7 daysClosed in 14 daysClosed in 1 monthClosed in 2 monthsClosed in 3 monthsClosed in 4 monthsClosed in 5 monthsClosed in 6 monthsClosed in 7 monthsClosed in 8 monthsClosed in 9 monthsClosed in 10 monthsClosed in 11 monthsClosed in 1 yearClosed in more than 1 yearRequests still openRequests dropped
2019-01104883179126441420262400000000136
2019-0216161582215397722738831717254000000192
2019-0317621113947282432992616512940937000000229
2019-0423751771069574195183115644153600000249
2019-0522611422339181826247028291052931330000283229
2019-0613482022671431741222830907500000295138
2019-07141212865155187921311539788000000243154
2019-0838317908306884121800000008651
2019-093735813131154821314000000008035
2019-1035821315718527220000000005955
2019-1131672233628461300000000006632
2019-122515213424523000000000006313
2020-0120128151700000000000001329
Extended data
Data periodTotal requestsClosed in 3 daysClosed in 7 daysClosed in 14 daysClosed in 1 monthClosed in 2 monthsClosed in 3 monthsClosed in 4 monthsClosed in 5 monthsClosed in 6 monthsClosed in 7 monthsClosed in 8 monthsClosed in 9 monthsClosed in 10 monthsClosed in 11 monthsClosed in 1 yearClosed in more than 1 yearRequests still openRequests dropped
2009-1018617900000000000000007
2009-11677660000000000000000017
2009-12587569000000000000000018
2010-01801777010000000000000023
2010-02785755000000000000000030
2010-03939902000000000000000037
2010-0411061079000000000000000026
2010-05998974000000000000000024
2010-06768742010000000000000025
2010-07735711100000000000000023
2010-08752735100000000000000016
2010-09929901000000000000000028
2010-10860828110000000000000030
2010-11829795000000000000000034
2010-12476451100000000000000024
2011-01653632000000000000000021
2011-02716693000000000000000023
2011-03735709000000000000000026
2011-04662625400000000000000033
2011-05704653200000000000000049
2011-06651619300000000000000029
2011-07923887210000000000000033
2011-08973924000000000000000049
2011-09897827810100000000000060
2011-10794752100010000000000040
2011-11923873000000000000000050
2011-12683646000000000000000037
2012-01854816000000000000000038
2012-02763717000000000000000046
2012-03714677010000000000000036
2012-04654622311000000000000027
2012-056545962040000000000000034
2012-06658615510000000000000037
2012-076856341371000000000000030
2012-086746151320000000000000044
2012-097917271521000000000000046
2012-107817211203000000000000045
2012-119008131853000000000000061
2012-122915274811101000000000000154
2013-012575238155100000000000000138
2013-0218571615114700100000000000120
2013-032094969768179230000000000000155
2013-04140412515751000000000000090
2013-05879718732515000000000000048
2013-0611167811774934100000000000074
2013-0711981034274928000000000000060
2013-08114498386130000000000000062
2013-0911684934757847600000000000069
2013-101174325487210293100000000000092
2013-111183254303447275600000000000096
2013-1297855727440211200000000000074
2014-0197187085131810000000000056
2014-0210519052513192620000000000061
2014-0311274385483617700000000000081
2014-0467648913640000000000000047
2014-056075421310000000000000051
2014-06404381010000000000000022
2014-07664638100000000000000025
2014-08864813320000000000000046
2014-0999390615135000000000000054
2014-1010409503721000000000000050
2014-11101792727105100000000000047
2014-1210539991180000000000000035
2015-0113881342400000000000000042
2015-02147713786420000000000000033
2015-0315127125741561000000000000069
2015-041493125414220000000000000095
2015-0514578351803582000000000000082
2015-0611074113482612000000000000085
2015-07116210472952000000000000079
2015-081269111437350000000000000083
2015-09178016612150000000000000093
2015-1019041800410000000000000099
2015-111716158710300000000000000116
2015-12145313433200000000000000105
2016-011494126113410000000000000098
2016-0214401357110000000000000081
2016-031446131712200000000000000115
2016-0413661266200000000000000098
2016-051953179334100000000000000125
2016-061642152114300000000000000104
2016-0714571057217900000000000000174
2016-081174105816000000000000000100
2016-091347121912200000000000000114
2016-101430124334000000000000000153
2016-11154936362636500000000000000195
2016-12144141423863010000000000000158
2017-0117262102098202823000000000000202
2017-021299111283100200000000000092
2017-0317251094376282612200000000000187
2017-041277578156340256000000000000172
2017-0513629492179020000000000000104
2017-061186701186108275000000000000159
2017-07114546213341840000000000000128
2017-0810566602523250000000000000107
2017-09127691617333361000000000000117
2017-101618118025626251000000000000130
2017-111807321133144248750000000000000211
2017-121484168117105440509000000000000145
2018-01177011072291168638000000000000194
2018-0215604559319912650412182000000000151
2018-0317921794460101111253161000000000226
2018-04158515951387283951620000000000196
2018-05172316652911155601700000000000182
2018-06136140515426938743200000000000101
2018-07166813538243761211100000000099
2018-0817355354534733265442000000000167
2018-0918091451486187271863000000000108
2018-1020408091565492226914170000000000204
2018-1121314184787547671108150000000000238
2018-1217451515935572347172893000000000200
2019-01225120536446391317612582420000000295
2019-0216161582215397722738831717254000000192
2019-0317621113947282432992616512940937000000229
2019-0423751771069574195183115644153600000249
2019-0522611422339181826247028291052931330000283229
2019-0613482022671431741222830907500000295138
2019-07141212865155187921311539788000000243154
2019-0838317908306884121800000008651
2019-093735813131154821314000000008035
2019-1035821315718527220000000005955
2019-1131672233628461300000000006632
2019-122515213424523000000000006313
2020-0120128151700000000000001329
@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 :) - - RichT|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:
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:
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. $8talk2me 17:11, 5 November 2021 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Request_an_account/Archive_6&oldid=1208737498"