This would be very useful; and in training sessions run in-house by Wikimedians in Residence, too. I've had a lot of valuable training-time wasted dealing with the issues described.

Correct me if I am wrong, but this is what ThrottleOverride extension does. If not, let's just add these features to the extension. When a sysop sets an exception for certain IP addresses or ranges with an expiry time set, users from the IP address/range can bypass the default rate limits until the expiry time. By introducing a new userright instead of noratelimit, which the extension currently uses, we can take one step for getting this resolved.

Instead of developing a completely new extension for this, let's just improve the ThrottleOverride extension and get it deployed to Wikimedia projects. :)

That link didn't work, does the throttle override extension do all of the things that this would do, and does it have the same privacy compliant features to enable remote use, and also does it have the same temporary feature that would leave our anti spam and antivandalism filters working on all other IPs?

In T91928#1118918, @WereSpielChequers wrote:

That link didn't work,

Which link?

does the throttle override extension do all of the things that this would do,

If the extension doesn't have needed functionality, then we can add them, as I already said.

and does it have the same privacy compliant features to enable remote use,

I'm not sure whether the log should be private. Currently, we don't have a log in ThrottleOverride extension but what we've been doing on the mediawiki-config's throttle.php for years now has been public. Anyone can view the history of throttle.php and I haven't seen any privacy issues being raised regarding it.

and also does it have the same temporary feature that would leave our anti spam and antivandalism filters working on all other IPs?

Yes, only certain IP address/range are exempted. Currently, ratelimits can be bypassed for account creation, edits, moves and emails.

Change 196780 had a related patch set uploaded (by Glaisher):
Use a new right ('throttleoverride') instead of 'noratelimit'

https://gerrit.wikimedia.org/r/196780

How would "throttleoveride" be of use to event organisers, trainers, Wikimedians in Residence, etc, who are not sysops?

In T91928#1119065, @Pigsonthewing wrote:

How would "throttleoveride" be of use to event organisers, trainers, Wikimedians in Residence, etc, who are not sysops?

We can create a user group with the throttleoverride right as needed.

Change 196780 merged by jenkins-bot:
Use a new right 'throttleoverride' instead of 'noratelimit'

https://gerrit.wikimedia.org/r/196780

Reopened - this is not resolved by "throttleoverride", according to https://lists.wikimedia.org/pipermail/wikimedia-l/2015-June/078309.html

Please credit me with some intelligence. This has nothing to do with "deployment to WMF sites". The proposed solution /when deployed/ will not not resolve the issue described.

Why not?

In T91928#1382241, @Pigsonthewing wrote:

Please credit me with some intelligence. This has nothing to do with "deployment to WMF sites". The proposed solution /when deployed/ will not not resolve the issue described.

ThrottleOverride extension is not deployed into WMF cluster. So you won't see this on wikimedia wikis.

There is a throttle setting that is overridden of WP:EN, specifically to allow the use of mass rollback/undo. Perhaps this same mechanism could be applied here.

In T91928#1385429, @Rich_Farmbrough wrote:

There is a throttle setting that is overridden of WP:EN, specifically to allow the use of mass rollback/undo. Perhaps this same mechanism could be applied here.

Please open a new bug for new suggestion.

In T91928#1504522, @WereSpielChequers wrote:

I've reopened this and changed it to stalled

Actually you removed the status "stalled" by setting the status to "open"...

Good idea.

So what is this report now, a request to enable the extension in Wikimedia? Literally speaking, "The Event Organiser's Userright" is already fixed in Wikimedia by the account creator group.

The "account creator" right (which I hold, for en.WP) does not do the same thing.

does not do the same thing.

What is missing? If you literally mean the user should be able to *alter* $wgRateLimits, this is a duplicate of T28992.

In T91928#1940126, @Nemo_bis wrote:

What is missing? If you literally mean the user should be able to *alter* $wgRateLimits, this is a duplicate of T28992.

Having a way to alter $wgRateLimits for a specific IP on a specific project does not have to involve a full implementation of T28992. Yes, it would mean code modifications, and any solution we implement would need to have a security and performance review, but it could probably be done without implementing the full config database described in T28992.

Quoting mw:Mass_account_creation#Requesting_temporary_lift_of_IP_cap:

While those with account creator permission can create accounts for people at events, there are sometimes situations where it would be preferable to open an IP to permit on-site individual creation of these accounts, such as at a GLAM event, without needing to login with a privileged account. Allowing people to create their own accounts may help them feel more engaged.

There doesn't necessarily need to be a new user right, but allowing those with the account-creator right to also be able to perform temporary IP address cap lifts would be a huge win for event organizers who have the account-creator right.

In T91928#1940391, @RobLa-WMF wrote:

Quoting mw:Mass_account_creation#Requesting_temporary_lift_of_IP_cap:

That's not [[mw:]] but [[m:]], it's not MediaWiki documentation but some users' opinion.

While those with account creator permission can create accounts for people at events, there are sometimes situations where it would be preferable to open an IP to permit on-site individual creation of these accounts, such as at a GLAM event, without needing to login with a privileged account. Allowing people to create their own accounts may help them feel more engaged.

As you quote this largely incorrect paragraph, I guess it's a danger for public knowledge to let it stay: fixed. https://meta.wikimedia.org/w/index.php?title=Mass_account_creation&type=revision&diff=15270602&oldid=14734061

As I see, the ip limit removing for saving is not needed as the participant of an event should create an account.

In which condition there is a captcha when you are adding an external link (I believed it was only for ip) ?

Hi Xcombelle, it isn't just IP editors who have to do a capcha each time they add a link. On English Wikipedia it is also accounts that have not yet been autoconfirmed, ie less than ten edits or less than four days. In practice that means almost all trainees at outreach events. But the trainers don't have the same issue unless we create a new training account for each event, and I doubt anyone does that.

The limit for saving is not just IPs. If it was just IPs we could resolve things just by getting people to create accounts. The problem is it is IPs and accounts that are not yet autoconfirmed. If you have two trainers one of whom is an admin then you can get round this by having the admin set people's accounts as autoconfirmed. But admins are scarce, an extra trainer for each event is a big overhead, and it is embarrassing having to explain that the way we run training events is based on mediawiki having such problems.

Here is a write up from an outreach event in Mexico where they simply had too many people to even try and get them to create accounts due to the IP throttle problems with mediawiki. So the problem is in ES as well as EN, Swedish and so forth.

Without this userright outreach simply doesn't scale.

I'll note that it is now possible to exempt specific IPs (and users logged-in from those IPs) from having to submit captcha by listing the IP addresses or IP ranges at MediaWiki:Captcha-ip-whitelist on the wiki. I realize that it doesn't meet the requirements of this task because only sysops (and others who are allowed to edit interface pages) can edit these pages but at least it is better than how it was previously and I encourage organizers to make use of it (by requesting sysops to add the IPs there) for a better experience for participants.

In T91928#1382241, @Pigsonthewing wrote:

Please credit me with some intelligence. This has nothing to do with "deployment to WMF sites". The proposed solution /when deployed/ will not not resolve the issue described.

In T91928#1504515, @WereSpielChequers wrote:

[...]this development is not the same as the one it was incorrectly conflated with.

I honestly don't think there's someone trying to annoy you here, but it's just not clear what you're asking for. The task description and comments given here lead me to the impression that Extension:ThrottleOverride would indeed solve the problem you're trying to get rid of. If that's not true, could somebody please describe what's the actual difference here?

What Extension:ThrottleOverride is aiming for is to provide a special page to users who hold the right "throttleoverride". That right might be given to admins, account creators or some new group - whatever fits your purposes best. Whether you'd call that right "Event Organiser's Userright" or something else doesn't matter.

On that special page you'd have to input

1. which IP addresses(es) to exempt ( just google "what is my ip" will do it once you arrived at the location and are connected to their network)
2. point in time when the exemption of throttles starts (this is not implemented yet, currently one can only use "start right now"; T93468 tracks the implementation of this)
3. point in time when the exemption of throttles ends (expiration)
4. reason (as with blocks, providing some information which will be shown in the log)
5. a number of checkboxes to select which throttles the ip addresses should be exempted from (for example account creation, page edits, page moves etc.)

Again calling it "IP addresses to exempt" or "event ip" is of no difference.

While an IP address is an ''Event IP'':

1. There is no limit to the number of accounts created from that IP address. However many people attend your outreach event they can all create accounts.

In Extension:ThrottleOverride, marking the "account creation" checkbox will do that.

2. There is no limit to the number of IP/unconfirmed editor edits per minute from that IP address. So the course leader can say "all hit save now" without the current situation of 6 successful saves and the rest of the class needing help.

Checkbox "page edits" will do that.

3. The capcha requirement for adding external links is waived. So you can train newbies to reference their edits without them being required to complete a capcha.

This is currently not part of Extension:ThrottleOverride, but of course including it there is a reasonable request. I've created T174225 for that.

24 hours after an IP has been set as an ''event IP'' the status lapses.

Just set the expiration to "1 day" or "24 hours".

Logging
Only Checkusers and Oversighters would have access to the log showing which IP addresses had been flagged as ''Event IP''s. So flagging an IP that someone else has used as an ''Event IP'' wouldn't be a sneaky to identify the IP someone uses.

Removing the throttles is currently done a configuration file. That file as well as it's whole history are viewable for everybody for at least 5 years. Personally I'm not aware of any reason why we shouldn't continue to have this log visible to the public. Besides the question who'll be able to view that log, it's obvious that we'll need such a log in the first place. There is T62421 to integrate that functionality in Extension:ThrottleOverride.

IP Throttles
The three throttles that the userright avoids are all designed to make life difficult for spammers, vandals and unsupervised classrooms of children. This userright only makes tiny and temporary gaps in these very important throttles.

Only the IP addresses that are exempted from the throttle get special treatment, for other IPs nothing will change. Admins can remove throttle exemptions that are abused at any time (and of course they still could block users).

Rights Allocation
As with other user rights this would by default be included in the administrators toolset and be allocated to others by administrators.

As mentioned above, we can assign the right "throttleoverride" to any user group that is preferred and/or assign it to a separate user group and enable bureaucrats/admins to add/remove users to/from that group.

Endorsements
And of course one of the biggest reasons for having this userright is that it can be done during the setup period before the participants start to arrive, thus freeing up trainer time for actually getting people to do useful edits.

So you'd arrive at the event, google "what is my ip", copy that address and paste it into Special:OverrideThrottle, fill out the rest of the form and hit "submit". The throttle would be gone instantly.

This proposal is for a 24 hour unthrottling for the event, if you really think this could be a problem it should be possible to code the right so the window was a number of hours set by the person with that right with a start and end time that only covers the event. But a preset 24 hours seems to me simpler and a reasonable window.

Extension:ThrottleOverride as it is today asks to set any expiration time one chooses, in the same was Special:Block asks for a expiration. There's not much point in removing the flexibility of users being free to choose whatever expiration they like.

Note: All of what's described here would only apply once Extension:ThrottleOverride is deployed to WMF cluster - which it is currently not, as it is still lacking basic features (logging, deleting throttles, changing throttles) and - after that features have been integrated - still needs a security review (T27000).

Relevant discussion at enwp:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Create_a_new_Event_Coordinators_user_group

In T91928#3555132, @EddieGP wrote:

In T91928#1382241, @Pigsonthewing wrote:

The proposed solution /when deployed/ will not not resolve the issue described.

[removing captchas] is currently not part of Extension:ThrottleOverride

Thank you for confirming that my statement "The proposed solution /when deployed/ will not not resolve the issue described" is true.

I've created T174225 for that.

And thank you for that also.

In T91928#3623998, @Pigsonthewing wrote:

Thank you for confirming that my statement "The proposed solution /when deployed/ will not not resolve the issue described" is true.

The "proposed solution" is, and was from the very beginning (as suggested in T91928#1118877 and T91928#1118936) to do both

• deploy Extension:ThrottleOverride (which includes developing all the features necessary to do so)

and

• add missing features to that extension

The "issue described" means the three bullet points in the task description. #1 and #2 would be resolved by deploying ThrottleOverride (T27000) and #3 would be resolved by adding another feature to ThrottleOverride (it would have been senseful to create a specific task for that earlier; which, as I said, was now done with T174225).

So if you claim that "The proposed solution when deployed will not resolve the issue described" I can only try to describe why I think that's not true (which I've done now) and repeat Krenairs question (T91928#1382256):

Why not?