This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Rate limit have been increased. It has been suggested that people move on unless you want further increase of rate limit. If you want so, please open a new thread. — regards, Revi14:35, 13 June 2018 (UTC)
There is a new rate limit for non-admins at 90 edits per minute. Proposal is to raise the limit higher. It only applies to people with the autopatrol permission.
Support, rate limits don't make sense, mass-copyright violation uploaders will be nuked on sight anyhow, upload rate limits don't prevent them nor does it halt them. My concern is with all the good faith uploaders that hit this limit and don't know how to not hit it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:28, 17 May 2018 (UTC)
Fucking kill this ratelimit right now. This is going to make things I do around here annoying to the bone. I have kicked VFC in the balls to make it nominate 1700 files for Commons:Deletion requests/undefinedinsource:huntingtontheatreco which was hard enough without such a ratelimit and I'm not looking forward in the slightest to all the fun I'll be having when I finally find the time to start categorizing these by photographer - which will be needed. The thousands of edits with cat-a-lot to categorize Category:Photos from tasnimnews.com by photographer are annoying, complicated and slow enough as it is. For IP-users, I fully support a ratelimit of 10 edits per minute if not less. For autopatrolled users it needs to be way higher. If the only way around this is to become admin then God help me I will apply for that. And nobody wants that! - Alexis Jazzping plz22:17, 17 May 2018 (UTC)
I asked because I hit some kind of limit recently when moving files out of a misspelled, redlinked category using Cat-a-lot. That's a task I do often, and I hadn't seen this limit before. --Auntof6 (talk) 23:44, 17 May 2018 (UTC)
Easy solution: Make the scripts slower so you don't run into rate limits. Decrease your 'Maximum number of requests to send to the API simultaneously' --Zhuyifei1999 (talk) 00:55, 18 May 2018 (UTC)
How do you do that with Cat-a-lot?—Odysseus1479 (talk) 04:36, 18 May 2018 (UTC)P.S. I just catted about a thousand files—taking about half a minute per batch of 200—and didn’t apparently hit a limit, so now I’m not sure what this is about. – 05:05, 18 May 2018 (UTC)
@Odysseus1479: I wonder if you are excluded from this limitation. Maybe it's your rollbacker rights? That's an anti-vandal tool so it would make sense if that excluded you from this limit. - Alexis Jazzping plz08:18, 18 May 2018 (UTC)
@Zhuyifei1999: that's not a solution. That's like when you find yourself completely out of breath after going down the stairs, you suggest "buy a house without stairs". You need to see a doctor, not a real estate agent! - Alexis Jazzping plz08:18, 18 May 2018 (UTC)
I am unclear why people are voting on this. It looks like a bug, not a design request. If a 90 edits per minute limit has been introduced for all tools, like Cat-a-lot, where is the Phabricator task to make the change, why was the all done in secret and without any community consultation?
This rate limit should not apply on Wikimedia Commons to cat-a-lot, GLAMwiki toolset, any shared or established housekeeping tools, bots, or similar trusted tools. To block these with a global and secret change is both bizarre and disruptive (if true, take screenshots, evidence please). --Fæ (talk) 04:51, 18 May 2018 (UTC)
I am still asking for screenshots as the change was implemented with the developers still guessing as to what the impact might be. If you examine the gerrit comments, it was still unknown if this actually affected uploads or not, and it was presumed that bots and other types of account would be unaffected. At this point nobody seems to actually understand the impact of this untested global major change that had zero consultation with the community and was done in secret discussions for secret reasons by unknown participants, but is claimed to not be done for the WMF because is a "mediawiki" change. --Fæ (talk) 08:32, 18 May 2018 (UTC)
Just to clarify. I understand what this change does - you could have asked me. It does not affect groups with the noratelimit right (bots, admins, account creators). It does not affect uploads. I know the secret phab tasks mentioned sound mysterious, but they are only tangentially related to the new rate limit thing, and don't have any big information in them that's of interest about this. BWolff (WMF) (talk) 09:56, 18 May 2018 (UTC)
Please do not gaslight me when I am only guilty for raising issues as they appear to us humble users. It was impossible for me to "ask you" anything because this change was done in secret without any consultation. I am not mad, neither am I telepathic.
In the change you put through gerrit on 9 May, it can be seen from the comments from yourself and others that it was guesswork as to what the impact would be. Neither yourself nor others thought that any testing or further checks were needed before implementation, nor did it apparently occur to these power-users to consult with those of us with special interest in Wikimedia Commons tools. Had this happened I would probably have been one of those asking what the impact on tool use would be.
Despite your words here, I still do not see any evidence of analysis of impact. For example "I was kind of assuming that edit limits also apply to upload because uploading something requires an edit" has now changed to "the initial edit to the image description page during upload does not count towards your edit rate limit AFAIK", both statements from you are assumptions, not facts.
This was a significant change of a type that risks breaking several tools for many users, such as cat-a-lot. The problems experienced here by real users are not imaginary, nor exaggerated. Please replace assumptions by facts.
As for the original "security" incident, which I chose to avoid drawing attention to, you and I both know that it is possible to discuss why rate limits should be tightened up, without giving vandals a hackers guide on a plate. It is not, and should never become, an excuse to avoid community consultation of changes that significantly affect the user experience and usability of Wikimedia projects. --Fæ (talk) 10:35, 18 May 2018 (UTC)
@Fæ: Originally, I was unsure if initial edit to images counted as an edit for the purposes of rate limiting. So I looked it up, and now I'm sure that the answer is no. The change is working as I intended it from a technical perspective, so I wouldn't say its under-tested from a technical perspective (political perspective is a different matter). I'm sorry its negatively affecting commons, and I must admit that I'm not as on top of it as I normally would be due to this last week being very busy. That said, you're an experienced user who knew it was me who made the change, if you had questions about the intended functionality of the change you could have easily asked me on my talk page (or here, and mentioned my username so I got an echo notice, or on gerrit, etc) instead of just complaining its unclear. The security bug is by and large only tangentially related to this. BWolff (WMF) (talk) 12:30, 18 May 2018 (UTC)
You appear to not understand what gaslighting means in this instance. I only became aware of this change after receiving an email about it 17 hours ago and got around to looking at the gerrit record 5 hours ago. That was the first time I saw your name on the record and your comments about it. It is classic gaslighting to insist that you know what is in my head or my memory better than I do and that I am at fault for failing to approach you about this several days before I could possibly know about it. Please do not do that, driving a technical issue on an irrelevant ad hominem tangent by forcing me to defend myself, erodes my trust and drives both myself and other interested unpaid volunteers from asking questions or participating in improving this project in the future. --Fæ (talk) 13:23, 18 May 2018 (UTC)
I can’t talk about the security bug stuff for obvious security reason, but the tools should not run that fast, imo. "Too many edits in too small amount of time can affect infra in several ways, one is replag, one is dispatch lag, one is jobqueue size." @phab:T184948#4075653 (Yes, this is Wikidata task, but I believe this applies to Commons too.) — regards, Revi08:42, 18 May 2018 (UTC)
Thanks for your opinion. The question here is why your opinion and that of a tiny handful of people who may or may not be active on Commons at all, has complete authority to break tools and change the meaning of some of our most significant user groups and rights, while the active Wikimedia Commons community are neither kept informed, nor are consulted with. If the aim was to insult the Wikimedia Community by treating them as ignorant plebs, congratulations.
This significant change was not tested, nor has there been a proper analysis of impact, either in secret or in public. --Fæ (talk) 09:06, 18 May 2018 (UTC)
For the record: While I had read access to the bug, my opinion is not relevant to the security bug, my opinion was not influenced by that security bug, I didn't know about that bug until this Monday or around that. — regards, Revi12:33, 18 May 2018 (UTC)
Howdy folks - it was me who added the rate limit. So just to be clear:
Previous state:
All the same as before, except that autoconfirmed users (Edit since this was unclear: This is anyone who is autoconfirmed including people with other groups such as image-reviewer, autopatroller, and patroller), now have a rate of 90 edits/minute. Admins, bots and account creators continue to have no rate limits (As they have noratelimits). Uploads stays at the same 380/72 minutes (In particular, note that the initial edit to the image description page during upload does not count towards your edit rate limit AFAIK).
I apologize for lack of communication on this issue. The short version is that we no longer want to have rate limits for editing of infinity except in groups that people are explicity added to. So continuing to have no rate limits for users who are bots and admins is cool, but we need some rate limit for autoconfirmed users.
What the actual rate limit is doesn't matter too much as long as its some level of sanity. 90 edits/minute was chosen as something that I didn't expect ordinary users to come remotely close to hitting (I guess I was wrong in the commons case). That's one of the reason's why I failed to communicate this change like I should because I didn't actually think real people would hit it (sorry). I am totally open to having a higher limit either in general, or for other groups like autopatrol (Within reason. Suggesting a limit of 900 edits a second doesn't count. We do need to have some upper bound limit that's not infinity). Another option is to adjust the time frame (So instead of 90 edits a minute, we could have 450 edits per 5 minutes or whatever). BWolff (WMF) (talk) 09:49, 18 May 2018 (UTC)
@BWolff (WMF): I am autopatrolled, so I can upload 999 files/second but I can't nominate 100 files/minute for deletion? Holy cow.
Since admins and bots have no limit and the way cat-a-lot and VisualFileChange work and are used, my first suggestion is that users with autopatrol have the same limit applied to them as bots and admins - currently, that means none. This should apply only to Commons, other projects may not need this. (I only make suggestions for Commons)
For autoconfirmed users, I suggest 1000 edits per 15 minutes. That's lower than the current limit, but it's considerably less likely people will run into it. By the time they do, they should be considered for autopatrol anyway. - Alexis Jazzping plz11:26, 18 May 2018 (UTC)
@Alexis Jazz: Not really. Just set it to something sensible that won't get in the way of good editors. Maybe have a look through the edit logs to determine what that might be. Thanks. Mike Peel (talk) 22:10, 18 May 2018 (UTC)
If this were true, I think we would not be seeing the cat-a-lot and VFC problems that have been stated in this thread. What is needed, and some may find this a really whacky idea in this pseudo-Agile environment, is some documented tests using accounts with these different rights, and gosh-darnit, written down analysis rather than "trust me, I know what I'm doing". --Fæ (talk) 14:04, 18 May 2018 (UTC)
User:Jeff G. - no. image-reviewer, patroller and autopatroller do not override edit rate limits, so it is the same as normal (autoconfirmed) users. (unlike uploads, where image-reviewer, patroller and autopatroller do override). BWolff (WMF) (talk) 14:56, 18 May 2018 (UTC)
So what do we want instead
Ok. So I can change the limit, but I need to know what to change it to. Would this be acceptable to the community:
Newbies/anons: stay the same: 8 edits/minute
Autoconfirmed: 270 per 3 minute (Same rate, but over a larger time period to account for bursts)
The problem is that tools like Cat-a-lot and Visual File Change can effect a large number of files at the same time. When moving files from one category to another, for example, you might want to change thousands of files in a fairly short amount of time, in chunks of 200 each. For Cat-a-lot at least a rate limit of at least ~210/30 seconds would be necessary, other tools might need even more edits. In the long term, I think the developers should take a good look at these use cases, and possibly provide better tools that do not hit any rate limits. (For example, why can't we move a category, including its contents and need hacks like Cat-a-lot in the first place?) Sebari– aka Srittau (talk) 15:30, 18 May 2018 (UTC)
Do we often have newish users (at least users who aren't autopatrollers yet) who need to perform large inter-category moves? That's not a rhetorical question. Would it be overly burdensome to have them request autopatroller right before performing large moves? My naive assumption is that it's a perfect diagnostic for being autopatroller: do we trust you to perform these types of re-categorizations correctly. But then, these are just my naive thoughts - I don't spend a huge amount of time with Catalot or patrolling. If there's a lot of pushback from people who do a lot of categorization, I'll change to abstain from support. Storkk (talk) 15:37, 18 May 2018 (UTC)
The autopatrol right is never assigned automatically, is it? But it might still be the best solution for now. Sebari– aka Srittau (talk) 15:51, 18 May 2018 (UTC)
It's not assigned automatically by the software, but it is often assigned without having been requested... as it was for both yourself and for me. Presumably by admins not wanting the Recent Changes list clogged by obviously reasonable editors. Storkk (talk) 16:00, 18 May 2018 (UTC)
I was given autopatrol without even knowing what it was, what it meant and if I hadn't been mentioned on the request I might not have even known it ever happened. - Alexis Jazzping plz16:42, 18 May 2018 (UTC)
Support 90 edits/min just won't do. That would cut off any of the following: VFC mass DR of a user's 89 uploads; VFC mass DR of 45 files in one cat or search result (all with different uploaders); VFC search/replace or categorization change on 91 files in one cat or search result; Rollback all 91 of a vandal's top edits to pre-existing pages; or any Cat-a-Lot operation on any 91 files. — JeffG. ツ please ping or talk to me16:02, 18 May 2018 (UTC)
@Alexis Jazz: In order, I support: the original "get rid of it" proposal (status quo ante) of ∞ for autoconfirmed and autopatrolled; Alexis Jazz's counter of 1000/15m for autoconfirmed, ∞ for autopatrolled; Donald Trung's counter of 2000/4m for autoconfirmed (and I guess the same for autopatrolled); BWolff (WMF)'s counter of 270/3m for autoconfirmed, 2000/5m for autopatrolled; and dead last the status quo of 90/m for autoconfirmed and autopatrolled. — JeffG. ツ please ping or talk to me19:50, 18 May 2018 (UTC)
Comment@BWolff (WMF): I'm not so sure. Technical reasons are apparently not the issue, as admins, bureaucrats and bots are exempt. So why do we need to limit autopatrolled users at all? Have they caused any serious problems recently? If they didn't, why limit them? If they did, why didn't we ban the fuckers instead of punishing everyone? I personally may not run into a 2000/5m limit often, but why do legitimate actions need to be limited at all? And don't say "technical reasons", because admins and bots are not affected. I can only speak for myself when I say I probably won't run into a 5000/5m limit soon. But with cat-a-lot and VFC, users are effectively operating as assisted bots. Also, 270/3m for autoconfirmed isn't always gonna cut it. And we may not always want to make those users autopatrolled, at the same time we don't want to ratelimit them. I suggested 1000 edits per 15 minutes for autoconfirmed. Autopatrol the same limit as sysops and bots. (which, currently, is none) - Alexis Jazzping plz16:42, 18 May 2018 (UTC)
I lean towards Support but would change it to "2000 (two-thousand) uploads/edits per 4 (four) minutes" for two simple reasons, one most people who chase down copyright violatiolators from other wiki's aren't anything other than "Autoconfirmed" here and of course the fact that there are mass-uploaders who import from large image banks with free licenses. Anyhow I would personally rather see users with more than 1000 files of which less than 100 are deleted to be able to apply for a "mass-uploader" flag which would place them in the "noratelimit" category, this should probably also apply to other mass editors such as those that do mass categorisation and/or file mass delete requests. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:15, 18 May 2018 (UTC)
@Majora: this has nothing to do with "blanket upping". This limit never existed before last week. We are not suddenly removing a protective measure that kept us safe for years. @BWolff (WMF): said "Suggesting a limit of 900 edits a second doesn't count", but didn't make it clear what we really could suggest, what the possible range is or at what point it stops making sense from a technical point of view. I'm getting the feeling we are now haggling for a higher limit on a rate limiter for which I have seen no proof it reduces vandalism from autopatrol users. What I said was: apply the same limit to autopatrol as that which is applied to sysops. Limit sysops to 500 edits/m, limit autopatrol to 500 edits/m: no problem. I would actually support some limit for sysops. They sometimes go bad as well, they should not be exempt. I understand the wish to have some limit, but especially for groups that have rarely if ever abused the edit rate, the limit should be so high there is virtually no chance anyone will ever touch it without bad intentions. - Alexis Jazzping plz21:16, 18 May 2018 (UTC)
Just because you see no proof doesn't mean it doesn't happen. Rate limits are a tool that if working properly you would never actually see. It is about logical prevention. Making any rate limit high enough where nobody would ever reach it defeats the entire purpose. That level should only be reserved for our most trusted individuals. And yes, admins fit that bill. That is the point of RfA. Determination of trust. --Majora (talk) 21:33, 18 May 2018 (UTC)
We've had hundreds of admins here. Thousands of admins across the projects. The percentage of those that abuse their powers are minimal and the fact that you had to use other projects to prove your petty point proves mine. But I digress.
No rate limits should be reserved for a very small subset of people. Period. I fully oppose the removal of rate limits and the return of infinite edits per minute for anyone besides those who explicitly have the no rate limit flag granted to them. The idea that that was even a thing is an incredibly oversight in my opinion. The developers obviously also don't like that idea else they wouldn't have changed it.
If I'm going to support something I need data. What is the normal editing patterns? Most people who stick around become autopatrolled, else they shouldn't have a higher rate limit anyways. So I like the idea of having autopatrolled (and those with that right included) as the gate for any higher limits. That right shows that you know what you are doing and that you have been around Commons semi-long enough for people to know you aren't going to break things. You so far have ignored Mike Peel's suggestion that you do some research on the topic. Perhaps you should abide by their advice? Instead of getting all worked up over this give us some data to work off of. If you want to effect change you have to do the legwork and give us something to go on. Something reasonable. Else BWolff's settings at the top of this section will have to do. --Majora (talk) 02:55, 19 May 2018 (UTC)
Where to begin.. It doesn't matter there are thousands of admins. If I gave you a bag with 5000 peanuts and told you they are all perfectly fine except for one which will kill you, would you eat any of them? Admins don't need infinite. Nobody does. I didn't have to use other projects. I limited myself to English and to cases I had heard about before.
"You so far have ignored Mike Peel's suggestion that you do some research on the topic": Who do you think I am? I haven't. I don't have the tools to answer that question adequately. And you have no idea how much of a miracle it is that I now am actually able to say anything about it at all. But you could not have reasonably expected the data I'm about to put here. (still processing, will take a while) - Alexis Jazzping plz11:15, 19 May 2018 (UTC)
'newbie' each new autoconfirmed accounts; overrides 'user'
'ip' each anon and recent account
'subnet' ... within a /24 subnet in IPv4 or /64 in IPv6
'groupName' by group membership
New page creation probably doesn't count as an edit. At least for uploads it doesn't. So if vandals want to fuck with Commons, they could just get an autoconfirmed account and upload 999 files/second. Seems like this really wasn't thought through.
Autoconfirmed has "autoconfirmed" and "editsemiprotected" set to true, otherwise it's just another user with the same limits.
Bots have "bot", "autoconfirmed", "editsemiprotected", "nominornewtalk", "autopatrol", "suppressredirect", "apihighlimits" and "writeapi".
Highvolume has "bot", "apihighlimits", "noratelimit" and "markbotedits".
There is some group named "sysops" that has a lot of permissions, including "unblockself". I would suggest not fucking with them.
I'm not sure how bots get noratelimit. Maybe inherit it through highvolume, but I don't see how. Maybe some bots have highvolume and others don't. If that's the case, some bots may also be affected by ratelimits.
@Jeff G.: you have a specific rollbacker right so that limit probably doesn't apply to you. I don't think I can do rollbacks at all, so Commons doesn't seem to use the default settings for this. - Alexis Jazzping plz11:15, 19 May 2018 (UTC)
I concur with Jeff that limiting rollbacks to 10/m would severely impact my anti-vandalism work, and is just dumb. You're either trusted with the privileges because of a demonstrated need of the tools or not. If someones needs the tools why hamper the work. Just silly. -- Sixflashphoto (talk) 14:38, 19 May 2018 (UTC)
@BWolff (WMF): I don't think 270 edits per 3 minute is going to be adequate for Commons (per my comments in the Phabricator thread). I would suggest 200 edits per minute (to account for category editing tools). Kaldari (talk) 04:34, 19 May 2018 (UTC)
Cat-a-lot is often used for moving/renaming categories, category diffusion, and other things. I believe it can move as many as 600 things at a time (up to 200 each of files, pages, and subcategories). Often it moves only 200 at a time because there are usually more files than anything else. Some categories have thousands or tens of thousands of files. Each move takes only seconds. If I have to wait a minute each time I invoke Cat-a-lot, I'm going to be reluctant to do that kind of work. I understand not wanting vandals to be able to do too much at a time, but I'd like to be able to invoke Cat-a-lot multiple times within a minute. --Auntof6 (talk) 06:41, 19 May 2018 (UTC)
Delete Kill This limit with fire. Another change to a core ability of edition made by stealth without consultation or discussion by the peasantry. This is another show of how WMF treats the communities. Make a change by stealth and so change the goalposts and them claim to discuss what you already changed. No proof that there is a need to limit the number of editions. Does the developers even comprehend how things work. To make a move of 200 files, that used to take 10 seconds, it now takes two minutes? Talk about a friendly interface. It is now frustrating to do any kind of some basic work, because some chap tought of this measure with is legs, and not with his brain. Tm (talk) 12:24, 19 May 2018 (UTC)
@BWolff (WMF): Now, because of your undisclosed and undiscussed change, is infuriating to do any basic work on Commons. What took less than one minute to make, like to move 2000 files, now takes more 20 minutes to make. You call this user friendly. Show the data that supports this radical change or otherwise this is not based in any valid metric. And dont tell that the data is secret or there is any other security bs reason. Also, how much vandalism has it stopped? Versus the frustration of good faith users, it must be really residual. Tm (talk) 12:55, 19 May 2018 (UTC)
Comment Per my comments in Phab:T194864, if developers are insisting that there is a realistic chance of Wikimedia Commons being destroyed overnight, I suggest 2000 edits per minute as a conservative back-stop limit. However, again, the case for the existence of weapons of mass disruption (for Wikimedia Commons) has not been made, so this is not yet a war. If 2000 edits/min is not sufficient then a detailed proposal should be written up with proper facts and evidence as to why harsher steps are necessary; so far there has been no evidence that limits must be imposed in so much of a hurry that it cannot wait for analysis to be published and proposals written properly. Any vandal editing Commons that I have ever seen can be mass reverted within seconds of being noticed with almost no long term damage possible. If I am wrong, then the potential cases should be put forward in writing, rather than being a question of oblique allusion and imagination. By the way, waiving the Tech CoC at Tm on Phabricator was unnecessary, nobody is getting harassed by Tm expressing a strong viewpoint. --Fæ (talk) 15:10, 19 May 2018 (UTC)
Ok, some actual research. This is how fast people have edited in the last month (roughly, I'm dividing the month into 1 minute intervals, on the 00 second, not maximizing the 1 minute interval that has the highest count).
Excluding only sysop, bot and account creator:
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 if we exclude some other groups like filemover, rollbacker, autopatrolled and patroller:
Comment I have done some research of my own, as Majora suggested, even though I don't have access to the right tools like BWolff does. My data is quite different due to a completely different approach. There may be some errors because a lot of this is copypaste work. This is what I got now:
I performed 2000 edits in 5 minutesstarting with this one. (I had only looked at my Cat-a-lot log. Haven't checked yet if I did more with VFC)
I performed 3630 edits in 10 minutesstarting with this one. (possibly same batch, at least related work)
For myself I had only looked at cat-a-lot. For Jeff G. I looked at everything but only dating back to May 2017.
I also looked at Rafic.Mufid (talk·contribs) who categorizes a lot, but he topped out at 66 edits in 5 minutes.. with HotCat. (surprisingly, he has never used cat-a-lot) Restecp..
@Alexis Jazz: My first group was of spelling fixes. My second group was of minor changes to force results that were not happening through the glacial job queue of the time, I won't do that again. Frankly, I'm surprised you didn't happen on my DENY mass rollbacks of INC's socks. — JeffG. ツ please ping or talk to me17:34, 19 May 2018 (UTC)
I have your top 20 (and maybe more if I didn't accidentally throw it away), without duplicates:
Looking over a longer time period (Starting from jan 1 this year), we do see some larger numbers (Note: this doesn't filter the dummy edits from page move or initial upload text):
@BWolff (WMF): So this is all the number of edits in 1 minute, right? Artix Kreiger 2 is a sock, but were those mass edits vandalism? (I would guess not as they happened weeks/months apart)
Artix Kreiger (not 2) at one point had extended uploader, patroller, rollbacker and file mover rights. Not really unthinkable someone like that can become sysop one day. (although his rights were stripped later, but such things already happened in the past) Admins are not on this list, but an admin should not be able to deface a wiki at whatever speed the Wikimedia servers can handle. Is there a legitimate use for admins to do more than 3000-4000 edits per minute?
No way by the way any of the people on this list are using standard tools in a standard browser. At the very least they must be using something like Fasterfox. - Alexis Jazzping plz18:50, 19 May 2018 (UTC)
@BWolff (WMF): Oh, and as you now have seen for yourself that the ratelimit is severely crippling legitimate use here, I basically take it for granted you already have raised the limit to something no legitimate user will run into. We don't want to haggle over that. If you implement a rate limit in such a way no legitimate user ever runs into it (or only a handful of users have to wait 2 minutes every month or so) I don't really see any need for consensus. - Alexis Jazzping plz19:00, 19 May 2018 (UTC)
The point of those stats were to try and find what a rate limit would be that would not affect any (non-vandals), not to convince the neccessity of rate limits, which is why I didn't include admins. I won't be able to change the limit until monday, but do intend to change it for commons once monday comes. BWolff (WMF) (talk) 19:24, 19 May 2018 (UTC)
@BWolff (WMF): right, monday, I forgot.. okay. What I meant to say was that the limit should be increased/disabled ASAP (which is monday I'm afraid, a part of one of your tables already shows users hitting the limit repeatedly) and we can discuss details later. I don't know what Artix Kreiger 2 did (can't find the edits.. either removed or timezones are confusing me), but Elisfkc (talk·contribs) is not a vandal. So where you previously said "600/min" that should be (at least) 3000/min. For autoconfirmed, 300/m seems kinda reasonable - but I think something needs to be made to allow lifting that limit without making them autoconfirmed and without resorting to noratelimit. Some users can do good work, use tools that may exceed 300/m but they may be problematic in other areas and need their edits to be patrolled. Also, if 300/min is acceptable, why not put autoconfirmed on 900/3m or 1500/5m? - Alexis Jazzping plz19:58, 19 May 2018 (UTC)
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 the 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. --Fæ (talk) 03:23, 20 May 2018 (UTC)
@Fæ: And as far as theoretical risks go: sysops sometimes do go bad and unless they actually need noratelimit for some reason, they should be on the ratelimit as well. (for the value to use stats will be needed) The risk of an admin going bad and editing at whatever speed the servers can handle may be tiny, but the potential fallout is more serious. - Alexis Jazzping plz06:54, 20 May 2018 (UTC)
This whole discussion has felt like trying to explain to Brexiteers why there are no good reasons for the UK to leave Europe, and being repeatedly told to shut up, give Brexiteers proper respect, and stop moaning unless you can come up with solutions to the problems Brexit creates.
Why the knee jerk change? - because 'security' - details please? - sorry, no, oh but there was no security problem, but we need it because something bad might happen - so why should we break tools because of a hypothetical problem for which no analysis exists? - Oh, okay we can relax the change, but as you objected to the arbitrary limits, you will have to do the work of justifying what limit we need - ... hang on, how has your tool breaking change become everyone else's fault now?
@Odysseus1479: You were wondering why you didn't hit the limit. I think I know why!
YOU DID HIT THE LIMIT!
I just tried to categorize 315 files with cat-a-lot. Cat-a-lot gave me that beautiful big green checkmark when it was done, but to my surprise only 89 files appeared in the category. All subsequent edits were silently dropped.
Now that I know this, we should have never allowed @BWolff (WMF): to wait with this until today. I don't care if you would have had to remotely login to some system or ask someone else to fix it. A ton of categorization work must have been silently dropped and there's probably no way to recover that. - Alexis Jazzping plz08:01, 21 May 2018 (UTC)
I'm not allowed to change things except for emergencies during weekends (Its a general WMF policy). I don't believe this was something I could justify as an emergency, which is why I am waiting until today. Its not because I don't want to work on a Sunday (In fact, I was at Wikimedia hackathon all sunday, so I was literally on wiki the entire time). There are many reasons other than rate limits why an edit can fail. If the script is not checking whether or not edits succeeded, then I would say its a broken script, and will break on lots of other conditions than rate limits. BWolff (WMF) (talk) 13:07, 21 May 2018 (UTC)
@BWolff (WMF): You claim that "there are many reasons other than rate limits why an edit can fail" and "If the script is not checking whether or not edits succeeded, then I would say its a broken script". Well please explain that the same that has happened to Alexis Jazz has happened to me, but only after the imposition of rate limits. How is this the fault of a "broken script" if worked completely fine and unbroken, before the rate limits imposition? Tm (talk) 13:28, 21 May 2018 (UTC)
I'm not intimately familiar with that gadget - but if edits are failing and its not reporting the failure to the user, then that's a bug in the gadget. Edits can fail for a variety of reasons (Page protected, loss of session data, captcha triggered [that's unlikely unless you are an anon], abuse filter, edit conflict, user blocked. Not to mention more obscure things like article too big, content model mismatch, db read only). If indeed the gadget is not reporting errors from the api properly, I imagine people didn't notice because it would normally be an obscure happening. BWolff (WMF) (talk) 13:45, 21 May 2018 (UTC)
The script had no reason to assume an edit could fail this way. And the developer wasn't informed (almost nobody was) about this change.
Page protected: I tested it and indeed cat-a-lot is mistaken by that as well. But protected file pages are incredibly rare on Commons. (File:Example.jpg is one) We have 532 of them. Maybe a few more if the template isn't always applied, but it's still incredibly rare.
Loss of session data: also very rare.
Captcha triggered: again, rare. I've never seen an anon use cat-a-lot. Since anons can't go to their preferences to enable cat-a-lot, I don't know how they could use it anyway.
Abuse filter: pretty much unthinkable for cat-a-lot.
Edit conflict: you are a developer. race condition that depends on another user editing the same page in a window of typically ~150ms. (for people who don't speak this language: it's only marginally more likely than getting struck by lightning)
User blocked: yes, if you get hit by car your main concern should be your torn jacket.
Yes, the script should be fixed, but none of this was ever going to cause any serious problems. - Alexis Jazzping plz14:16, 21 May 2018 (UTC)
Higher rate limits (900 edits per 3 minutes for autoconfirmed. 10500 per 3 minutes for Patrolled/autopatrolled/Image reviewer [2][3]) are now enabled. BWolff (WMF) (talk) 13:34, 21 May 2018 (UTC)
For those who haven't seen it: the error presented when trying to edit a page with the regular editor after exceeding the limit with a gadget
Thank you. (you dodged a pretty nasty rant by a hair.. I had already written it) The non-rant part of it: "This was broken by a change that was untested, undiscussed, unannounced, unproven to require such a speedy implementation and finally it was implemented in an unsafe way. The safe(r) way was to first implement it with a ridiculously high limit and gradually lowering it and monitor who (if anyone) is hitting the limit and why." (yes, this really was the non-rant part). - Alexis Jazzping plz14:16, 21 May 2018 (UTC)
I know. I only implemented it in this fashion because I really believed that 90/edits per minute was ridiculously high and that nobody would hit it (obviously a very mistaken assumption). I know this is not an excuse - but I was not as responsive as I should have been on this due to timing (First there was some other largely unrelated security issues that happened around the week of may 9 and beginning of next week that was stressful and occupied my time. Then there was travel to Wikimedia hackathon on wed where I was severely jet legged/over tired). In any case, I am aware that my handling of this was bad and I apologize. There may be times when we have to enforce unpopular things in the name of security, but this (at least at this point) isn't one of them - and if there does come a time where we would have to enforce something which hinders users for security reasons we would do proper community outreach and not some silent change. BWolff (WMF) (talk) 15:04, 21 May 2018 (UTC)
The Brexiteer parallel for gaslighting will linger. Please add "because, security" to the check-list of trust-me responses most likely to do the exact opposite. --Fæ (talk) 15:09, 21 May 2018 (UTC)
@Fæ: I think you're using wikt:gaslight#Verb ("To manipulate someone psychologically such that they question their own sanity, particularly by leading them to doubt their own experiences or perceptions of reality.") in a way different from common usage. If you think I'm actually doing that please provide diffs and an explanation as to how I'm actually doing that. Security stuff is a risk management sort of thing. Whether or not a security control is worth it, depends on the potential damage of the risk it prevents, the likelihood, and the cost (e.g. to users) of implementing the control. The rate limit was meant primarily as a hardening thing (e.g. lowish severity/likelyhood risk but also very low cost to users). I was obviously mistaken about the cost (but I still believe severity/likelihood is the same as it always was - which is relatively low. I can expand on that if you really want me to...), Thus the original rate limit was increased significantly because the cost of the rate limit was underestimated [After much prodding by the commons community. I apologize that the community was required to prod me to such an extent]. BWolff (WMF) (talk) 18:31, 21 May 2018 (UTC)
Was this a security issue? No, as later confirmed by yourself this could only be considered tangentially related to security, yet the original (not visible to me) change was justified as "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."
Was this an urgent change? No, there is still no evidence that this has been a necessary change, certainly there is no evidence that it had to be made urgently.
Did those making the change understand that the change was wrong? Apparently not, the response in the ticket was "If commons wants higher limit for some group, it must ask for some." This entire thread followed through on that position, by putting the onus on the Wikimedia Commons community to argue and push for facts against a apparently unjustified change.
Has a consensus for the change been sought or respected? No. The attitude from tech folks off-Commons is stated as "Community consensus shouldn't be bureaucracy blocking things that are seemingly urgent and should be resolved ASAP. I'm not going to require explicit Commons consensus." This is a bizarre statement with an implicit lie, there was no urgency, only fake urgency, and even now the stated conclusion of the ticket is to implement whatever Brian comes up with, not whether a successful proposal exists, or whether there is a Community consensus on what to do. The title of this section is a misleading lie, it should more factually read "so what does Brian want instead?" as there is no "we".
There is no proper analysis of risk, the only analysis has been to query how fast users have edited, and then put in limits that might not cause tools to fail. This is not a justification for putting limits in place, which now appear unrelated to actual risks of vandalism or security issues.
Yes, this all smells of gaslighting, because by asking very basic questions us unpaid volunteers have felt like incompetents and painted on Phabricator and here like we were causing a problem, and even now our consensus or opinions have zero weight compared to the arbitrary choices of Brian (the outcome being stated as "I changed the values to others per @Bawolff suggestion."). Even now we are being gaslighted by being shown as argumentative when we are simply pointing out these facts and calling it out for what it is.
PS Related to this subject, I see that Tm's comment has been removed from the Phabricator task. Could someone email it to me please? From what I recall of it, I find it bizarre that his opinion has been blanked from history unless Tm agreed to have it removed. @Ladsgroup: Thanks --Fæ (talk) 20:25, 21 May 2018 (UTC)
Re No, as later confirmed by yourself this could only be considered tangentially related to security: No, I meant it was tangentially related to the specific secret security bug you were referencing, not that it was tagentially related to security in general. The high-edit rate vandal at meta was one of the reasons for the change, but it wasn't the only reason. I believe that high-edit rate vandals are a threat, especially for smaller wikis. They are a threat to places like commons too, but a much lower threat then they are to a small wiki. The primary reason for this change was more of a hardening measure, against for example the case where 100 users all edit as fast as they can at the same time or other edit related DOS attacks. The nature of a hardening measure is generally to remove some of the attackers abilities by removing things that are unused. I thought the 90/edits a minute was an unused "feature". I was wrong.
Re urgency - I never indicated it was urgent (We make changes all the time. It wasn't an out of process change or anything. There was a public gerrit entry, and there was a pubic entry on wikitech:SAL. There are public feeds available for all changes that happen that people can subscribe to if they are really interested (This is of course really boring and most people aren't interested for the same reason most people don't actually read every change on Special:Recentchanges) There was no phab ticket specifically for this (The previously mentioned secret phab tickets are not specifically for this) as often phab tickets are more for planning future work/feature requests/discussions, and get skipped when those things aren't happening. Most changes of this type people don't notice, as we usually don't screw up the assessment of who it effects like I did with this change.). I also never claimed it was neccessary, only that I thought it was an improvement against certain risks (Very few things are 100% strictly necessary. Most things are more of a cost vs benefit)
Re Did those making the change understand that the change was wrong? - I am not a mind reader. I admit I screwed up here and should have investigated whether the change had negative affects on people. But given that I screwed up, I won't know I screwed up until someone tells me. That's the best I can do. The comment on the ticket of "If commons wants higher limit for some group, it must ask for some." was written before I was even made aware of the existence of that ticket (That said, I think its a fair statement - people can't fix things unless someone asks that they be fixed, regardless of where the fault lies).
As far as the Title of this section goes - the commons community thus far couldn't seem to agree what rate limit (other than infinity or values that are de-facto infinity, which I don't want - If you want to claim that my statement that I don't want infinity rate limits is without consensus, fair enough). If the community has an alternative agreed upon proposal for what non-infinity rate limit numbers they want, please let me know.
Regarding Urbancem's (A volunteer) statement that Community consensus shouldn't be bureaucracy blocking things that are seemingly urgent and should be resolved ASAP. I'm not going to require explicit Commons consensus." - General policy is that changes specifically requested for commons needs community consensus, where chanages that apply to mediawiki in general, do not (Whether or not you like that is irrelevant - that's just the way its been forever). Since the ticket is a request from commons community, it would normally require consensus. Urbancem's statement is simply that since this is seriously affecting commons, he's going to push the change through right away and disregard what would normally be a requirement. I imagine Urbancem stated this to cover himself in case someone complained about lack of community consensus. I'm not really sure why you are picking on his statements - he went out of his way to ensure that the 90 edit/min rate limit was significantly increased on commons - which is what you wanted. He essentially went out of his way to push through a partial revert of a change made by a WMF staff member - which can be a very intimidating thing to do as a tech volunteer (I have no idea if he felt intimidated by this. I certainly hope he wasn't. But at the end of the day there are power imbalances between staff devs and community devs, so its quite possible). You should be applauding Urbancem for taking the effort to fix something that I broke and that you wanted fix.
Re analysis of risk - I wasn't trying to analyze risk in those tables. I was trying to analyze effect on users. Whether or not we do something should be based on risk vs cost. I was trying to minimize cost, not determine risk. The risk as I see it is potential mass vandalism and potential (performance) DDOS vector (Really two different types of DOS attacks). I view this risk as relatively low (However I doubt I could put a number on it) on a large wiki like commons, but still worth mitigating if we can minimize cost on users.
Re final paragraph - if you can show me something you all agree on, I'll do it (Provided that it is not infinity. Sorry but I'm being an evil dictator on that part). I'm sorry if you feel like I'm blaming the community for "causing the problem". That's not my intent.
Re p.s. about Tm's comment. Based on who removed the comment, it was probably an official action of the code of conduct committee. I don't know anything about that. Maybe some sort of AGF type violation. I don't think I'm allowed to email you the comment as it might be considered "Attempting to circumvent a decision of the Committee" which is not allowed according to mw:CoC. BWolff (WMF) (talk) 20:38, 21 May 2018 (UTC)
Honestly the limit has been changed, if the limits are still not OK then ask what precise values you want and why. Otherwise move on, fights by principles only bring bad victories. I personally have trouble seeing a real bad intention of BWolff (WMF), or what he could do more. Christian Ferrer(talk)20:57, 21 May 2018 (UTC)
Thanks for replying so promptly here. Honestly, there was nothing about Tm's comment that stood out enough to fix in my memory as "harassment and other types of inappropriate behavior". I have difficulty believing it needed to be rapidly censored from view once Tm was advised about the CoC. As it has been censored by yourself, and based on the CoC nobody will now be allowed to discuss the act of censorship openly without risk of a global ban, I guess there is a lesson there about having a open discussion here on Commons where we are allowed to be critical so long as we intend to work collegiately and avoid creating a hostile environment, versus risking saying anything not perceived as "productive and collaborative" on Phabricator.
I strongly recommend that Tm considers the implications of the specific sanctions available to those that enforce the Technical CoC and how it works behind closed doors.
@Fæ: and @Ladsgroup: and thanks to your replies. The text was deleted without my consent or knowledge. I dont have a copy, but there was nothing more on my comment on Phabricator, then what i said already in here, before or after my comment on Phabricator. Anyone that reads my comments, in here, can see the differences between what is considered a debate in here and Phabricator, and make their own mind about why the text was deleted. Tm (talk) 22:11, 21 May 2018 (UTC)
@BWolff (WMF): "The short version is that we no longer want to have rate limits for editing of infinity except in groups that people are explicity added to. So continuing to have no rate limits for users who are bots and admins is cool, but we need some rate limit for autoconfirmed users."
@Majora: "That level should only be reserved for our most trusted individuals. And yes, admins fit that bill. That is the point of RfA. Determination of trust."
A compromised account does not "vindicate" you in any shape or form. Not in this area it doesn't. Nice try though. --Majora (talk) 18:50, 10 June 2018 (UTC)
Oh and by the way. Pinging someone else to falsely gloat about someone else is poor form. Very poor. I expected a slightly higher level of discourse in a supposed collegiate setting. --Majora (talk) 18:54, 10 June 2018 (UTC)
I don't gloat falsely, I just gloat. Even if we trust all admins unconditionally (which I also don't think is a good idea, but that's besides the point now), this hack proves we can't unconditionally trust admin accounts. So they should have a rate limit applied to them, for the same reasons and on the same conditions as autopatrolled users. Their limit may need to be higher, but that would have to be evaluated. - Alexis Jazzping plz19:49, 10 June 2018 (UTC)
I don't know what you think is new now we didn't know before. We always knew that Admin account compromise was a potential serious risk (Along with many other things). We (Or at least I) always knew rate limits would do nothing against that. The rate limits were not meant to combat that type of issue. There are many problems in the world. There's no one solution to all of them. The rate limits on non-admin accounts helps mitigate one small type of potential risk. It is a different risk than admin account compromise. BWolff (WMF) (talk) 22:33, 10 June 2018 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Question Who are you? Where do you speak from? What is your source? Yann (talk) 13:17, 17 May 2018 (UTC)
Support, rate limits don't make sense, mass-copyright violation uploaders will be nuked on sight anyhow, upload rate limits don't prevent them nor does it halt them. My concern is with all the good faith uploaders that hit this limit and don't know how to not hit it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:28, 17 May 2018 (UTC)
Oppose No. Thera are good reasons to keep ratelimits. --Steinsplitter (talk) 13:20, 17 May 2018 (UTC)
Comment pinging @Mike Peel: maybe you have some comment on this? - Alexis Jazz ping plz 11:26, 18 May 2018 (UTC)
Delete Kill This limit with fire. Another change to a core ability of edition made by stealth without consultation or discussion by the peasantry. This is another show of how WMF treats the communities. Make a change by stealth and so change the goalposts and them claim to discuss what you already changed. No proof that there is a need to limit the number of editions. Does the developers even comprehend how things work. To make a move of 200 files, that used to take 10 seconds, it now takes two minutes? Talk about a friendly interface. It is now frustrating to do any kind of some basic work, because some chap tought of this measure with is legs, and not with his brain. Tm (talk) 12:24, 19 May 2018 (UTC).jpg&diff=prev&oldid=298147528){kind=link}
.jpg&diff=prev&oldid=298148685){kind=link}
.jpg&diff=prev&oldid=265492022){kind=link}
Even if we trust all admins unconditionally (which I also don't think is a good idea, but that's besides the point now), this hack proves we can't unconditionally trust admin accounts. So they should have a rate limit applied to them, for the same reasons and on the same conditions as autopatrolled users. Their limit may need to be higher, but that would have to be evaluated. - Alexis Jazz ping plz 19:49, 10 June 2018 (UTC)