Description

On some outreach events (primarily courses), the newbie limit for saving (8 edits/minute, applied to all newbies from same IP) is blocking normal work (one example).

We currently have throttle.php (https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/throttle.php). This file can temporarily raise the six account limit, but does not raise editing limit. Thus it leave event organizers to solve this as well, probably by letting the participants wait. This is in strong contrast when compared with "Anyone can edit" slogan. We should either make throttle.php raise editing limits (by one of solutions described below) or create other file working similar to the throttle.php file managing the editing rate limit. In longterm, this should be all managed on wiki, but there is other task for this. This is short-term/mid-term solution.

A) Set wgAutoConfirmAge and wgAutoConfirmCount to 0

Everybody editing from that IP would qualify as autoconfirmed user and thus no newbie limits will be applied. This will have side effects like allowing everybody with an account editing from that IP to move/perform other actions restricted to autoconfirmed users. It can make experienced users confused, because non-autoconfirmed user is moving.

B) Grant autoconfirmed to all registered account editing from that IP.

I'm not sure how this behave. The description of the right ("Not be affected by IP-based rate limits") says to me it is a possible solution, but probably more experienced mediawiki guys should look on this.

C) Raise wgRateLimits['newbie']['edit'] and wgRateLimits['ip']['edit'] for everybody from that IP

This will do just the proposed thing. Still, limits will be counted together for the IP, so theoretically one participant can slow down the other one, but it can work. An example: Event with 10 participants, instructor shows how to edit sandbox and participants do what instructor does. There will be presumably one edit per participant. Then, instructor says "try to make one or two other edits". This will lead to max 3 edits per participants. If we allow numberOfParticipants*3 edits per minute, it should be probably enough for most events.

To discuss

Which technical solution (A, B, C or other) should be choosen

If this should be a standard part of throttle.php rule or separate exception

Theoretically, only the first thing would be truly something the user might face only on events, but since outreach program users are usually trusted enough to have higher rate limits, and it's not probable user will ever notice the difference in edit limits, it's probably safe to just enable it.

A patch that'll use existing throttle.php for definitions is above. Since most courses would probably need both, it's probably okay. Reviews and thoughts appreciated.

Maybe also warrants an User-notice. The usernotice text can say something like (edits welcomed!) "Previously, it was possible only to request an exemption from six-account limit. The same exemption process now also raises edit rate limits, which was an often bottleneck at outreach events.".

@Urbanecm How about this for the usernotice? "For event organizers, if you [[m:Mass_account_creation#Requesting_temporary_lift_of_IP_cap | request a temporary lift of the IP cap]] for mass account creation, this will now also raise the edit rate limit for those new accounts at the event, which will prevent another bottleneck."