Page MenuHomePhabricator

Create a process for raising editing rate limits similar to the six account exceptions (throttle.php)
Closed, ResolvedPublic

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

  1. Which technical solution (A, B, C or other) should be choosen
  2. If this should be a standard part of throttle.php rule or separate exception

Event Timeline

Urbanecm created this task.Sep 17 2018, 6:57 PM
Restricted Application added a project: User-Urbanecm. · View Herald TranscriptSep 17 2018, 6:57 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Urbanecm moved this task from Backlog to Own projects on the User-Urbanecm board.Sep 18 2018, 2:49 PM
Urbanecm moved this task from Own projects to Created on the User-Urbanecm board.Sep 19 2018, 5:29 AM
Sau226 updated the task description. (Show Details)Oct 18 2018, 1:30 PM

Change 518298 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] [throttle-analyze] Grant autoconfirmed permission to user when throttle rule is applied

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

I've tested B) locally, and looked into relevant parts of MediaWiki to learn what it'll do. Seems granting autoconfirmed to user group does the following:

  1. separates coutning rate limits for each individual user
  2. uses 'user' edit limit, instead of 'newbie' (user gets higher rate limits, currently 90 edits/minute)

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.

Change 518298 merged by jenkins-bot:
[operations/mediawiki-config@master] [throttle-analyze] Grant autoconfirmed permission to user when throttle rule is applied

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

Mentioned in SAL (#wikimedia-operations) [2019-07-03T11:11:25Z] <urbanecm@deploy1001> Synchronized wmf-config/throttle-analyze.php: SWAT: [[:gerrit:518298|[throttle-analyze] Grant autoconfirmed permission to user when throttle rule is applied]] (T204583) (duration: 00m 49s)

Urbanecm closed this task as Resolved.Jul 3 2019, 11:12 AM
Urbanecm claimed this task.

Done. Everything in throttle.php now has also higher rate limits. Going to update the docs.

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."

I've also tried to clarify the docs a bit, and fix some of the bad/old translation markup. (https://meta.wikimedia.org/wiki/Mass_account_creation)

Urbanecm added a comment.EditedJul 4 2019, 7:17 PM

Sounds good to me, @Quiddity! Thanks for the docs fixes.