Maniphest T194864

Raise the rate limit for autopatrollers on Commons
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Zhangj1079
	May 17 2018, 12:01 AM

Description

Recently, system administrators installed a very low rate limit of 90 edits for 1 minute.

On Commons, this is a very low rate, in a very crippling way. Quite frequently, editors will use tools to edit en masse, often times more than 90 files. Tools like Cat-a-lot and VisualFileChange edit very fast and goes upwards of several hundred a minute.

With the low edit rate, editors are hobbled in batch edits and have to wait for the next minute. This is quite tedious and time-wasting. Thus, please restore the rate limit to the speed BEFORE the change.

Details

	Subject	Repo	Branch	Lines +/-
	Raise the rate limits for Commons to higher values than global 90 edits/minute	operations/mediawiki-config	master	+7 -0

Customize query in gerrit

Related Objects

Mentioned In: T245214: Ratelimit on Commons is way too aggressive/broken
T228317: Increase the rate limit for moves on Commons for file movers to 100/minute
T56515: Apply editing rate limits for all users

Event Timeline

Zhangj1079 created this task.May 17 2018, 12:01 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 17 2018, 12:01 AM

Recently, system administrators installed a very low rate limit of 90 edits for 1 minute.

Any link / reference to that change?

Well, this was introduced because of vandals editing with speed over 30000 edits per hour (this is too high). The reference is T192668 but the task is restricted because of security. We can probably introduce higher rate limits for autopatrolled users or other similary approved users but this global rate limit won't be changed to the original limit. One of the reasons is that the original limit was "no limit for autoconfirmed". The current limit 90 edits per mnute for autoconfirmed seems to be acceptable globally. If commons want higher limit...

AlexisJazz subscribed.May 17 2018, 10:30 PM

zhuyifei1999 added a project: Community-consensus-needed.May 18 2018, 12:52 AM

zhuyifei1999 moved this task from Backlog to Blocked on community consensus on the Wikimedia-Site-requests board.

zhuyifei1999 subscribed.

As was requested previously, where is the link/reference to make the change. If this affects all tools for Commons users, then there should have been a public proposal on Commons, not a super duper secret Phabricator task because "security".

There is only the task and gerrit change https://gerrit.wikimedia.org/r/#/c/432279/ . Cannot link to anything nonexistent. This is a global change in mw core, affecting both wmf and non wmf projects.

If commons wants higher limit for some group, it must ask for some.

In T194864#4212788, @Fae wrote:

As was requested previously, where is the link/reference to make the change. If this affects all tools for Commons users, then there should have been a public proposal on Commons, not a super duper secret Phabricator task because "security".

I do not think all the security fix that might affect community should be consulted. That will just... leak the vulnerability.

alaa subscribed.May 18 2018, 11:21 AM

Hi. Im the one who added the limit.

The limit was supposed to be an upper bound and not affect actual users. Im sorry for the inconvinence and am totally ok with a higher limit (as long as all groups that you can be auto added to have a reasonable rate limit)

@Bawolff: It's pretty easy to hit 90 edits a minute on Commons. All you have to do is 1 cat-a-lot move in a category with more than 90 files. On Commons, it needs to be at least 200/min (the number of files displayed in a category at once).

Tm subscribed.May 19 2018, 12:49 PM

This comment was removed by Ladsgroup.

@Tm: Welcome to Phabricator. There was no previous one. See the link in T194864#4212867.
Also see https://www.mediawiki.org/wiki/Phabricator/Etiquette for expectations on tone and content in Phabricator. Thanks a lot!

The best thing that can be done IMHO is to raise the rate limit for Commons, to 200 edits per minute (as @kaldari suggested). I'm going to write a patch for it. For wikis with text-based content (most wikis IMHO), 90 edits per minute should be more than enough. I'm claiming the task, then.

Restricted Application added a project: User-Urbanecm. · View Herald TranscriptMay 19 2018, 1:42 PM

Restricted Application added a subscriber: Dereckson. · View Herald Transcript

Change 433988 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Raise the rate limits for Commons to 200 edits/minute for all logged-in users

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

gerritbot added a project: Patch-For-Review.May 19 2018, 1:43 PM

Community consensus shouldn't be bureaucracy blocking things that are seemingly urgent and should be resolved ASAP. I'm nto going to require explicit Commons consensus.

See above.

Urbanecm moved this task from Backlog to To deploy on the User-Urbanecm board.May 19 2018, 1:45 PM

It's quite normal to change 2000 files in 60 seconds with catalot or use VFC to make a DR with several hundred files in half that.

Please keep in mind that the case for the limit was never made, there has yet to be a proper analysis of why and in which cases this is of practical or realistic benefit as a way to protect the integrity of Commons. Until that is done, it is foolish and appears insulting to insist unpaid volunteers try to justify the way Commons has successfully worked for over a decade with minimal or no limits.

Ok. If I (or anybody else) would do an analytics and it will take a month, there will be approx. 1314870000 of vandalism edits with his current edit speed (I meant before introducing the rate limit of course). Would you take care about them? Would you pay for the space needed to store all the useless revisions (approx 13 TB)?

Sorry for my tone. Now I'm serious:

It is very unusual that such (potentionally dangerous) right like no rate limits for editing is being granted to someone automatically, without any explicitly assigned user group (like autoconfirmed, but this is about any group assigned by autopromote fce). Anyway, I amended the patch linked upper so it will restrict editing to 200 per minute for all users but image reviewers, patrollers and autopatrolled (those groups will be "restricted" to 999 edits per second => effectively no rate limit). This is similar to uploads (~5 uploads per minute for non-privileged users, 999 uploads per second for privileged). Is that okay? Keep in mind that admins, bots and account creators are never rate limited, unless very rare exceptions.

Cheers,
Martin

Sure, I'll take care of the vandalism on Wikimedia Commons, don't over-egg the case. The realistic risk of damage or disruption has not been made clear to us "non security" volunteers. Rather than telling us off in an attempt to make us feel stupid, try explaining the case properly and leave bullying tactics at the school gate.

I do not believe that any disruption on Wikimedia Commons would ever be undo-able in a few seconds of effort by a sysop who is experienced in handling mass reverts. 200 edits per minute is ridiculously low as this effectively makes cat-a-lot unusable. Please up it for the time being to 2000 edits per minute until or unless there is a proper analysis of risk done relevant to Wikimedia Commons and a proper Community consensus to support a proposal for more harsh limits that explains why the introduction of any limit is necessary to protect the project from damage, and explains how this will affect the use of standard tools.

If what has happened here is a single smart troll/vandal has misused our systems, that is not a reason for knee jerk reactions that make incredibly useful tools like cat-a-lot unusable for many helpful and collegiate volunteers.

revi unsubscribed.May 19 2018, 2:57 PM

In T194864#4217246, @Fae wrote:

Sure, I'll take care of the vandalism on Wikimedia Commons, don't over-egg the case. The realistic risk of damage or disruption has not been made clear to us "non security" volunteers. Rather than telling us off in an attempt to make us feel stupid, try explaining the case properly and leave bullying tactics at the school gate.

It's not a risc but real problem, https://meta.wikimedia.org/w/index.php?title=Special:Contributions/Hero9000&dir=prev&target=Hero9000, https://ar.wikipedia.org/w/index.php?title=%D8%AE%D8%A7%D8%B5:%D9%85%D8%B3%D8%A7%D9%87%D9%85%D8%A7%D8%AA/Hero9000&dir=prev&target=Hero9000&uselang=en, https://en.wikipedia.org/w/index.php?title=Special%3ACentralAuth&target=Jamesbebo and other links.

I do not believe that any disruption on Wikimedia Commons would ever be undo-able in a few seconds of effort by a sysop who is experienced in handling mass reverts. 200 edits per minute is ridiculously low as this effectively makes cat-a-lot unusable. Please up it for the time being to 2000 edits per minute until or unless there is a proper analysis of risk done relevant to Wikimedia Commons and a proper Community consensus to support a proposal for more harsh limits that explains why the introduction of any limit is necessary to protect the project from damage, and explains how this will affect the use of standard tools.

Sysops are always excempted from rate limits, so they should have no problems with mass rollbacking.

If what has happened here is a single smart troll/vandal has misused our systems, that is not a reason for knee jerk reactions that make incredibly useful tools like cat-a-lot unusable for many helpful and collegiate volunteers.

Don't know how many real users, but as I explained - such dangerous rights are not usually granted automatically, just after 4 days.

For reference:

MariaDB [commonswiki_p]> SELECT substr( rc_timestamp, 1, 12 ) 'ts', rc_user_text 'user', count(distinct rc_id) '#', group_concat( distinct ug_group ) 'group' from recentchanges left join user_groups on rc_user = ug_user  where  rc_type <= 1 and NOT EXISTS( select 1 from user_groups where ug_user = rc_user and ug_group in ( 'sysop', 'bot', 'accontcreator' ) ) group by 1,2 order by 3 desc limit 40;
+--------------+------------------------+-----+------------------------------------+
| ts           | user                   | #   | group                              |
+--------------+------------------------+-----+------------------------------------+
| 201804270018 | Chabe01                | 470 | autopatrolled                      |
| 201804281116 | Ymnes                  | 458 | autopatrolled                      |
| 201804300528 | Ser Amantio di Nicolao | 410 | filemover,patroller,rollbacker     |
| 201804260947 | Perumalism             | 378 | autopatrolled,filemover,rollbacker |
| 201805070219 | Tm                     | 377 | Image-reviewer,filemover           |
| 201805031529 | Ser Amantio di Nicolao | 372 | filemover,patroller,rollbacker     |
| 201805031529 | Ser Amantio di Nicolao | 343 | filemover,patroller,rollbacker     |
| 201804260952 | Perumalism             | 337 | autopatrolled,filemover,rollbacker |
| 201804291403 | Perumalism             | 326 | autopatrolled,filemover,rollbacker |
| 201804300528 | Ser Amantio di Nicolao | 323 | filemover,patroller,rollbacker     |
| 201804300938 | I99pema                | 323 | autopatrolled,filemover            |
| 201805070222 | JotaCartas             | 323 | filemover,patroller,rollbacker     |
| 201804302248 | Hiàn                   | 316 | autopatrolled                      |
| 201804270018 | Chabe01                | 302 | autopatrolled                      |
| 201804301624 | Ser Amantio di Nicolao | 298 | filemover,patroller,rollbacker     |
| 201805011455 | Ser Amantio di Nicolao | 298 | filemover,patroller,rollbacker     |
| 201804281116 | Ymnes                  | 297 | autopatrolled                      |
| 201804261146 | Perumalism             | 295 | autopatrolled,filemover,rollbacker |
| 201804261153 | Perumalism             | 285 | autopatrolled,filemover,rollbacker |
| 201804221543 | Chabe01                | 283 | autopatrolled                      |
| 201804261338 | Chabe01                | 275 | autopatrolled                      |
| 201804271105 | Perumalism             | 275 | autopatrolled,filemover,rollbacker |
| 201804211856 | Chabe01                | 270 | autopatrolled                      |
| 201804261147 | Perumalism             | 268 | autopatrolled,filemover,rollbacker |
| 201804260948 | Perumalism             | 264 | autopatrolled,filemover,rollbacker |
| 201804211856 | Chabe01                | 261 | autopatrolled                      |
| 201804261157 | Perumalism             | 261 | autopatrolled,filemover,rollbacker |
| 201804301624 | Ser Amantio di Nicolao | 251 | filemover,patroller,rollbacker     |
| 201804251914 | Perumalism             | 241 | autopatrolled,filemover,rollbacker |
| 201804261135 | Perumalism             | 241 | autopatrolled,filemover,rollbacker |
| 201805080723 | Cobatfor               | 240 | filemover,patroller                |
| 201804261200 | Perumalism             | 239 | autopatrolled,filemover,rollbacker |
| 201804261338 | Chabe01                | 239 | autopatrolled                      |
| 201805031529 | Ser Amantio di Nicolao | 238 | filemover,patroller,rollbacker     |
| 201804261131 | Perumalism             | 237 | autopatrolled,filemover,rollbacker |
| 201804220833 | Ser Amantio di Nicolao | 233 | filemover,patroller,rollbacker     |
| 201804211856 | Chabe01                | 231 | autopatrolled                      |
| 201804281908 | Perumalism             | 222 | autopatrolled,filemover,rollbacker |
| 201804240520 | Ser Amantio di Nicolao | 221 | filemover,patroller,rollbacker     |
| 201804240520 | Ser Amantio di Nicolao | 221 | filemover,patroller,rollbacker     |
+--------------+------------------------+-----+------------------------------------+
40 rows in set (30.16 sec)

And

MariaDB [commonswiki_p]> SELECT substr( rc_timestamp, 1, 12 ) 'ts', rc_user_text 'user', count(distinct rc_id) '#', group_concat( distinct ug_group ) 'group' from recentchanges left join user_groups on rc_user = ug_user  where  rc_type <= 1 and NOT EXISTS( select 1 from user_groups where ug_user = rc_user and ug_group in ( 'sysop', 'bot', 'accontcreator', 'filemover', 'rollbacker', 'autopatrolled', 'patroller' ) ) group by 1,2 order by 3 desc limit 40;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    14832468
Current database: commonswiki_p

+--------------+-----------------+-----+----------------+
| ts           | user            | #   | group          |
+--------------+-----------------+-----+----------------+
| 201804242340 | BrunoRuttler    | 278 | NULL           |
| 201804220004 | Majora          | 272 | Image-reviewer |
| 201804291848 | Broichmore      | 255 | NULL           |
| 201804250002 | BrunoRuttler    | 251 | NULL           |
| 201804220005 | Majora          | 215 | Image-reviewer |
| 201804242359 | BrunoRuttler    | 208 | NULL           |
| 201804242356 | BrunoRuttler    | 196 | NULL           |
| 201804222205 | Jaimmeeridlee   | 192 | NULL           |
| 201804202012 | NeoMeesje       | 165 | NULL           |
| 201804242343 | BrunoRuttler    | 164 | NULL           |
| 201804250003 | BrunoRuttler    | 160 | NULL           |
| 201804250004 | BrunoRuttler    | 149 | NULL           |
| 201804222205 | Jaimmeeridlee   | 145 | NULL           |
| 201804242356 | BrunoRuttler    | 142 | NULL           |
| 201804242352 | BrunoRuttler    | 141 | NULL           |
| 201804242349 | BrunoRuttler    | 140 | NULL           |
| 201804242346 | BrunoRuttler    | 139 | NULL           |
| 201804201302 | Ditch Witch     | 133 | NULL           |
| 201804220004 | Majora          | 133 | Image-reviewer |
| 201804242351 | BrunoRuttler    | 126 | NULL           |
| 201804242343 | BrunoRuttler    | 101 | NULL           |
| 201804250000 | BrunoRuttler    |  97 | NULL           |
| 201804222205 | Jaimmeeridlee   |  93 | NULL           |
| 201804230226 | TitiNicola      |  92 | NULL           |
| 201804242356 | BrunoRuttler    |  92 | NULL           |
| 201805180053 | OceanAtollWaves |  91 | NULL           |
| 201805162144 | OceanAtollWaves |  90 | NULL           |
| 201805162148 | OceanAtollWaves |  90 | NULL           |
| 201805162303 | OceanAtollWaves |  90 | NULL           |
| 201805162307 | OceanAtollWaves |  90 | NULL           |
| 201805162323 | OceanAtollWaves |  90 | NULL           |
| 201805170038 | OceanAtollWaves |  90 | NULL           |
| 201805170129 | OceanAtollWaves |  90 | NULL           |
| 201805170131 | OceanAtollWaves |  90 | NULL           |
| 201805172056 | OceanAtollWaves |  90 | NULL           |
| 201805172239 | OceanAtollWaves |  90 | NULL           |
| 201805172319 | OceanAtollWaves |  90 | NULL           |
| 201805172323 | OceanAtollWaves |  90 | NULL           |
| 201805172324 | OceanAtollWaves |  90 | NULL           |
| 201805172330 | OceanAtollWaves |  90 | NULL           |
+--------------+-----------------+-----+----------------+
40 rows in set (39.60 sec)

So based on data from the last month, the following should have negligible affect on commons community (Or at least would have in the last month):

* 'autopatrolled', 'filemover', 'rollbacker', 'patroller', 'Image-reviewer': Put it at 600/min.
* 'user': Put it at 300/min

If what has happened here is a single smart troll/vandal has misused our systems, that is not a reason for knee jerk reactions that make incredibly useful tools like cat-a-lot unusable for many helpful and collegiate volunteers.

While there do exists vandals who have exploited this - previous people exploiting with mass editing is not the primary reason why I want this. I want there to be upper bounds for security controls in general for all users (except sysops who have large amount of trust)

So I ran a further test of since beginning of 2018, and we definitely have some high edit rates

+--------------+------------------------+------+-------------------------------------+
| ts           | user                   | #    | group                               |
+--------------+------------------------+------+-------------------------------------+
| 201803041833 | Artix Kreiger 2        | 3904 | NULL                                |
| 201803201704 | Elisfkc                | 3014 | Image-reviewer,filemover,rollbacker |
| 201804060120 | Jarnsax                | 2852 | NULL                                |
| 201804060226 | Jarnsax                | 2721 | NULL                                |
| 201804060119 | Jarnsax                | 2704 | NULL                                |
| 201802061326 | Artix Kreiger 2        | 2687 | NULL                                |

Edit: It should be noted that Artix is a vandal, but some of these aren't

Because people were concentrating on the vandals, here it is with vandals removed:

MariaDB [commonswiki_p]> SELECT substr( rev_timestamp, 1, 12 ) 'ts', rev_user_text 'user', count(distinct rev_id) '#', group_concat( distinct ug_group ) 'group' from revision_userindex left join user_groups on rev_user = ug_user  where  NOT EXISTS( select 1 from user_groups where ug_user = rev_user and ug_group in ( 'sysop', 'bot', 'accountcreator' ) ) AND not exists( select 1 from ipblocks where ipb_user = rev_user ) and rev_timestamp > '201800000000'  group by 1,2 order by 3 desc limit 60;
+--------------+------------------------+------+-------------------------------------+
| ts           | user                   | #    | group                               |
+--------------+------------------------+------+-------------------------------------+
| 201803201704 | Elisfkc                | 3014 | Image-reviewer,filemover,rollbacker |
| 201804060120 | Jarnsax                | 2852 | NULL                                |
| 201804060226 | Jarnsax                | 2721 | NULL                                |
| 201804060119 | Jarnsax                | 2704 | NULL                                |
| 201804060237 | Jarnsax                | 2464 | NULL                                |
| 201804060233 | Jarnsax                | 2450 | NULL                                |
| 201803292141 | ToBeFree               | 2434 | extended-uploader                   |
| 201804060236 | Jarnsax                | 2351 | NULL                                |
| 201804060232 | Jarnsax                | 2314 | NULL                                |
| 201803310955 | Ser Amantio di Nicolao | 2216 | filemover,patroller,rollbacker      |
| 201804060227 | Jarnsax                | 2134 | NULL                                |
| 201804060231 | Jarnsax                | 2105 | NULL                                |
| 201801180316 | Jarould                | 2087 | filemover,patroller,rollbacker      |
| 201803201717 | Elisfkc                | 1972 | Image-reviewer,filemover,rollbacker |
| 201803201707 | Elisfkc                | 1921 | Image-reviewer,filemover,rollbacker |
| 201803201812 | Elisfkc                | 1842 | Image-reviewer,filemover,rollbacker |
| 201803310958 | Ser Amantio di Nicolao | 1825 | filemover,patroller,rollbacker      |
| 201804171812 | Ser Amantio di Nicolao | 1801 | filemover,patroller,rollbacker      |
| 201802131749 | Elisfkc                | 1693 | Image-reviewer,filemover,rollbacker |
| 201801180336 | Jarould                | 1652 | filemover,patroller,rollbacker      |
| 201804060234 | Jarnsax                | 1611 | NULL                                |
| 201801180315 | Jarould                | 1535 | filemover,patroller,rollbacker      |
| 201804011953 | Felis domestica        | 1500 | autopatrolled                       |
| 201804021243 | Maliepa                | 1500 | filemover,patroller,rollbacker      |
| 201805031529 | Ser Amantio di Nicolao | 1455 | filemover,patroller,rollbacker      |
| 201802071749 | Mr.Nostalgic           | 1445 | autopatrolled,filemover             |
| 201802131748 | Elisfkc                | 1417 | Image-reviewer,filemover,rollbacker |
| 201803292137 | ToBeFree               | 1395 | extended-uploader                   |
| 201803201419 | Jkadavoor              | 1388 | Image-reviewer,filemover,rollbacker |
| 201801180345 | Jarould                | 1385 | filemover,patroller,rollbacker      |
| 201802050541 | Tm                     | 1385 | Image-reviewer,filemover            |
| 201803201809 | Elisfkc                | 1291 | Image-reviewer,filemover,rollbacker |
| 201802071752 | Mr.Nostalgic           | 1282 | autopatrolled,filemover             |
| 201804011800 | Felis domestica        | 1278 | autopatrolled                       |
| 201803201713 | Elisfkc                | 1276 | Image-reviewer,filemover,rollbacker |
| 201804220833 | Ser Amantio di Nicolao | 1260 | filemover,patroller,rollbacker      |
| 201802071757 | Mr.Nostalgic           | 1253 | autopatrolled,filemover             |
| 201803201811 | Elisfkc                | 1244 | Image-reviewer,filemover,rollbacker |
| 201804060224 | Jarnsax                | 1238 | NULL                                |
| 201804061521 | Ser Amantio di Nicolao | 1238 | filemover,patroller,rollbacker      |
| 201803201420 | Jkadavoor              | 1233 | Image-reviewer,filemover,rollbacker |
| 201804080839 | Ser Amantio di Nicolao | 1220 | filemover,patroller,rollbacker      |
| 201803201714 | Elisfkc                | 1218 | Image-reviewer,filemover,rollbacker |
| 201804011801 | Felis domestica        | 1208 | autopatrolled                       |
| 201804211856 | Chabe01                | 1205 | autopatrolled                       |
| 201801190026 | MB298                  | 1200 | Image-reviewer,filemover,rollbacker |
| 201804012349 | Felis domestica        | 1186 | autopatrolled                       |
| 201801182102 | Tm                     | 1172 | Image-reviewer,filemover            |
| 201803201807 | Elisfkc                | 1172 | Image-reviewer,filemover,rollbacker |
| 201802190341 | Takeaway               | 1154 | filemover,patroller,rollbacker      |
| 201801200223 | Elisfkc                | 1149 | Image-reviewer,filemover,rollbacker |
| 201804091829 | Ser Amantio di Nicolao | 1123 | filemover,patroller,rollbacker      |
| 201801182356 | MB298                  | 1116 | Image-reviewer,filemover,rollbacker |
| 201804300528 | Ser Amantio di Nicolao | 1070 | filemover,patroller,rollbacker      |
| 201804031431 | Sporti                 | 1026 | filemover,patroller,rollbacker      |
| 201803201403 | Jkadavoor              | 1017 | Image-reviewer,filemover,rollbacker |
| 201802070948 | Mr.Nostalgic           | 1001 | autopatrolled,filemover             |
| 201801050258 | Clusternote            | 1000 | filemover,patroller,rollbacker      |
| 201803190543 | Kwangmo                | 1000 | autopatrolled                       |
| 201804011802 | Felis domestica        | 1000 | autopatrolled                       |
+--------------+------------------------+------+-------------------------------------+
60 rows in set (4 min 34.78 sec)

Ladsgroup subscribed.May 19 2018, 6:08 PM

Sixflashphoto subscribed.May 19 2018, 8:41 PM

Based on the last set of numbers, I would up my suggestion of a limit to 3000 edits / minute on Commons.

Please keep in mind that use of a high edit rate on Wikimedia Commons for serious vandalism/disruption remains entirely theoretical and this push to have edit rates was based on flawed gut feelings rather than analysis of a security risk. Implementing a edit rate restriction, even for brand new accounts, does not appear to protect anyone at this point. Until there is a series of real cases to discuss, leaving the edit rates high for this one project in the Wikimedia family, is very low risk and avoids putting off good faith editors that may wish to use cat-a-lot or VFC to make helpful mass corrections during their earliest edits.

Yes, these mass edits can go wrong, but on Commons they represent a very low risk of anything permanent as mass reverting is easy to do.

In T194864#4218611, @Fae wrote:

Please keep in mind that use of a high edit rate on Wikimedia Commons for serious vandalism/disruption remains entirely theoretical

Oh really? Both of these INC socks vandalized thousands of pages before anyone took action:
https://commons.wikimedia.org/wiki/Special:Contributions/BrunoRuttler
https://commons.wikimedia.org/wiki/Special:Contributions/Tammy_Eliot

Neither of them are autopatrolled, so I do not object to raising the limit for autopatrolled and higher.

Meh, changing some categories is not exactly the crime of the decade, especially considering it only takes a few seconds to swap the entire lot back. If these are the only example of misuse, it's a really, really, weak case for breaking standard tools for good faith contributors.

As for the auto-patrolled point, if a past sysop like INC wants to vandalise the project, limiting them to auto-patrolled accounts is like a sticking plaster to stop a flood.

Hello, I scheduled the patch(es) above for deployment and it will happen on Tuesday. It should happen between 13:00 and 14:00 UTC.

In T194864#4218773, @Fae wrote:

Meh, changing some categories is not exactly the crime of the decade, especially considering it only takes a few seconds to swap the entire lot back. If these are the only example of misuse, it's a really, really, weak case for breaking standard tools for good faith contributors.

As for the auto-patrolled point, if a past sysop like INC wants to vandalise the project, limiting them to auto-patrolled accounts is like a sticking plaster to stop a flood.

For the record, the reason for the original change had nothing to do with these issues.

The tables I pasted above was to determine what rate limits could be chosen that would not affect the status quo on commons. It was not an example of why we should have these changes; quite the opposite it was to determine what changes to the rate limit would still allow those sorts of things

I'm going to use 200/min for ordinary users and unlimited for autopatrolled and above. It will fix it for most users. I'll try to look for better rate limit after the patch will be deployed, but I really think there SHOULD be some rate limit.

I changed the values to others per @Bawolff suggestion. It is going to be 900 edits/3 minutes for normal users, 10500 edits/3 minutes for autopatrolled+.

Urbanecm moved this task from To deploy to To deploy - scheduled for SWAT on the User-Urbanecm board.May 20 2018, 6:41 PM

Change 433988 merged by jenkins-bot:
[operations/mediawiki-config@master] Raise the rate limits for Commons to higher values than global 90 edits/minute

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

Mentioned in SAL (#wikimedia-operations) [2018-05-21T13:22:27Z] <bawolff@tin> Synchronized wmf-config/InitialiseSettings.php: Increase edit rate limits on commons (T194864) (duration: 01m 24s)

This is live now.

I want to again apologize for the disruption I caused by this. I'd also want to thank @Urbanecm for his help on this ticket.

Edit: It should be noted that Artix is a vandal, but some of these aren't

Artix wasn't a vandal, most, if not all of his actions were done in good faith.

In T194864#4220751, @Zhangj1079 wrote:

Edit: It should be noted that Artix is a vandal, but some of these aren't

Artix wasn't a vandal, most, if not all of his actions were done in good faith.

I made the assumption based on the fact that [[User:Artix Kreiger 2]] is blocked. I did not investigate what exactly he was blocked for.

I am concerned that there may have been a mistake on some of my queries (It appears that sometimes the group by is grouping by the full timestamp instead of the prefix of the timestamp up to 1 minute. But only when I run on toolforge, not when I run on analytics-store.eqiad.wmnet)

Checking other wikis for possible affectedness by looking at users who are close (88 edits) to the rate limit (This excludes blocked users to try to exclude vandals as not being legitemently affected. Does not exclude globally locked users. It counts each user only once per wiki where they hit the rate limit):

bawolff@stat1005:~$ for i in `cat all.dblist`; do echo 'SELECT "'$i'",count(distinct user) from (SELECT substr( rc_timestamp, 1, 12 ) "ts", rc_user_text "user", count(distinct rc_id) "#", group_concat( distinct ug_group ) "group" from recentchanges left join user_groups on rc_user = ug_user  where  rc_type <= 1 and NOT EXISTS( select 1 from user_groups where ug_user = rc_user and ug_group in ( "sysop", "bot", "accontcreator" ) ) AND not exists( select 1 from ipblocks where ipb_user = rc_user limit 1 ) group by 1,2 HAVING count(distinct rc_id) > 88 order by 3 desc ) t;' | mysql -h analytics-store.eqiad.wmnet $i --skip-column-names; done > ratelimitviolations-user.txt

bawolff@stat1005:~$ egrep '[1-9]' ratelimitviolations-user.txt 
collabwiki	1
commonswiki	169
dewiki	1
enwiki	4
eowiktionary	1
eswiki	2
euwikibooks	1
fawiki	1
newiki	1
ruwiki	1
trwiki	1
viwiki	4
wikidatawiki	31

Seems like minimal (albeit a little bit) affect on other wikis. Most of the enwiki examples seem to be people using catalot on enwiki. wikidata doesn't count as it has its own rate limit that's different.