Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Community portal
introduction
Help desk Village pump
copyrightproposals
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P · COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

Commons discussion pages (index)


Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 

RFC: Change in Scope - Art & the education of intelligent machines (& people)[edit]

RFC/ PROPOSED CHANGE: ART AND THE EDUCATION OF INTELLIGENT MACHINES (& PEOPLE)[edit]

EXECUTIVE SUMMARY Considering art's unique role in education, how do we make space for paintings, drawings, non-photographic interpretations of what words mean within wikimedia? One suggestion would be to remove “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills” as an example of something that is not in scope and allow artwork to be removed on other grounds.

Open for discussion. This is important. What do you think?[edit]

See updated summary below
Considering art's unique role in education, how do we make space for paintings, drawings, non-photographic interpretations of what words mean within wikimedia? One suggestion would be to remove “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills” as an example of something that is not in scope and allow artwork to be removed on other grounds.
— Preceding unsigned comment added by Gretchenandrew (talk • contribs) 17:24, 19 January 2018 (UTC)

Gretchenandrew (talk) 17:56, 19 January 2018 (UTC)gretchenandrew

NEW SUMMARY OF DEBATE ART & WIKIMEDIA COMMONS[edit]

Art is an underrepresented knowledge form that has an important role in the education of people and intelligent machines. Its systematic disclusion and deletion from Wikimedia Commons, both as a matter of official scope and dramatically different interpretations of official scope, perpetuates knowledge gaps that serve to limit the usefulness, diversity, and impact of Wikimedia. Mainly for this reason I believe we should remove “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills” from OUT OF SCOPE.

Those that oppose this change have argued that:

Such a change would legitimize, “low-quality selfies in Category:Art.”@LX:
Not true. Low quality selfies could still be removed for “bad quality” or as “Private image collections.”
Wikimedia is not a Deviant Art like site and should not become one. @El Grafo:
REPLY “I think the concern is the change could lead to a large increase in the number of images hosted on the Commons, but I don't think that concern is a fair reason to dismiss this proposed change. I think it is important to emphasize that all other policies would still need to be followed for these potential new images, including COM:ADVERT. Beyond the reasonable educational explanation, each image would need to be appropriately categorized according to that explanation and otherwise presented and described properly.” @Psantora:
Anything can be considered art! @Ghouston:
While this is true it is not relevant. I am not suggesting that we keep files just because someone calls them art but that we not delete files because they are in a non-photographic medium, particularly when they address a subject in a non-immediately illustrative way such as when emotions/ mental illness are portrayed via paintings. This debate is not about what is and is not art, and who does and does not get to decide. This is not about allowing anyone’s and all drawings being uploaded and tagged as “art” but about drawings/paintings being tagged with their subject.
Images are not removed for this reasons, @Yann:
Not true. The debate on my recently uploaded images show this is not true.

Those that see the current status as an issue have argued that:

“There also needs to be an awareness among deleting admins that Commons does not exist simply to illustrate Wikipedia, and that artwork (photographic, painting, drawing, computer generated) need not be a direct illustration of some notable noun, but may be educationally useful if illustrating a mood, emotion, memory, concepts, arguments, beliefs, etc. We can have contemporary art illustrating sadness, joy, childhood, equality, environmentalism, holiness, love, etc, etc.” @Colin:
Category:Nude or partially nude women facing right - and I'm still not sure why those should be considered inherently more educational than drawings of people, things, or concepts that we have 0 photos for! @Seeeko:
I believe that pictures with educational value should be permitted but what constitutes "educational value" is often left to the whim of the closing admin which is why almost all "pornographic" images get deleted by default even if they are fully within scope. Art is no different, sure Wikimedia Commons can be used as a medium for self-promotion for new artists but the same can be said about "amateur photographers" @Donald Trung:
I think the "obvious" part of that example becomes too high of a standard for non-traditional media that is not photography. @Psantora:

Gretchenandrew (talk) 16:39, 10 March 2018 (UTC)

Updated summary of Gretchen's proposal:[edit]

  • Thanks for the summary, Gretchen. This hopefully will make it easier for others to comment. An even more concise summary, if I may:
    Proposal: Remove Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills from the second example given under the header Examples of files that are not realistically useful for an educational purpose: in COM:NOTUSED.
    Rationale (as described by @Gretchenandrew): Art is an underrepresented knowledge form that has an important role in the education of people and intelligent machines. Its systematic exclusion and deletion from Wikimedia Commons, both as a matter of official scope/policy and dramatically different interpretations of official scope/policy, perpetuates knowledge gaps that serve to limit the usefulness, diversity, and impact of Wikimedia.
    Arguments against (with rebuttals):
    • Paraphrased from @LX: Such a change would legitimize, “low-quality selfies in Category:Art.”
      Rebuttal from @Gretchenandrew: Low quality selfies could still be removed for “bad quality” or as “Private image collections”.
    • From @El Grafo: Wikimedia is not a Deviant Art like site and should not become one.
      Rebuttal from @Psantora (me): I don't think that concern is a fair reason to dismiss this proposed change. I think it is important to emphasize that all other policies would still need to be followed for these potential new images, including COM:ADVERT. Beyond the reasonable educational explanation, each image would need to be appropriately categorized according to that explanation and otherwise presented and described properly.
    • From @Ghouston: Anything can be considered art!
      Rebuttal from @Gretchenandrew: While this is true it is not relevant. I am not suggesting that we keep files just because someone calls them art but that we not delete files because they are in a non-photographic medium, particularly when they address a subject in a non-immediately illustrative way such as when emotions/mental illness are portrayed via paintings. This debate is not about what is and is not art, and who does and does not get to decide. This is not about allowing anyone’s and all drawings being uploaded and tagged as “art” but about drawings/paintings being tagged with their subject.
    • Paraphrased from @Yann: Images are not removed for this reason.
      Rebuttal from @Gretchenandrew: The debate on my recently uploaded images show this is not true.
    Arguments in favor:
    • From @Colin: Commons does not exist simply to illustrate Wikipedia, and that artwork (photographic, painting, drawing, computer generated) need not be a direct illustration of some notable noun, but may be educationally useful if illustrating a mood, emotion, memory, concepts, arguments, beliefs, etc.
    • From @Seeeko: I'm still not sure why those [Category:Nude or partially nude women facing right] should be considered inherently more educational than drawings of people, things, or concepts that we have 0 photos for!
    • From @Donald Trung: I believe that pictures with educational value should be permitted but what constitutes "educational value" is often left to the whim of the closing admin which is why almost all "pornographic" images get deleted by default even if they are fully within scope. Art is no different, sure Wikimedia Commons can be used as a medium for self-promotion for new artists but the same can be said about "amateur photographers"
    • From @Psantora (me): I think the "obvious" part of that example becomes too high of a standard for non-traditional media that is not photography.
  • Symbol oppose vote.svg  Oppose Wikimedia Commons is not for private/out of scope. I oppose the proposal. --Steinsplitter (talk) 10:54, 4 May 2018 (UTC)

End of summary[edit]

  • The way I'm reading this, there is too much variation and unfair judgement for what is determined to have an "obvious educational use" and it is used as a catch-all for practically any file to be deleted. In general, this is more obvious with files that are not photographic images. As a result, non-photographic images (and art in particular) are more likely to be casually deleted without any real debate or discussion as to their merit on Wikimedia. Amending policy by removing or softening Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills will force these discussions to have more substantial arguments for why these underrepresented images should be removed from the project. It is also important to again emphasize that this does not mean that Wikimedia will turn into Deviant Art or an image host. All other policies and rules regarding content would still need to be followed, it just would require an actual argument as to why a questionable file doesn't belong beyond just relying on the crutch of it needing to have "obvious educational use".
  • In addition, I contend the example in question does not actually support the policy it is supposed to represent. The policy as currently written is Must be realistically useful for an educational purpose and "educational" is defined according to its broad meaning of "providing knowledge; instructional or informative". There is nothing about the use being obvious.
  • Given these points and the argument summarized above, I think it is reasonable to change the example Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills to something that does not include obvious or even remove the example entirely. Here are some options:
    My suggestion (1):
    1. Remove the example entirely.
      Suggestion (2) from @Colin:
    2. Artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills.
      Suggestion (3) from @El Grafo:
    3. Artwork without educational use, including non-educational artwork uploaded to showcase the artist's skills.
      Suggestion (4) from @Christian Ferrer:
    4. Self made artwork without obvious educational value, without illustrative interest, or without any visual qualities, including non-educational artwork uploaded to showcase the artist's skills.
  • I think any of the above changes would benefit the project, though I would prefer one without "obvious" in it. ~ PaulC/T+ 16:51, 17 March 2018 (UTC)
  • Symbol oppose vote.svg  Oppose per all the opposes above. Also, to be in scope, a file has to be realistically useful in another WMF project. Where would such files be realistically useful?   — Jeff G. ツ please ping or talk to me 23:08, 24 March 2018 (UTC)
    • Without weighing in on any other issue here, @Jeff G.: I believe you are wrong at that. While use in another WMF project is sufficient for a file to be in scope, even the potential for such use is by no means necessary. For example, we're more than glad to have thorough photo documentation of the public activities of a member of a national legislative body, even though typically only a fraction of those have any potential for reuse on another WMF project. - Jmabel ! talk 04:24, 25 March 2018 (UTC)
      • @Jmabel: Wikipedia has articles on such bodies, their members, their legislation, and their indiscretions. There is no such use case for the OP's works (and the works of others similarly situated), I'm afraid.   — Jeff G. ツ please ping or talk to me 04:37, 25 March 2018 (UTC)
    • To be clear, while this proposal was raised by Gretchenandrew, it is not about their "works". It is about correcting ambiguous and inconsistently applied policy. Whether Gretchen's work would qualify is a completely separate discussion. Striking "obvious" from the example wouldn't then mean that anyone could upload anything for any reason. All other guidelines would still need to apply, including "Must be realistically useful for an educational purpose", as you noted. A very generous reading of your comment could be seen as being in support of option 2 above: Change "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills." to "Artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills." ~ PaulC/T+ 05:55, 25 March 2018 (UTC)
  • Symbol support vote.svg  Support El Grafo’s variant. The word “obvious” obviously prompts deletionist trolling. Incnis Mrsi (talk) 06:35, 25 March 2018 (UTC)
    • Just to clarify, do you mean #2 or #3 above? ~ PaulC/T+ 13:45, 26 March 2018 (UTC)
  • Symbol support vote.svg  Support El Grafo’s variant. Clarification: Support language such as "Artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills." Commons shouldn't be a Deviant Art type repository for artwork with no credible purpose, however the word "obvious" is clearly incorrect. Content is in-scope if there is a legitimate and credible in-scope purpose for re-use, even if that purpose was not immediately obvious. When content is challenged as out-of-scope, a credible rationale is required for how the content is in-scope. Non-notable artwork by a non-notable artist does not, in itself, have any credible purpose for re-use. I'd also like to note that diversity and topic-coverage is relevant. For example the content in Child art is clearly valuable, however there is diminishing value in each additional drawing. In particular, there is approximately value in retaining multiple drawings by the same child. Alsee (talk) 20:26, 25 March 2018 (UTC)
  • Pictogram-voting-question.svg  Question Sorry, still not clear. Can proponents of the change give an example of a file that would be allowed with their change that is not allowed now? --GRuban (talk) 14:26, 3 April 2018 (UTC)
    • My understanding is that the arguments for deleting these files are too general. I don't have any specific examples, but I'm sure others that are more familiar with image deletion on Commons can bring some up. I'm hesitant to point to anything uploaded by Gretchenandrew, since that would cloud the debate further. My point is that all other policies would still apply, so why not remove the ambiguous and contentious example if it isn't necessary? ~ PaulT+/C 02:58, 6 April 2018 (UTC)
  • After thinking about this, I don't see the problem with the word "obvious". In fact, this makes the example more restrictive, meaning artwork can only be proposed for deletion if its lack of educational use is obvious (e.g. a personal doodle). By removing this word, any artwork lacking educational use can only be proposed for deletion, not just the obvious ones. So the problem is not the word "obvious" but the subjective term "educational use". We likely can never agree on what is educational or not, so it is better to discuss this on a case-by-case basis. For this reason, I Symbol oppose vote.svg  Oppose any change. --P 1 9 9   15:32, 3 April 2018 (UTC)
Well said, the current wording allows a human decision on a case-by-case basis, and that's fine. Christian Ferrer (talk) 17:20, 3 April 2018 (UTC)
Here is the full text of the example in question: Examples of files that are not realistically useful for an educational purpose: Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills. The key here is "not realistically useful". The word "obvious" makes the example more expansive. That is, it purports that the file should be deleted if it isn't obviously educational. The actual policy states the opposite: The expression "educational" is to be understood according to its broad meaning of "providing knowledge; instructional or informative". There is nothing about the use being obvious. It is a little confusing because of the negative, but that is exactly the point. The example is a poor one and I think it should be removed. ~ PaulT+/C 02:58, 6 April 2018 (UTC)
OK, I see why you would read it that way. But even if we remove the word "obvious" (or rewrite it to "obvious artwork without educational use" - the way I read it), it won't change anything. Educational use would still need to be discussed on a case-by-case basis... --P 1 9 9   18:16, 10 April 2018 (UTC)
I don't see how your rewrite is any better, P199. The word "obvious" is not part of the policy, but "educational" is. Since "obvious" is not policy it should be removed from the examples. It is not any different from having a policy that states "only colorful flowers are allowed" with an example that states "flowers must have obvious color" and then people argue if a flower with shades of light-blue/grey "has obvious color" and since it is not obvious it is therefore against policy and should be deleted. Technically light-blue/grey is a color and the flower is therefore colorful, it just isn't obvious.
People by nature will use the easier to cite (and more restrictive) example instead of the policy, defeating the whole purpose of the broad policy in the first place. In this area the policy is intentionally broad, as stated directly in the explanation of the policy: The expression "educational" is to be understood according to its broad meaning of "providing knowledge; instructional or informative". There is nothing about how obvious the providing of knowledge needs to be, just that it is being provided. Having said that, "realistically useful" is part of the policy. This is not the same as obvious. Lots of things can be realistic but not obvious. (Sadly, I'm currently too tired to find a way to extend my colorful flower analogy to cover this distinction as well.) ~ PaulT+/C 04:06, 13 April 2018 (UTC)
  • I do not see why an unknown (and potentially bad) artist should have his place here; at least this is what I read in the sentence "…including non-educational artwork uploaded to showcase the artist's skills." If it's Picasso, fine, but if it's the husband of my cousin, I'd rather not have his artworks here. --Ruthven (msg) 20:19, 3 April 2018 (UTC)
    • I don't see an argument based in policy. How well known a creator is doesn't really matter as long as the file has an educational use and is allowed under other policies (see also child art). ~ PaulT+/C 02:58, 6 April 2018 (UTC)
Happy that is has been pointed out, and I echo, that the debate about whether or not my particular paintings are educationally useful is a separate, though related, conversation. Removing "obvious" would be an "obvious" first step. Unresolved would be the preference for photography, subject vs object, and the connection to the education of intelligent machines. Maybe another way of raising that would be to say that not all painted images are "art." But I very much support the taking of a first step and removing "obvious." Gretchenandrew (talk) 01:05, 12 April 2018 (UTC)
With an interest in bringing this discussion to consider again an more abstract example of why non-photographic mediums have educational value, I am adding 15 new images for the word Ubuntu which is an operating system but also roughly means:

Ubuntu (Zulu pronunciation: [ùɓúntʼù])[1][2] is a Nguni Bantu term meaning "humanity". It is often translated as "I am because we are," and also "humanity towards others", but is often used in a more philosophical sense to mean "the belief in a universal bond of sharing that connects all humanity".[3]

It is a strong word to show how photography will fail us. It is an important concept that wikimeida currently can only accept in its commercial, product form. It also happens to be the theme for Wikimania 2018 and therefore a good philososphy over which to debate the question: what images should be accepted as relating to this word? In this process, does anyone know how to change the title of this page from "ubutu" to "Ubuntu Operating System"? See discussion on this page started in 2006 OR how to add Ubuntu philosophy to this page? What's the best move? You can see the images over which I want to discuss re: ubuntu in its category: https://commons.wikimedia.org/wiki/Category:Ubuntu

Gretchenandrew (talk) 11:02, 1 May 2018 (UTC)
  • Symbol oppose vote.svg  Oppose Commons is not for think kind of uploads. --Steinsplitter (talk) 10:55, 4 May 2018 (UTC)
  • Symbol oppose vote.svg  Oppose To the extent it represents a real change in what we keep, it does not seem to be in a good direction. "drawings of people, things, or concepts that we have 0 photos for" seem clearly in scope even without this change.--Prosfilaes (talk) 22:53, 14 May 2018 (UTC)

WebM[edit]

Would it be possible to include already-transcoded WebM files as mainspace pages for wikilinking? For example, this 1910 Frankenstein film is only available as OGV in mainspace, but there is a WebM version available at file:Frankenstein (1910) - Full Movie.ogv#Transcode status. The problem with this is that some MediaWiki video extensions (for use outside of Wikimedia) support WebM but not OGV, so that only WebM videos can be wikilinked to. If the transcoded WebM videos can be included as mainspace pages (e.g. file:Frankenstein (1910) - Full Movie.webm), it will allow both video formats for wikilinking. The files already exist, so all they need is associated wikipages. I could manually download the WebM versions and re-upload them to Wikimedia Commons to make wikipages for them, but I am not sure if that is permitted. Nicole Sharp (talk) 22:09, 29 April 2018 (UTC)

@Nicole Sharp: this would be better suited as a feature request on https://phabricator.wikimedia.org/, but it may already be there. - Alexis Jazz 05:28, 10 May 2018 (UTC)

Ethnicity, gender, religion and sexuality[edit]

I'm wondering whether Commons should adopt a guideline comparable to en:Wikipedia:Categorization/Ethnicity, gender, religion and sexuality. We certainly have enough of the sort of problem it was intended to address, particularly for gender. - Jmabel ! talk 15:12, 30 April 2018 (UTC)

Sure. Such a guideline would greatly help in case of disagreement. Regards, Yann (talk) 15:20, 30 April 2018 (UTC)
  • Symbol support vote.svg  Support .   — Jeff G. ツ please ping or talk to me 03:14, 1 May 2018 (UTC)
  • Symbol oppose vote.svg  Oppose without modification. We don’t have the concept of “non-diffusing“ categories here and I, for one, would oppose its introduction—at least not without separate discussion, and COM:OVERCAT would need modification to accommodate it. Users’ wanting to put things in parent-&-child cats is already a fairly common cause of conflict. On that question in general, I think a solution more natural to the way we usually solve the ‘burial problem’ is instead to have (Topic) by (secondary property) cats, which keep the over-categorization at arm’s length.—Odysseus1479 (talk) 06:12, 1 May 2018 (UTC)
    • “non-diffusing“ categories is exactly why we need this policy. Yann (talk) 07:27, 1 May 2018 (UTC)
  • Symbol oppose vote.svg  Oppose Please write a specific proposal based on past cases on this project. -- (talk) 07:39, 1 May 2018 (UTC)

OK, here's a draft. Would anyone like to help hammer it into shape? (Since it is my proposal, currently in my user space, I retain the right to revert what I might consider hostile edits, but help with getting it to be a more appropriate proposal for Commons would be greatly appreciated.) - Jmabel ! talk 04:57, 10 May 2018 (UTC)

Pictogram voting comment.svg  Comment Maybe better to live with the mess for a little longer and hope (I think it should) COM:Structured data will solve some of these issues. This proposal would probably lead to less (specific) categorization which might hurt structured data in the long term. - Alexis Jazz 05:23, 10 May 2018 (UTC)

Question[edit]

Probably I'm asking a stupid question, but let it go: Is the following feasible? Say, we are looking at the page Category:Male guitarists from Turkey; then we want to know, which other country cats come with "male guitarists", and move backward to Category:Male guitarists from Tunisia or forward to Category:Male guitarists from Ukraine by using an alphabetical "key" on top of the page, the key always following the developments in Category:Male guitarists by country, automatically. Stupid question? Thanks for probable replies without insults. --E4024 (talk) 14:29, 14 May 2018 (UTC)

{{Category tree}} already does the job although it doesn't have a horizontal table-of-content-like output:
To display all subcategories, click on the "►".
But it looks like this could be done. De728631 (talk) 14:54, 14 May 2018 (UTC)

Rate limit is at 90 edits per minute[edit]

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.

Possible raises to

  • 600/min
  • 1000/min
  • original limit before implementation

Thoughts? —Preceding unsigned comment was added by 2600:387:5:80D:0:0:0:88 (talk) 13:30, 15 May 2018 (UTC)

Pictogram-voting-question.svg  Question Who are you? Where do you speak from? What is your source? Yann (talk) 13:17, 17 May 2018 (UTC)
  1. Symbol support vote.svg  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)
  • Symbol oppose vote.svg  Oppose No. Thera are good reasons to keep ratelimits. --Steinsplitter (talk) 13:20, 17 May 2018 (UTC)

@Yann:,https://phabricator.wikimedia.org/T194864 —Preceding unsigned comment was added by 2600:387:5:805:0:0:0:63 (talk) 21:34, 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 Jazz ping plz 22:17, 17 May 2018 (UTC)
  • Pictogram-voting-question.svg  Question To what does this limit apply? Uploads? Edits to pages? Something else? --Auntof6 (talk) 23:03, 17 May 2018 (UTC)
@Auntof6: everything I guess, as I ran into it while creating a mass deletion request. - Alexis Jazz ping plz 23:04, 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 Jazz ping plz 08: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 Jazz ping plz 08: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). -- (talk) 04:51, 18 May 2018 (UTC)
Limitation before collaboration
@: https://gerrit.wikimedia.org/r/#/c/432279/ (phab:T192668 and phab:T194204) (no, those links may not work for you, "Access Denied: Restricted Task") - Alexis Jazz ping plz 08:18, 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. -- (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. -- (talk) 10:35, 18 May 2018 (UTC)
@: Also, "the element of surprise" really does not work when fighting vandals. - Alexis Jazz ping plz 11:11, 18 May 2018 (UTC)
@: 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. -- (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, Revi 08: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. -- (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, Revi 12:33, 18 May 2018 (UTC)

Howdy folks - it was me who added the rate limit. So just to be clear: Previous state:

  • anons & new users: 8 edits/min
  • autoconfirmed users: ∞ edits/min, 380 uploads/72 minutes
  • Image-reviewer, patroller, autopatrolled: 999 uploads/second
  • Admins, bots, account creators: No limits

New 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 Jazz ping plz 11:26, 18 May 2018 (UTC)
Pictogram voting comment.svg  Comment pinging @Mike Peel: maybe you have some comment on this? - Alexis Jazz ping plz 11: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)
@BWolff (WMF): There is no edits/min limit for image-reviewer, patroller, and autopatrolled, right?   — Jeff G. ツ please ping or talk to me 13:34, 18 May 2018 (UTC)
@Jeff G.: I am autopatrolled and I am limited. - Alexis Jazz ping plz 13:45, 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". -- (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[edit]

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)
  • Image reviewers, patrollers, autopatrollers - 2000/5min.
  • bot, admin, account creators (groups with noratelimit right) - continue with no rate limit.

Would this address people's concerns? If not, please suggest an alternative. BWolff (WMF) (talk) 15:11, 18 May 2018 (UTC)

An additional note: We'll make whatever change is decided on Monday. BWolff (WMF) (talk) 15:38, 18 May 2018 (UTC)
  • Symbol support vote.svg  Support Regardless of how we got to this point, this seems reasonable. Storkk (talk) 15:17, 18 May 2018 (UTC)
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 Jazz ping plz 16:42, 18 May 2018 (UTC)
Rafic.Mufid (talk · contribs) does plenty categorization. He doesn't have autopatrol. He should not be limited to 270/3m. - Alexis Jazz ping plz 16:42, 18 May 2018 (UTC)
  • Symbol support vote.svg  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.   — Jeff G. ツ please ping or talk to me 16:02, 18 May 2018 (UTC)
@Jeff G.: are you supporting that new 270/3m proposal or the original "get rid of it" proposal? - Alexis Jazz ping plz 16:42, 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.   — Jeff G. ツ please ping or talk to me 19:50, 18 May 2018 (UTC)
  • Pictogram voting comment.svg  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 Jazz ping plz 16:42, 18 May 2018 (UTC)
  • I lean towards Symbol support vote.svg  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)
  • Pictogram voting comment.svg  Comment Commons:Village pump/Proposals/Archive/2018/01#Proposal to rename account creator group to batch uploaders was archived without action and is still technically an open RfC. I Symbol oppose vote.svg  Oppose blanket upping of any rate limits but I do support a need based rate limit exemption as indicated by my proposal. --Majora (talk) 20:17, 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 Jazz ping plz 21:16, 18 May 2018 (UTC)
I can understand why the limit exists, but building a mass-reversion tool would be better than just blanket limiting all users except for a privileged few. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:24, 18 May 2018 (UTC)
@Donald Trung: you know, Jcb blocked me exactly over “mass reversion” of the troll’s edits. Not a solution for this and other reasons. Incnis Mrsi (talk) 15:59, 19 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)
Yeah, admin accounts never (ever) go bad right? Just try to imagine (@BWolff (WMF): you too) what any of them could have done if they had fully exploited their (lack of) rate limit. - Alexis Jazz ping plz 01:01, 19 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 Jazz ping plz 11:15, 19 May 2018 (UTC)

@Donald Trung: this doesn't affect uploads. From the DefaultSettings.php:

type edits moves uploads rollbacks Trigger pw reset email Emailing other users using MediaWiki Purging pages Purges of link tables Files rendered via thumb.php non-standard thumbnails Stashing edits into cache before save Adding or removing change tags Changing the content model of a page
ip 8/m - 8/m - 5/60m 5/day 30/m 30/m 700/30s 70/30s 30/m 8/m -
newbie 8/m 2/2m 8/m 5/2m - 5/day - - - - 30/m 8/m 2/m
user 90/m 8/m - 10/m - 20/day 30/m 30/m 700/30s 70/30s - - 8/m
sysop noratelimit
bureaucrat noratelimit
bot ?
  • 'anon' any and all anonymous edits (aggregate)
  • 'user' each logged-in user
  • '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. Face-wink.svg

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.

There's more but people who are interested should read for themselves. - Alexis Jazz ping plz 20:52, 18 May 2018 (UTC)

Limiting rollbacks to 10/m severely impacts my antivandalism and antievasion work.   — Jeff G. ツ please ping or talk to me 03:34, 19 May 2018 (UTC)
@Alexis Jazz: - bots getting noratelimit comes from line 9975 of InitialiseSettings.php [1]. See also Special:ListGroupRights. BWolff (WMF) (talk) 08:55, 19 May 2018 (UTC)
@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 Jazz ping plz 11:15, 19 May 2018 (UTC)
@Alexis Jazz: So who does this 10/m rollback limit apply to, and what's my rollback limit?   — Jeff G. ツ please ping or talk to me 13:30, 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)
@Sixflashphoto: @Jeff G.: this is the default rollback limit for Mediawiki installations. I don't know what your limit is or if you even have one. - Alexis Jazz ping plz 17:43, 19 May 2018 (UTC)
@Alexis Jazz: 05:38, 13 May 2018 (UTC), I managed to MassRollback 27 of an INC sock's edits in one minute. Usually, the en:User:Writ Keeper/Scripts/MassRollback.js script just does some on a page and I have to refresh and try again.   — Jeff G. ツ please ping or talk to me 18:10, 19 May 2018 (UTC)
For 1 minute, you performed (extracted from your 5 minute record, I could search for your actual record but it probably won't be very different):
386 edits on 13:38, 24 March 2018
484 edits on 13:37, 24 March 2018
464 edits on 13:36, 24 March 2018
472 edits on 13:35, 24 March 2018
428 edits on 13:34, 24 March 2018
398 edits on 13:34, 24 March 2018
484 is more than 27. Your MassRollbacks would be somewhere in my stats, but they don't stand out. - Alexis Jazz ping plz 18:25, 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)

  • Symbol delete vote.svg  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)

  • Pictogram voting comment.svg  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. -- (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:

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

Thoughts? BWolff (WMF) (talk) 15:26, 19 May 2018 (UTC)

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

I'll now try some of the users BWolff came up with. - Alexis Jazz ping plz 16:46, 19 May 2018 (UTC)

@Alexis Jazz: All my stuff is based on public data from https://quarry.wmflabs.org/ (although i used command line to get around timeouts). I think the main reason mine is different is I only looked at data for the last month (in order to make queries fast) BWolff (WMF) (talk) 17:12, 19 May 2018 (UTC)
@BWolff (WMF): My queries (almost) take hours. They're not even queries! - Alexis Jazz ping plz 18:04, 19 May 2018 (UTC)
@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.   — Jeff G. ツ please ping or talk to me 17:34, 19 May 2018 (UTC)
I have your top 20 (and maybe more if I didn't accidentally throw it away), without duplicates:
The fact that none of these was vandalism related is also interesting. - Alexis Jazz ping plz 18:04, 19 May 2018 (UTC)

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):

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 rev_timestamp > '201800000000'  group by 1,2 order by 3 desc limit 60;
+--------------+------------------------+------+-------------------------------------+
| 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                                |
| 201801170413 | Artix Kreiger 2        | 2600 | NULL                                |
| 201804060237 | Jarnsax                | 2464 | NULL                                |
| 201804060233 | Jarnsax                | 2450 | NULL                                |
| 201803292141 | ToBeFree               | 2434 | extended-uploader                   |
| 201802080431 | Artix Kreiger 2        | 2428 | NULL                                |
| 201804060236 | Jarnsax                | 2351 | NULL                                |
| 201804060232 | Jarnsax                | 2314 | NULL                                |
| 201802080448 | Artix Kreiger 2        | 2249 | NULL                                |
| 201802052324 | Artix Kreiger 2        | 2220 | NULL                                |
| 201803310955 | Ser Amantio di Nicolao | 2216 | filemover,patroller,rollbacker      |
| 201804060227 | Jarnsax                | 2134 | NULL                                |
| 201802052323 | Artix Kreiger 2        | 2122 | NULL                                |
| 201804060231 | Jarnsax                | 2105 | NULL                                |
| 201801180316 | Jarould                | 2087 | filemover,patroller,rollbacker      |
| 201802261606 | Artix Kreiger 2        | 2027 | NULL                                |
| 201802080428 | Artix Kreiger 2        | 2023 | NULL                                |
| 201803201717 | Elisfkc                | 1972 | Image-reviewer,filemover,rollbacker |
| 201803201707 | Elisfkc                | 1921 | Image-reviewer,filemover,rollbacker |
| 201802212301 | Artix Kreiger 2        | 1876 | NULL                                |
| 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      |
| 201802080335 | Artix Kreiger 2        | 1780 | NULL                                |
| 201803031857 | Artix Kreiger 2        | 1768 | NULL                                |
| 201802212313 | Artix Kreiger 2        | 1745 | NULL                                |
| 201802131749 | Elisfkc                | 1693 | Image-reviewer,filemover,rollbacker |
| 201801180336 | Jarould                | 1652 | filemover,patroller,rollbacker      |
| 201801170420 | Artix Kreiger 2        | 1650 | NULL                                |
| 201802080333 | Artix Kreiger 2        | 1637 | NULL                                |
| 201804060234 | Jarnsax                | 1611 | NULL                                |
| 201802070448 | Artix Kreiger 2        | 1562 | NULL                                |
| 201802212304 | Artix Kreiger 2        | 1555 | NULL                                |
| 201801180315 | Jarould                | 1535 | filemover,patroller,rollbacker      |
| 201802052325 | Artix Kreiger 2        | 1527 | NULL                                |
| 201802070449 | Artix Kreiger 2        | 1527 | NULL                                |
| 201803022014 | Artix Kreiger 2        | 1515 | NULL                                |
| 201803032300 | Artix Kreiger 2        | 1506 | NULL                                |
| 201801170407 | Artix Kreiger 2        | 1500 | NULL                                |
| 201804011953 | Felis domestica        | 1500 | autopatrolled                       |
| 201804021243 | Maliepa                | 1500 | filemover,patroller,rollbacker      |
| 201803022015 | Artix Kreiger 2        | 1486 | NULL                                |
| 201805031529 | Ser Amantio di Nicolao | 1455 | filemover,patroller,rollbacker      |
| 201802071749 | Mr.Nostalgic           | 1445 | autopatrolled,filemover             |
| 201803022116 | Artix Kreiger 2        | 1430 | NULL                                |
| 201802131748 | Elisfkc                | 1417 | Image-reviewer,filemover,rollbacker |
| 201803292137 | ToBeFree               | 1395 | extended-uploader                   |
| 201803201419 | Jkadavoor              | 1388 | Image-reviewer,filemover,rollbacker |
| 201802060011 | Artix Kreiger 2        | 1386 | NULL                                |
| 201801180345 | Jarould                | 1385 | filemover,patroller,rollbacker      |
| 201802050541 | Tm                     | 1385 | Image-reviewer,filemover            |
| 201803021931 | Artix Kreiger 2        | 1370 | NULL                                |
| 201802261647 | Artix Kreiger 2        | 1368 | NULL                                |
| 201802261652 | Artix Kreiger 2        | 1342 | NULL                                |
| 201802080352 | Artix Kreiger 2        | 1339 | NULL                                |
+--------------+------------------------+------+-------------------------------------+
60 rows in set (2 min 17.91 sec)

BWolff (WMF) (talk) 17:55, 19 May 2018 (UTC)

@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 Jazz ping plz 18: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 Jazz ping plz 19: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 Jazz ping plz 19: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. -- (talk) 03:23, 20 May 2018 (UTC)

@: 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 Jazz ping plz 06: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?
Meh, illogical, volunteer time-sink, avoidable nonsense. -- (talk) 09:43, 20 May 2018 (UTC)
@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 Jazz ping plz 08: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 Jazz ping plz 14: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 Jazz ping plz 14: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. -- (talk) 15:09, 21 May 2018 (UTC)
@: 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.
-- (talk) 19:44, 21 May 2018 (UTC)
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 -- (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)
    +1 Jean-Fred (talk) 22:08, 21 May 2018 (UTC)

User:Fæ and User:Tm. I removed the comment on behalf of the CoC committee and part of their decision. For more information read mw:CoC Amir (talk) 21:35, 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.
Thanks again for your positive response. -- (talk) 21:48, 21 May 2018 (UTC)
  • @: 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)

Herbert Percy Horne[edit]

I am preparing the article Herbert Percy Horne who created the Fondazione Horne and it's Museum in Florence. There are no reasonable pics in commons.wikimedia.org . Who can help me finding out whether these two pics are free for an upload?

1) https://www.google.de/imgres?imgurl=http://luc.devroye.org/HerbertHorne-Pic.jpg&imgrefurl=http://luc.devroye.org/fonts-39607.html&h=1504&w=1156&tbnid=hdEX_canTXUY_M:&tbnh=123&tbnw=94&usg=__3eJ-rTqUap5qdaEt7_LNZmAsRsI%3D&vet=10ahUKEwjYvbfX4pPbAhXKy6QKHWVlDZgQ_B0InQEwDw..i&docid=dAVM6TWxo2avOM&itg=1&sa=X&ved=0ahUKEwjYvbfX4pPbAhXKy6QKHWVlDZgQ_B0InQEwDw 2) https://burlingtonindex.files.wordpress.com/2015/08/herbert-p-horne-ritratto-di-henry-harris-brown-1908-bassa.jpg

The first one (autor unknown) is a photograph created around 1890/1895. The second can be found in the Burlington Magazine, a portrait painted by Henry Harris Brown in 1908. Given the age of the painting (original in the Museo Horne in Florence) it should be free, isn't it?

Grateful for informations

Cantakukuruz
— Preceding unsigned comment added by Cantakukuruz (talk • contribs) 07:53, 20 May 2018 (UTC)
@Cantakukuruz: The first photo is quite borderline, but you can upload it with {{PD-old-assumed}} template (do not forget to specify the date). The second seems to be a portrait by Henry Harris Brown (1864-1948), still under copyright. --Ruthven (msg) 10:20, 20 May 2018 (UTC)
Thank you so much! Concerning the painting by Henry Harris Brown, I wrote to the Museo Horne and hope they will give us the permit to publish it. However, Brown's Copyright ends this year (2018), we can wait... Regards --Cantakukuruz (talk) 11:24, 20 May 2018 (UTC)