Note account creation itself is also rate limited and some guide may be provided if the IP can create no more accounts currently.

Maybe just block them?

At the high end (as in more account creation attempts) there are long term vandals/abusers (a.k.a. LTA's), editathons (scheduled mass gatherings of people editing WMF sites) and countries with limited number of IP's versus population (like some African countries - https://afrinic.net/ip-address-and-asn-allocations-in-africa). LTA's are blocked anyway and editathons usually have short ip rate limit exemptions. Also the difference between LTA's and editathons, is that LTA's go through many IP's (sometimes more than 10 per month), editathons do not. I do not know how the whole countries with limited number of IP's goes, I have no experience with it.

Was considering adding logged-out bots to the mix, but they do not frequently clear their cookies or change their IP's. Proxies might be in this list, but there are allready some blocked.

At the low end (as in less account creation attempts) there are schools and libraries. They also do not go through many IP's.

@KStoller-WMF this seems like something worth keeping an eye on towards the goal of "getting more new editors with accounts, especially those that were willing to edit previously"-aspect of our overall goals of "getting more editors". Though, as @kostajh said, this is probably not directly actionable and also likely needs some kind of designs first.

I was looking at this section of code yesterday, in TempUserCreator.php:

// TODO: Use a custom message here (T357777, T357802)
$message = wfMessage( 'acct_creation_throttle_hit' )->params( $result['count'] )
  ->durationParams( $result['wait'] );

Currently, we show the message for acct_creation_throttle_hit which is this in MediaWiki core:

Visitors to this wiki using your IP address have created {{PLURAL:$1|1 account|$1 accounts}} in the last $2, which is the maximum allowed in this time period.
As a result, visitors using this IP address cannot create any more accounts at the moment.

and this in WikimediaMessages:

Visitors to this wiki using your IP address have created {{PLURAL:$1|1 account|$1 accounts}} in the last day, which is the maximum allowed in this time period.
As a result, visitors using this IP address cannot create any more accounts at the moment.
If you are at an event where contributing to Wikimedia projects is the focus, please see [[m:Mass account creation#Requesting_temporary_lift_of_IP_cap|Requesting temporary lift of IP cap]] to help resolve this issue.

I think for the purposes of task, we should come up with a message that is more relevant to temporary accounts, and provides a link to Special:CreateAccount.

Note the monitoring of rate limits mentioned above has been shifted to the Grafana ticket https://phabricator.wikimedia.org/T357763
The relevant graph can be seen at https://grafana.wikimedia.org/d/e293b3fd-032f-4915-a6c0-72b6062d66b5/temporary-accounts?orgId=1&viewPanel=11

This needs some design / product specification before we can bring it to review with Stewards.

In T357802#10500741, @kostajh wrote:

This needs some design / product specification before we can bring it to review with Stewards.

@Tchanders @Niharika @KColeman-WMF it would be good to do this before global rollout, IMHO.

@KStoller-WMF Do you have thoughts on this task?

It looks like this is happening regularly, but not at incredibly high rates. However, I imagine this will change as we scale temp accounts to more wikis.

From my perspective, I think it would be ideal if this is worked on, but the Growth team doesn't have the capacity to take on this work right now without deprioritizing our other annual plan work.

Let me know if this is something you think the Growth team needs to own, and I can discuss the priority with Product leadership to decide if the tradeoffs are worth putting off other work.

The UX for this right now is far from ideal

A separate i18n message for hitting the account throttle on account creation vs. temp account autocreation would be a trivial first step. AuthenticationProvider::testUserForCreation() gets a temp user creation flag, but permission-based checks don't, so that would require some hack (putting the flag in PermissionStatus, I suppose).

Never mind, apparently the throttling happens outside the normal autocreate flow. ThrottlePreAuthenticationProvider might have been a better place for it but don't need to fix it if it works, I guess.

As we approach the the full rollout of Temp Accounts, this is higher priority, but we'll need to decide on copy and UI before this is actionable by engineers.

In T357802#11263467, @kostajh wrote:

The UX for this right now is far from ideal

@kostajh a couple of clarifying questions before starting design explorations..

1. do we know how often is this limit being hit? is this a common problem or more of a edge case?
   1. i'm having a hard time interpreting this
2. are there legitimate use cases where multiple temp accounts from one IP might be needed? i'm thinking of events, workshops, edit-a-thons, classrooms, ...
3. how long does the rate limit last? will it always be 24h of will communities be able to specify that as well?
4. would it be possible for different people to hit this limit, or would this happen only for a specific non-logged editor? in other words, if multiple people share the same IP address (like in a school or office), would they all be blocked once any combination of them creates 6 temp accounts?
5. can we detect if the rate limit is already hit before non-logged editors click the edit button?
6. if the temp account rate limit is hit, we should only display the message.. it doesn't make sense to also show the warning message since a temp account can't actually be created anyway, right?
7. i'm assuming that we need to design something that works both as a full-width banner in source editor (like shown in your screenshot), and as a floating message in visual editor?
8. what happens if people try to edit (and publish) anyway? or it the editor "locked"?

cc @Niharika @KStoller-WMF

In T357802#11282065, @AAlhazwani-WMF wrote:

In T357802#11263467, @kostajh wrote:

The UX for this right now is far from ideal

@kostajh a couple of clarifying questions before starting design explorations..

1. do we know how often is this limit being hit? is this a common problem or more of a edge case?
   1. i'm having a hard time interpreting this

I sent some info via DM about this

1. are there legitimate use cases where multiple temp accounts from one IP might be needed? i'm thinking of events, workshops, edit-a-thons, classrooms, ...

Yes, but those should follow the established process for requesting a temporary exemption to rate limits (https://meta.m.wikimedia.org/wiki/Learning_patterns/Six-account_limit)

1. how long does the rate limit last? will it always be 24h of will communities be able to specify that as well?

There is currently a cap of 6 accounts per 24 hours, and also no more than 1 account per 10 minutes. (The latter is to make it more difficult for casual vandals to edit, clear their cookies, and edit again immediately.)

1. would it be possible for different people to hit this limit, or would this happen only for a specific non-logged editor? in other words, if multiple people share the same IP address (like in a school or office), would they all be blocked once any combination of them creates 6 temp accounts?

Yes, different people can trip this limit as long as they share the same IP address. While this is common in a small space (like a school, office, etc) it's worth noting that many countries have relatively few IP addresses per capita https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation, so it's fairly common for many unique individuals to appear to originate from a single IP address.

1. can we detect if the rate limit is already hit before non-logged editors click the edit button?

Not easily.

1. if the temp account rate limit is hit, we should only display the message.. it doesn't make sense to also show the warning message since a temp account can't actually be created anyway, right?

I'm not sure I understand, which warning message?

1. i'm assuming that we need to design something that works both as a full-width banner in source editor (like shown in your screenshot), and as a floating message in visual editor?

I was thinking that we might want to have a floating message / overlay for use in all scenarios, but I don't have a strong opinion. The main thing would be to make it easy and obvious to the user that going to Special:CreateAccount and registering an account would allow them to continue with their edit.

1. what happens if people try to edit (and publish) anyway? or it the editor "locked"?

Their edit won't go through. They'll get the same message again.

if the temp account rate limit is hit, we should only display the message.. it doesn't make sense to also show the warning message since a temp account can't actually be created anyway, right?

I'm not sure I understand, which warning message?

I assume this relates to the fact that we show the 🛑 red IP rate limit warning message, but also the yellow "⚠️ You are not logged in..." message.
If the rate limit is hit, then we should show that specific message and NOT show the yellow message, right?

In T357802#11283007, @kostajh wrote:

I sent some info via DM about this

thank you!

1. are there legitimate use cases where multiple temp accounts from one IP might be needed? i'm thinking of events, workshops, edit-a-thons, classrooms, ...

Yes, but those should follow the established process for requesting a temporary exemption to rate limits (https://meta.m.wikimedia.org/wiki/Learning_patterns/Six-account_limit)

my bad! i forgot to delete that question after looking at your screenshot more carefully!

I was thinking that we might want to have a floating message / overlay for use in all scenarios, but I don't have a strong opinion. The main thing would be to make it easy and obvious to the user that going to Special:CreateAccount and registering an account would allow them to continue with their edit.

i like this idea, will explore it!

thank you for all the other clarifications @kostajh.. this is useful info, and it helps me start exploring design ideas!

while working on T408011: Design Research: Prompt user to create a regular account after temp account creation rate limit trip we landed on this design and copy proposal..

given that in this specific scenario (when a person with a specific IP hits the temp account rate limit) it will be impossible for them to publish any edit as long as they don't create an account or log in, we suggest to "block" the editing experience with a modal.

we're also suggesting to use a modal to have a stronger separation of concerns between user-relevant information and article-relevant communications (like BLP notices among other things). we'd like to avoid situations like this one below where there are competing messages displayed at the same time.

our suggestion is to check whether the rate limit is hit while we load the editor.. and based on the result display (or not) the modal. we thought of two approaches where we present this modal potentially once (before the publish dialog) or twice (after the editor opens, and before the publish dialog).

show it once

show it twice

we can make a final decision on this during implementation to test this in a real environment. at the time of writing we're leaning towards showing twice so that people are aware before they invest time in editing, but we still give them the ability to edit if they want to then save their changes somewhere else or if they are simply testing things out.

we are also exploring a much more concise copy, clearly outlining what people need to to do proceed. it's not necessary to give too much background (technical) information as it doesn't really help people move forward.

Before	After

another decision to make during implementation is whether to hide the disclaimer inside an accordion, or if we should display it at all times.

With accordion	Without accordion

while making this decision we should keep in mind that english is usually much more concise compared to other languages like greek or malayalam (text has been translated with google translate, so take it with a grain of salt)

we acknowledge that this is a temporary solution, that will probably be affected by design decisions on T407497 (in the near-/mid-term) and on T409236 (in the mid-/long-term).

i've also created the eng task T410386: Prompt user to create a regular account after temp account creation rate limit trip