Wikimedia Commons

Commons:Village pump/Proposals

< Commons:Village pump
Latest comment: 14 hours ago by Zache in topic Proposal to add perceptual hashes to SDC

Shortcuts: 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; the latest archive is Commons:Village pump/Proposals/Archive/2024/04.

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?

 

Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

New draft of File naming guideline edit

Latest comment: 2 days ago177 comments29 people in discussion

There was a discussion recently on the English Wikipedia about whether including the photographer's work in the filename was relevant, specifically with images such as File:Murten Bern Tor photographed by Robbie Conceptuel.png. It was pointed out that Commons' file naming guideline is very terse, kind of a mess, and is actually a failed proposal - the closest accepted guideline is the Commons:File renaming policy. The "blatant advertising" renaming criterion was mentioned but I found a note in Commons:Requests for comment/File renaming criterion 2 that "re-naming a file to remove the author's name is inappropriate". I think that discussion has been resolved but it did bring to my attention that there is a gap in guidance - Commons has a detailed official guideline on renaming files, but no official guideline on what to name them initially.

Therefore, I took it upon myself to create a new draft, User:Mathnerd314159/File naming. I incorporated existing policies, guidelines, and advice from a variety of sources on Commons while trying not to create any novel policy. I was thinking that I would revise the draft to accommodate any comments and then once the draft is in a good state I would overwrite the main Commons:File naming page and there would be a vote on whether to adopt it. Mathnerd314159 (talk) 17:52, 22 March 2024 (UTC)Reply

Thank you for the work, and the proposal makes pretty much sense for me. Ymblanter (talk) 08:18, 23 March 2024 (UTC)Reply
  Support thanks for the work, I have made numerous move requests for nonsense filenames.Paradise Chronicle (talk) 08:47, 23 March 2024 (UTC)Reply
  Support +1 - Jmabel ! talk 09:55, 23 March 2024 (UTC)Reply
  Support +1 --Robert Flogaus-Faust (talk) 11:11, 23 March 2024 (UTC)Reply
  Comment — An important Commons constituency are third-party users. In the "Ideal" section I'd like to see a mention of the importance of choosing a name that is suitable for use/linking by third-party users. —RP88 (talk) 18:24, 23 March 2024 (UTC)Reply
I looked a bit but couldn't find many considerations in naming that were specific to third-party users. There is the general policy of stable filenames, which is partially to ease third-party use/linking, but that does not affect new uploads, so it is only mentioned in the introduction. There is searching for relevant files, but all Commons users appreciate better filenames in this task, so specifically identifying third-party users would be strange. Is there a specific file naming criterion that you had in mind that is important for third-party users but not relevant to first-party users? Mathnerd314159 (talk) 21:13, 26 March 2024 (UTC)Reply
Sorry, I wasn't as clear as I should have been. I'd like to see a mention of the use/linking by third-party users as an example/justification for the first point (the one that contains "...good idea to stick to graphemic characters, numbers, underscore..."). If I recall my Commons history correctly, linking by third parties was part of the original justification for suggestions of this sort when recommending preferred (as opposed to mandatory) name criteria. —RP88 (talk) 22:16, 26 March 2024 (UTC)Reply
The line in my guideline is from the original 2009 File naming guideline, there was a discussion on the talk. I see no mention of third-parties, it seems like the justification was that some files were being uploaded with control characters. I think most OS's/CMS's fully support UTF-8 filenames these days so generally any valid Commons name will be usable by a third party. When I kept the advice, I was thinking of stuff like w:Zalgo text. Mathnerd314159 (talk) 04:29, 27 March 2024 (UTC)Reply
  Oppose there are several problems with that approach:
  • the guidance that "filenames should be in English" violates our core Commons:Language policy.
  • Also, given that your initiative seems to have come from wanting to curbe the inclusion of the name of photographers as advertising or self-promotion, there should be some guidance that including the name of the photographer or archive is acceptable.
  • Also it's unclear if there is actually any added value in another page on the topic (Will we end up renaming because of the "file renaming policy" or because of the "file naming policy"?).
Further, I don't think the following is helpful and might make uploads of archives utterly complicated:
  • "The following styles of names are not allowed: Names consisting primarily of a broad location, such as a city, province, or country." Uploaders might struggle to be more precise than including the a city or province, but other contributors can easily complete descriptions and categories.
Enhancing999 (talk) 04:32, 24 March 2024 (UTC)Reply
  • On some of these, I think we need to distinguish between what is allowed and what is encouraged. Certainly that is the case for discouraging "broad location, such as a city, province, or country" and such files should probably be subject to renaming. I recently ran across a case where someone took 50 files of a single cemetery and gave titles that were each just the city name plus a number.
    Good catch on English, though. That's generally the case for categories, but file names can be in any language. - Jmabel ! talk 10:11, 24 March 2024 (UTC)Reply
    Even so, e.g. we have thousands of files from Ray Swi-hymn uploaded from Flickr with somewhat general, but useful filenames. Eventually some files end up fairly well described and categorized, but this is way beyond what can be done or expected from an uploader. Enhancing999 (talk) 10:32, 24 March 2024 (UTC)Reply
    @Enhancing999: I think you have separate the usefulness of a file name from the ability to categorize an image. Since they different ways of finding media that aren't mutually exclusive. If you want an example, check out how most stamps of the Soviet Union or Russia are currently named and categorized. Sure Russian stamps from 1996 are still categorized appropriately in Category:Stamps of Russia, 1996, but then the individual files are named after a catalog number from an obscure stamp catalog in Russian that no normal person has access to, cares about, or would use a way to search for the images. Especially on something like Google where descriptive file names are pretty important.
Regarding the English, I wrote in the minimum filename standards that any language was acceptable. The question I was attempting to answer was instead, for a multilingual uploader, which language they should use for their upload name. The language policy calls out English in several places (e.g., category names, creator names) so it seemed a good suggestion. I have updated it to prefer the language most relevant to the subject (based on Commons:Galleries#Naming_conventions). There could be further work on this guideline but at least the gallery convention encourages language diversity.
Author in the filename is listed in the minimum standards bullet list under "Names consisting solely of dates, the name of the photographer or rights holder, and/or words like “Flickr".
The "broad location" guidance is in the file renaming policy, there was a vote 15/18 that uploaders should do a "bare minimum" of work to include detailed locations in the filenames. For example File:20170712_ZurichRail_0932_(36101630414).jpg, arguably the filename is a "meaningless or ambiguous name". The only legible information is "Zurich Rail" but there is no Zurich Rail visible in the picture. The file could likely be renamed to a more informative name like "20170712-Lidl-Gretzenbach" without any opposition. Since it can be renamed, it is a bad filename.
There is some overlap between the naming and renaming policies, but the renaming policy actually specifically links to the naming policy page and says "Commons:File naming describes how files should be named." I would say the distinction is that the file naming policy describes how good a filename is (absolute scale), while the file renaming policy evaluates whether there is sufficient justification to rename a file (a certain arbitrary increment on the scale, from new to old). If this guideline does get accepted, likely some of the footnotes and explanations on the renaming page could be omitted as the file naming page goes into depth on those details. Mathnerd314159 (talk) 16:04, 26 March 2024 (UTC)Reply
  •   Support Per my comment above. We have a longstanding issue with people using file names for images that are to ambiguous or specialized to be useful. I think we should be able to separate the ability categorize something from the usefulness of the file name. Since they aren't mutually exclusive. Like with my example of how Russian stamps are currently named, sure they are "well categorized", but that doesn't mean that specific images are easy to find or that how they are currently named is at all useful to anyone. Anyway, we really need some kind of guideline to curb things like that. Although I do wonder how it would be enforced, but that's another discussion and I trust Mathnerd314159 will iron out the details before a final vote. --Adamant1 (talk) 17:23, 24 March 2024 (UTC)Reply
"There was a discussion..."
what's that?
  Oppose as @Enhancing999 has elaborated. RZuo (talk) 14:03, 25 March 2024 (UTC)Reply
  •   Support for the minimum standards. The ideal standards might need more work (vote   Neutral), but there have been improvements after Enhancing999 pointed out flaws. Mentioned is now: local languages are recommended for subjects; English would be standard for generic subjects. I don't know how this can be formulated better, but please imagine that we have the scan from a Polish book that features the 436th portrait of Columbus for Commons. Is "Ritratto Cristoforo Colombo" (it-Standard) better than "Portrait Christopher Columbus" (en-Standard) or shouldn't it be "Portret Krzysztofa Kolumba" (pl-Standard) because of the language of the book? On the other hand, which language can we reasonably expect when naming a photo of the Finnish folklore band that a Korean tourist took on their tour in Paris? en/fi/ko/fr could all apply. I would say all languages would qualify for "ideal" titles, as long as nothing is misspelled. But I'd also support that we focus on correcting file names that don't fulfill the minimum standards; rather than try to bring every name into "ideal" territory.
But we might want to (more clearly) discourage needless abbreviations: "pic org-com 4 wp glam-denco 02'10'2025" is a bad title, even if everyone involved knows that this is obviously a "picture of the organization committee for the Wikipedia-GLAM event in Denver, Colorado on October 02, 2025". Even if the description decodes that title and makes the picture searchable, it's too cryptic. The guideline covers "acronyms", but not abbreviations, so far. --Enyavar (talk) 09:20, 27 March 2024 (UTC)Reply
I think the policy may be useful for English language descriptions, or possibly filenames in English language Wikipedia, but Commons is not the English language Wikipedia file storage only.
It's still not consistency with our language policy to tell, e.g. Spanish language uploaders that they should use "chair" and not "silla" in the filename.
Also, the proposer's feedback fails to address the issue with large batch uploads, e.g. the thousands of files of the "Ray Swi-hymn" uploads. The "minimum standards" make these practically impossible. Maybe the proposer can try to work out a batch upload that consists of more than a dozen of images and attempt to tackle the issue in practice. The proposed guideline just doesn't scale to Commons size.
We already have multiple ways to describe files, we don't need another one. Filenames are already unambiguous, we don't even need a guideline for that, it's a technical necessity. Enhancing999 (talk) 09:45, 27 March 2024 (UTC)Reply
The argument for using English for general names is consistency of search results. If I search for "chair" I get pictures of chairs. If I search for "silla" I do not, the main results are an ancient Korean kingdom. There is one chair mixed in there, File:Silla de la Casa Calvet, Antonio Gaudí.jpg, but it is categorized as "furniture" rather than as a chair, so it does not show up when searching for chair. Just because an uploader "can" name their file "Silla de la Casa Calvet" does not mean that they should - there are actually 2 other files File:Gaudi's chair for Casa Calvet - Casa Milà - Barcelona 2014.JPG, File:Gaudi's chair for Casa Calvet - Casa Milà - Barcelona 2014 (2).JPG, so if the uploader knows English then naming it along the lines of "Casa Calvet Chair" would be more consistent. Similarly other terms like "armchair", "loveseat", "butaca", "confident" - they are all harder to search for than "chair". It is not really about language - if there was a really popular German term for something that had little usage in English, then likely using the German term would be appropriate - but I haven't encountered any such terms.
Regarding mass uploads, this seems to be a perennial conflict. For example in Commons:Batch_uploading/US_National_Archives#File_name_maximum_length_and_file_name_cutting_format, Teofilo stated "It is not realistic to correct all these file name errors afterwards one by one [...] The upload software bug must be solved. [...] I think the bot should be blocked until the file-name issue is solved." I certainly have some agreement with that - if Commons was willing to accept files under any name and rename them afterwards, it would not have global filename blacklists. Similarly, if an uploader is not willing to do any work on improving filename quality, how can they be trusted to have checked more important details such as licensing and that the file is of sufficient quality to be uploaded? Tools such as Pattypan allow easily changing the target filename and other details. What Commons needs is high-quality files with accurate and comprehensive metadata, at least meeting some minimum standards, not terabytes of garbage thrown in at random. And yes, I would include the "Ray Swi-hymn" uploads in this category of "garbage"- many photos are blurry, have no clear subject, seem like they have no realistic educational use, or are duplicates or worse shots of similar photos. The bad filenames are the least of the problems but serve as an indicator that minimal effort was made to curate the photos. Commons is not a Flickr mirror and does not need to blindly copy every single freely-licensed photo.
Regarding multiple ways of describing, filenames are not new and were the first method of describing files. I was reading a discussion where many users still reported finding files by their filename, finding categories and description data difficult to use. I suppose we could adopt something like Wikidata where all files are identified by an ID like Q691283, but I think this would make it more likely to have insufficient metadata for files, not less. As long as filenames are in use, it makes sense to have guidelines for how to write them. Mathnerd314159 (talk) 18:50, 27 March 2024 (UTC)Reply
Oh, so you are trying to fix search with the guideline. I understand, but this isn't the purpose of filenames at Commons. Enhancing999 (talk) 18:52, 27 March 2024 (UTC)Reply
No, I'm not trying to fix search, I'm trying to write a guideline. As I stated above there is a clear gap in policy, with Commons:File renaming referring to a non-accepted Commons:File naming page. I would be interested in hearing what you think the purpose of filenames is - my view is stated under "Purpose" - "Names are used to uniquely identify the item involved." But search visibility is certainly a consideration when choosing a filename, as are many other factors. Mathnerd314159 (talk) 20:04, 27 March 2024 (UTC)Reply
Are you trying to write that the descriptive word part of a filename should be unique or merely the string? Enhancing999 (talk) 20:14, 27 March 2024 (UTC)Reply
Well, clearly the string must be unique, as that is enforced by the software, but I also think that the intelligible part of the filename should be sufficient to distinguish it from other files. Like if there are "File:Duck-1.jpg" and "File:Duck-2.jpg", maybe they should have been uploaded with more detail in the filename, like "File:Duck-Cambodian Farm.jpg" and "File:Duck-Virginia Tech Pond.jpg". Mathnerd314159 (talk) 20:50, 27 March 2024 (UTC)Reply
Well, the rule is the language / name most closely associated with the subject. So for the Columbus example, if it is an original painting of Columbus, the name most closely associated would presumably be the name the painter used for Columbus. This could be the Italian, Spanish, Latin, or Old Portuguese spelling depending on the painter's preferred tongue. I think it is unlikely that Polish would be closely associated, as Columbus never went to Poland. Also English is unlikely, although I suppose it could be argued that Columbus is a "general subject" and the English spelling is therefore justified based on popularity. For the Finnish folklore band, I would say that the Finnish name is most appropriate if no text advertising the band is visible, otherwise French is most appropriate as it would match the name present in the photo. It is certainly a bit academic - few people are going to read the naming policy, and even fewer are going to put in the effort of finding the perfect name, but I think it is important to define what would be the perfect filename if renaming was zero-cost and we could endlessly debate and argue over filenames.
I added abbreviations to the list. Mathnerd314159 (talk) 17:29, 27 March 2024 (UTC)Reply
I think you misunderstand the problem. Many images are of general features that don't necessarily have a lanugage associated with it and we don't want English Wikipedia telling Spanish Wikipedia that English is ideal when uploading files in our Common repository. If you want to describe an ideal, don't make a guideline hindering uploads. Enhancing999 (talk) 18:44, 27 March 2024 (UTC)Reply
How exactly would it hinder uploading? Are you seriously going to argue someone from isn't going to know the dudes name is Columbus or not be able to put it in the file name? Look at it this way, its a global project, English is the prefered language and is spoken by most people in the world. Say you have someone who speaks a niche language like Basque and they want to upload a bunch of photographs they took on trip to the United States. Sure you shouldn't name files purely to help search results, but how exactly does anyone benefit from that user uploading those images in the Basque language? The four hundred thousand other people who speak the language are the only ones who are ever to see or use the files. And yeah, there's categories, but there's also an extremely small chance anyone who speaks the language will come along and be able to properly categorize the imahes to begin with. But hey, screw litterly everyone else I guess. --Adamant1 (talk) 19:23, 27 March 2024 (UTC)Reply
I think your comment is disrespectful, lenghty and off-thread. Enhancing999 (talk) 19:28, 27 March 2024 (UTC)Reply
That's not really a response, but whatever. --Adamant1 (talk) 23:32, 27 March 2024 (UTC)Reply
the premise of this discussion is still not given after a week. i see little value in any discussion. RZuo (talk) 07:49, 4 April 2024 (UTC)Reply

I'm a native English-speaker, but there is absolutely no reason why English should be favored over any other language for filenames, especially not to "make English-language search easier" and make searching in any other language harder. We want filenames that are decently descriptive in a language the person can actually write. It's bad enough that non-English-speakers have to cope with a mostly English-language category system (where uniformity actually is important) without making them use English where another language will do exactly as well or, in some cases, better. - Jmabel ! talk 22:46, 27 March 2024 (UTC)Reply

I should add: even as a native English-speaker I often use a different language, or a mix, in a filename when it seems more appropriate (e.g. my most recent upload as of this moment is File:Basilique Saint-Nazaire de Carcassonne from Hotel Le Donjon.jpg). I don't think there would be any gain in calling it the "Basilica of Saint Nazaire in/of Carcassone". - Jmabel ! talk 22:48, 27 March 2024 (UTC)Reply

@Jmabel: I'd argue file names should be in the most common form for the subject and whatever allows the most people to find, categorize, or use the image. That doesn't mean I think English should be favored, but if it's a subject where the name is in English to begin with and that's what everyone knows it by then the file name should be in that language. Same goes for something having to do with Korea and being in Korean, China and being in Chinese, Etc. Etc.
I could really care less about "English" per say, what I care about is people not writing file names that confuse people and/or make it harder or impossible for them to find the image because no one speaks the language or can decipher the code. Otherwise we could rename every file having to do with Christopher Columbus to "Cristóbal Colón" and call it good. Of course we aren't going to do that, but at the same time there should at least be some uniformity and common sense in file names. Otherwise what's the point in even having them? --Adamant1 (talk) 23:32, 27 March 2024 (UTC)Reply


Draft v2 edit

OK, I have uploaded a new draft. It seemed to me that the minimum vs. ideal distinction was perhaps a bit duplicative of the file renaming policy. Also the navigation was a bit difficult as the bullet points were not labeled. So I have collapsed it into a long list of the form "Name - criterion". I expanded the list with criteria from other projects, e.g. Wikipedia's article title policy. It is pretty long now but I couldn't see any obvious duplication and the "mess" of criteria well characterizes the state of affairs. I also added a language-specific section as that structure was on wikidata:Help:Label and it seems clear that a criterion like avoiding articles is language-specific. I also tried to address the language issue, by taking the English-specific guidelines (e.g. wikivoyage:Wikivoyage:Naming_conventions#Romanization) and negating them (c.f. "Language preserving" bullet point). Mathnerd314159 (talk) 02:05, 30 March 2024 (UTC)Reply

edit: I grouped the criteria so they're a little less messy Mathnerd314159 (talk) 02:59, 30 March 2024 (UTC)Reply

Usecase edit

How does other users feel about maintenance categories like Category:Cosplay at FanimeCon 2023 with bad file names?--Trade (talk) 23:54, 28 March 2024 (UTC)Reply

@Mathnerd314159 how would you go about such uploads? In terms of practical steps from files on your computer to files actually available for use on Commons? Enhancing999 (talk) 07:10, 30 March 2024 (UTC)Reply
I would look at the file, devise an appropriate name, and upload it? I guess if it was particularly tricky I might ask on the help desk - I would describe the contents and ask what a good filename would be. Or I would upload it under a bad filename and hope someone else renames it. Mathnerd314159 (talk) 16:04, 30 March 2024 (UTC)Reply
I don't think the initial method scales. There are 800 files in that category and if you ask 800 questions on help desk you might not get any help or even get blocked over it. So that essentially leaves you with "I would upload it under a bad filename". Can you add this to your proposed file naming policy? Enhancing999 (talk) 16:13, 30 March 2024 (UTC)Reply
It wouldn't be 800 questions for 800 files, it would be 800 instances of devising filenames and maybe 1-2 instances of asking for help. I myself am not particularly well-versed in cosplay but presumably a skilled contributor or three could go through all of those photos and identify the specific characters involved / media referenced. So if I made a help desk post it would likely be asking for such contributors to get involved.
My guideline already mentions that existing files with bad names will most likely stay. But I don't think it is a good idea to note that new files with bad filenames can be uploaded - it might be seen as encouragement of such behavior. Repeating myself, if someone cannot be bothered to devise a good filename, they likely will not add any metadata, and it is also questionable if they will select high-quality images in the first place. Like in this case, the cosplay photos have watermarks, are not particularly high resolution, and have no metadata relevant to their content. Apparently such images are not completely forbidden but are "strongly discouraged". I'm tempted to nominate them for deletion and see what happens - the uploader does not have a particularly good track record, and it is probably less work to delete them all and re-upload specific characters that do not otherwise have photos, than it is to systematically fix them. Given that Category:Files_with_bad_file_names_by_source lists 45.8k Flickr files, I would say it is definitely too easy to use the Flickr2Commons tool and use of the Commons:Batch uploading page should be required. Mathnerd314159 (talk) 18:36, 30 March 2024 (UTC)Reply
So practically, you want to prevent mass uploads of files where the uploader isn't sufficiently knowledgeable to devise the full description beforehand? Does this apply to Cosplay only or also to GLAMs or Flickr? Enhancing999 (talk) 09:55, 1 April 2024 (UTC)Reply
Well, GLAMs generally have good metadata. According to the discussion below, the issue is mainly Flickr. Mathnerd314159 (talk) 20:19, 1 April 2024 (UTC)Reply
I think you are confusing filenames and metadata, as well as uploaders and hosts. Flickr isn't an uploader. So bad file names if uploaded by GLAMs are ok? Enhancing999 (talk) 08:32, 7 April 2024 (UTC)Reply
It's more like the rate of bad filenames. Uploading a million files from a GLAM with 90% good filenames is pretty good - the junk doesn't matter, it is mostly invisible. And in the case of a GLAM there is often a metadata field suitable for use as a filename so such a 90% rate is achievable. Uploading 10 files, all with terrible filenames, probably deserves a warning - they are wasting their time uploading junk by hand when they should be writing better metadata, and also there is the w:broken windows theory suggesting that others will follow suite. In the case of Flickr, it seems a lot of files are uploaded by various people without changing the name (or adding a description, or anything really), and most names on Flickr are bad. A consistent effort to improve Flickr uploads could have significant effects. Mathnerd314159 (talk) 01:45, 8 April 2024 (UTC)Reply
The cosplay filenames aren't actually bad (such as misleading or fully undescript). It's unclear why GLAMs should be favored. We do have thousands of NARA files that don't meet your ideal. Enhancing999 (talk) 10:48, 8 April 2024 (UTC)Reply
It is simply about what is practical. For the cosplay, the user went through and added descriptions by hand to the ones they knew, like for example File:Cosplay of Denji, Power and Reze from Chainsaw Man at FanimeCon 2023 (53056133958).jpg. When they were uploading, they could simply have not uploaded the files they didn't recognize. With a GLAM / mass upload, simply examining each upload could be infeasible for a single contributor.
And you are seriously saying "the cosplay filenames aren't actually bad"? You are telling me you prefer the name "Fanime-2023-05-28-0362 (53055068002)" to "Cosplay of Denji, Power and Reze from Chainsaw Man at FanimeCon 2023"? In the bad filenames, the only relevant information is "Fanime", and it is unclear what it means. I could list off more criteria one-by-one but that is the point of the guideline, to establish a metric for evaluating filenames even in the absence of obvious comparisons. Mathnerd314159 (talk) 20:55, 8 April 2024 (UTC)Reply
I wish commons policy would forbid mass uploads with bad file names. Most of them are anyway not in use, many of those files are also just random files of whatever and they'll need to wait for years until someone appears and renames them correctly.Paradise Chronicle (talk) 16:51, 30 March 2024 (UTC)Reply
The problem are not the mass uploads of original content or GLAM content the only often problematic uploads are mass imports from Flickr or other image hosting pages. GPSLeo (talk) 19:59, 30 March 2024 (UTC)Reply
We could solve a good portion of the Shovelware and problems that come along with it like the bad file names just by banning mass imports from Flickr. 99% of the images from there are technically OOS, not being used anyway, and I can guarantee a lot of them would be deleted as non-educational if uploaded by regular uses. But for some reason it's totally cool to upload low quality, badly named, OOS scrap in mass as long as it is being imported from another site for some reason. --Adamant1 (talk) 04:39, 1 April 2024 (UTC)Reply
Usage on other Wikimedia websites doesn't necessarily indicate if a file has educational value or not. I often browse bookstores and check out random books and one thing I notice is that a lot of images I didn't even consider are used in educational ways. Random photographs of streets are often placed side-by-side to explain the evolution of a town if you read the Toen en nu ("Then and now") series of picture-books that are very popular among the elderly in the Kingdom of the Netherlands. Sometimes I think that some users see the term "educational" as something very narrow where if it's outside of the idea of educational materials they can think of they can't see the educational uses of a file.
The images from SmugMug's Flickr aren't too different from those of the national archives of many countries. To me, a random image of a random candle 🕯️ wouldn't be "educationally interesting", but to someone writing a book about different types of candles found around the world such an image would be very valuable. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:13, 1 April 2024 (UTC)Reply
That's a fair point. I'm just not a fan of how indiscriminate and uncurated (if that's the proper term) mass imports from Flickr are. Like people will just import thousands of photographs without meaningful descriptions or file names and not categorize them anywhere. Then expect us to do all the footwork to figure out what they are images of and how to organize them. It's just a very easy, selfish way of contributing to the project. On our end though we could at least have an approval process for mass imports from other websites like Flickr. I'm totally against them, but there should be some kind of oversight and the person doing them shouldn't just be able to dump a bunch of images on here and expect everyone else to do the work of sifting through them. --Adamant1 (talk) 05:29, 1 April 2024 (UTC)Reply
There I agree with you. If Universities and Museums upload their content, it is great, but those files usually also have a good filename and if that is missing at least a good description. But mass Flickr uploads are usually just a problem.Paradise Chronicle (talk) 08:20, 4 April 2024 (UTC)Reply
@Adamant1@Paradise Chronicle@Mathnerd314159 or better still, which may also solve COM:SCOPE debates and also reduces possible no-COM:FOP infringements: why don't we limit importation of Flickr files to just one file per import session? That will enforce discipline among all average users. Batch uploading may be allowed if the user conducting Flickr importation is a sysop/admin. JWilz12345 (Talk|Contrib's.) 23:11, 7 April 2024 (UTC)Reply
I won’t support Sysop/Admin batch uploading only, trusted users should also be allowed to batch upload. Bidgee (talk) 23:17, 7 April 2024 (UTC)Reply
@Bidgee perhaps extend to autopatrolled? (But yes, this may be a separate proposal for a new thread here.) JWilz12345 (Talk|Contrib's.) 23:55, 7 April 2024 (UTC)Reply
That sounds like a great idea. I'd probably support extending it to autopatrollers. Although I agree it's probably best for another proposal. --Adamant1 (talk) 00:07, 8 April 2024 (UTC)Reply

Final voting edit

Since feedback on my v2 draft was limited to one "thank", and comments on the first draft were generally positive, I have updated the main proposal page with my draft. This gives it better visibility and I think the overwrite is also an improvement as the voting on the old proposal was much less positive. I would say the proposal is "provisionally" final - someone could bring up new concerns, but I think all mentioned concerns have been addressed, besides enforcement w.r.t. Flickr imports, but guidelines generally do not include the enforcement process. So the main question now is whether it can become an official guideline. Mathnerd314159 (talk) 05:07, 7 April 2024 (UTC)Reply

  Support confirm support. Paradise Chronicle (talk) 14:28, 7 April 2024 (UTC)Reply
  Support, though I've made some edits. You can revert if you dislike them. - Jmabel ! talk 15:29, 7 April 2024 (UTC)Reply
  Oppose Still has issues that will cause more problems than it solves. “Consequently, new uploads should aim for the highest-quality filenames.” Big expectation and will differ depending on people’s opinion of certain file names.
in the Content-based “Names consisting solely of dates, the name of the photographer or rights holder, and/or words like “Flickr”, “original”, and “crop” are forbidden.”, overly vague (should have an example of what is and isn’t acceptable) and makes it sound like those should never be used when in cases it might be. Bidgee (talk) 16:14, 7 April 2024 (UTC)Reply
"will differ depending on people’s opinion": the point is that by establishing objective criteria for filenames, it will not depend on opinion. I suppose "highest-quality" is maybe too optimistic and I could instead say to aim for mediocre-quality filenames that are at least not terrible, or else to recommend spending between 10 and 30 seconds deciding on a filename (or some other range) – would either of those be better?
Content-based: This is from criterion 2 for renaming, "meaningless or ambiguous name", a widely accepted guideline. I added some examples. Mathnerd314159 (talk) 19:53, 7 April 2024 (UTC)Reply
While "meaningless or ambiguous name" in renaming has existed, it has also had its problems due to it being broad and subjective (as explained below, regarding "highest-quality filenames"). There have been times where I have used the camera file name for photographs that I took a large number of photos for (i.e. File:Harvey Hay Run 2020 convoy on Hammond Ave in Wagga Wagga (IMG 4705).jpg, File:Holden vs Ford track challenge at the 2012 Wagga Wagga Show (IMG 3146).jpg and File:Coulson Aviation (N137CG) Boeing 737-3H4(WL) at Albury Airport (IMG 4039).jpg), having it makes it easier to locate the RAW file to make new modifications/fixes if needed. Bidgee (talk) 22:41, 7 April 2024 (UTC)Reply
@Bidgee: how is "aiming for the highest quality" in any way controversial? - Jmabel ! talk 20:40, 7 April 2024 (UTC)Reply
Because it is subjective on what a "high-quality" file name is. Example is File:Helicopter A109LUH(NZ) by the NZ Defence Force.jpg, my view is should have been named File:Royal New Zealand Air Force (NZ3402) Agusta A109LUH(NZ) post maintenance flight.jpg, should "by the NZ Defence Force" be in the title? That is subjective also. Bidgee (talk) 22:30, 7 April 2024 (UTC)Reply
@Bidgee: what is an example where (for example) just "Flickr" and the name of the photographer would be an acceptable file name? Or some other combination of the things in this list? - Jmabel ! talk 20:41, 7 April 2024 (UTC)Reply
I never said just Flickr or the photographer as the file name. I'm saying they have their place and it doesn't make it clear as it was written but I can see the example given by Mathnerd314159 is exactly what I had been concerned about. Use of "original" and "crop" has its place, I use "original", when I have uploaded an almost unmodified version (separate) File:NT Police Speed Camera Unit (original).jpg (uploaded in 2012) that is different to the modified version File:NT Police Speed Camera Unit.jpg (uploaded in 2008). Then there are times that I have or others have cropped (File:Baby Latrodectus hasselti cropped.jpg) the original (File:Baby Latrodectus hasselti.jpg) file. Bidgee (talk) 22:21, 7 April 2024 (UTC)Reply
Just in looking, when uploading a modified version of a file, it is typical to use the original's filename and modify it for the upload ("cropped", "2", "3" "altered", etc.) Sometimes multiple versions are uploaded for choosing on feature picture nominations. Calling that practice "forbidden" now is definitely not correct -- this is a guideline I assume, not policy, and I certainly would not want to use this as justification for mass renaming of existing files. Maybe say "discouraged", at most, but once a filename exists then modifications using that as a base seem fine. Carl Lindberg (talk) 22:57, 7 April 2024 (UTC)Reply
The point is to forbid filenames that consist solely of such identifiers. It is fine if they are there, just not if there is nothing else. I already have a whole sentence "It is not forbidden to include such information" so I am not sure what else would make this clear. Mathnerd314159 (talk) 23:05, 7 April 2024 (UTC)Reply
Well it implies that, as does the example file name (noted above). Bidgee (talk) 23:19, 7 April 2024 (UTC)Reply
@Bidgee: I think you may simply be misreading (and I don't know what "example file name (noted above)" you are referring to, since there have been numerous filenames on this page). The sentence you quoted begins, "“Names consisting solely of…" (emphasis mine), but you seem to be flatly saying that it is an exclusion of using these things at all. If I say, "I won't eat a meal consisting solely of broccoli," it doesn't mean I won't eat broccoli. - Jmabel ! talk 14:07, 8 April 2024 (UTC)Reply
Really? This reads nothing like a guideline. "This page is designed to aid uploaders in selecting proper names for their files, promoting standards of excellence in filename conventions." We are not a university, the guideline should be about helping uploaders to select/pick filenames that are ideally appropriate/suitable. "It is important to note that while this page provides recommendations for creating high-quality filenames, the recommendations are not intended to serve as standalone justification for renaming files." Drop "high-quality" and replace with "suitable" and why do we need to repeat "recommendations" twice? "... balancing the principles outlined here with the costs of renaming files. In general, the costs of renaming are significant, so Commons aims to provide stable filenames and renames are limited." Why use "costs"? And how is it "significant"? Renames are not limited, just recommended not to be done too often. Keep the guideline simple (like Commons:Image annotations, Commons:Galleries), not complex, since it currently reads like a policy. Bidgee (talk) 05:16, 11 April 2024 (UTC)Reply
OK, I guess the phrasing was a little over-the-top. I have addressed the issues you mention, besides complexity (w:WP:MOS is a lot more complex). In the future you can be bold and fix it yourself, I won't mind. Mathnerd314159 (talk) 05:35, 11 April 2024 (UTC)Reply
  Support I still have a few issues with the whole thing myself, but Perfect is the enemy of the good and overall this seems like a good proposal. Some guidance on how to name files is clearly better then none. The few objections just seem like nitpicking, or at least things that can be ironed out later. You can't really iron out a guideline that doesn't exist in the first place though. --Adamant1 (talk) 00:12, 8 April 2024 (UTC)Reply
  Strong oppose: One seldom sees in Commons so many bad ideas bundled toghther with so much support from otherwise serious users. -- Tuválkin ✉ ✇ 23:35, 8 April 2024 (UTC)Reply
I am a bit confused. I believed, it was quite an improvement. Then what would be your suggestion to prevent uploads like this or this, there are several more of those... They were uploaded in 2020, with ambiguous filename, received a Basel category in 2022, and I eventually moved it to Nature in Basel in 2024. I don't know where in Basel there is such a landscape, its a city and there is not much nature. Or this one with simply Zurich, panoramio and numbers in the filename, uploaded in 2017, received a Zurich category in 2017 and was eventually moved to Nature in Zürich by me in 2024. We still don't really know where it is, what it shows etc. There is a problem with identification and I'd be glad if we could find a solution together. Paradise Chronicle (talk) 23:52, 9 April 2024 (UTC)Reply
Can you elaborate on these "bad ideas"? Mathnerd314159 (talk) 00:19, 10 April 2024 (UTC)Reply
No addressable / transparently-explanatory reasons have been given here so this is anything but a "strong" oppose. Agree with Paradise Chronicle but there are way worse filenames than PD's examples like "Jmse-10-01816-g001-550 hor.jpg". Prototyperspective (talk) 11:57, 14 April 2024 (UTC)Reply
  •   Comment This looks OK for best practice, but it should not be required (guideline, not policy). We basically have five redundant descriptions of the files - the filename, the categories, the caption, the description, and the structured data. Of those, I would argue that the least important is the filename, and the most important the categories, since that's how people currently find files (although that will hopefully transition to structured data in the long term). I reflect this in my uploads - since I upload a lot of files using batch uploading, giving them quite generic filenames (such as 'At Singapore 2023 001') is the most efficient way to get them uploaded to roughly the right place, and after that point my time goes into categorisation/use/QI. Requiring filenames to be more detailed would be a huge blocker to my workflow, although I never object to people renaming my uploads if they want. Thanks. Mike Peel (talk) 17:58, 9 April 2024 (UTC)Reply
    Did I not say in the beginning "the main question now is whether it can become an official guideline"? I was never proposing this to be a policy. Even Commons:File renaming is not a policy. Mathnerd314159 (talk) 20:41, 9 April 2024 (UTC)Reply
    There's too much text to easily spot that, but I've happily changed this from oppose to a comment on that basis. Thanks. Mike Peel (talk) 20:57, 9 April 2024 (UTC)Reply
    It does read the contrary on the page itself and it would still be a guideline GLAMs and users like @Mike Peel are expected to follow. An alternative could be to make an essai somewhere, e.g. MAthnerd's user namespace. Enhancing999 (talk) 21:18, 9 April 2024 (UTC)Reply
  •   Oppose as per Tuválkin. This all seems like a terrible idea. Strakhov (talk) 21:23, 9 April 2024 (UTC)Reply
    Could you elaborate on this? In my opinion filenames such as File:-i---i- (3042676940).jpg or File:"1JahrNurBlockiert", Demonstration von Fridays For Future, Berlin, 13.12.2019 (49239439091).jpg are not really helpful, both have multiple duplicates that (I believe, haven't checked all) only vary by a number. Also no helpful descriptions are there. Paradise Chronicle (talk) 16:52, 11 April 2024 (UTC)Reply
  •   Oppose This proposal does not solve a single problem that, to my knowledge, is not already regulated elsewhere or covered by the renaming rules. Instead, it creates additional hurdles and complicates things further, which will deter many potential uploaders. In addition, such a collection of rules will be used by some regulation and order fanatics as justification for enforcing their own ideas against the wishes of those contributors or creatives who are responsible for the actual content in the media sector, thus causing resentment, disputes and completely unnecessary extra work. --Smial (talk) 12:13, 10 April 2024 (UTC)Reply
There will be less disputes and extra work if file names are "correct" to begin with. --Adamant1 (talk) 14:35, 10 April 2024 (UTC)Reply
You are never going to avoid the need for renaming and naming disputes, with or without a File name guideline. Bidgee (talk) 05:18, 11 April 2024 (UTC)Reply
Sure, but disputes can be greatly reduced, if not totally mitigated, by having guidelines. Instead of people just endlessly bickering about something because we can't be bothered to give people guidance on the best way to do something or how to do it properly for some bizarre reason. --Adamant1 (talk) 06:57, 11 April 2024 (UTC)Reply
You're right that this is generally duplicating the renaming rules. However I absolutely do not expect new users to be aware of our renaming rules, whereas there should be a guideline accessible to them on how to name filenames correctly in the first place. Today, as far as I know, the only guidance they get is Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg on Special:Upload. Consigned (talk) 11:17, 19 May 2024 (UTC)Reply
  Support Very much support proper filename guideline. Details could be discussed there but as far as I can see things are fine. I do object to "When it comes to organisms and biological subjects, the scientific (Latin) name is recommended." even though it's just a recommendation. I think the most widely and most reasonable name should be used (except if incorrect/inaccurate). For example the word kidney should be used over phrases with "renal". Prototyperspective (talk) 00:06, 12 April 2024 (UTC)Reply
The Latin recommendation is from Commons:Galleries#Naming conventions, "An exception to this rule is the naming of galleries of organisms and subjects where Latin names are considered universal." And then I added "biological" as the grammar was a bit strange and I couldn't think of any other "subjects where Latin was universal". And then "scientific" came from w:WP:COMMONNAME, where there is a note "Common name in the context of article naming means a commonly or frequently used name, and not necessarily a common (vernacular) name, as opposed to scientific name, as used in some disciplines." It is certainly something worth discussing. Like there is the w:Terminologia Anatomica, using it as a systematic naming scheme for files would be good, but nobody uses it so it would be hard to adopt. For now I have changed "biological" to "botanical". As w:WP:FLORA says, in the vast majority of cases, the most common name will be the current scientific name. In the cases where it isn't, I expect the common name would not translate. Mathnerd314159 (talk) 03:53, 13 April 2024 (UTC)Reply
@Mathnerd314159: We have other biological names than botanical ones, so I oppose your change from "biological" to "botanical".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:12, 13 April 2024 (UTC)Reply
You write "so I oppose" but you didn't give any reason and didn't address the one I gave. People understand and search for certain things like kidney cancer and a few people use some words of a dead language the vast majority doesn't know, search for, or understand. Prototyperspective (talk) 13:18, 13 April 2024 (UTC)Reply
@Prototyperspective: I gave a reason. Latin is not dead in biological names, or binomial if you prefer. Thus saith a Homo Sapiens Sapiens.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:37, 13 April 2024 (UTC)Reply
Google is pretty clear that binomial names apply to "animals and plants" and "organisms". Indeed Homo sapiens qualifies as an animal and an organism. You have not given any examples of binomial names that are not organisms or plants. Mathnerd314159 (talk) 15:44, 13 April 2024 (UTC)Reply
@Mathnerd314159: I will stick with "biological".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:04, 14 April 2024 (UTC)Reply
And it doesn't mean people can't use the word renal or "cat" instead of "Felis catus". There needs to be some guidelines for descriptive useful filenames but at the same time it shouldn't be overprescriptive. Prototyperspective (talk) 13:36, 13 April 2024 (UTC)Reply
Perhaps the word you want is "taxonomic"? - Jmabel ! talk 14:03, 13 April 2024 (UTC)Reply
I don't know if you are you replying to me. No, images like "A cat catching a mouse.png", "Three people operating a robot.png", or "Statue of a dog.png" etc should not be recommended to be called "Felis catus catching a Mus musculus.png", "Three Homo sapiens sapiens operating a robot.png" and "Statue of a Canis lupus familiaris.png".
Categories and file descriptions can be used for that and they can still be named like that without this being in the guideline. This is absurd and partly because Jeff has still not given any reasons for the objection, I won't continue debating this which would just produce a walls of empty text. Prototyperspective (talk) 15:03, 13 April 2024 (UTC)Reply
@Prototyperspective: you are making a straw man argument. Presumably no one would prefer those file names, especially insofar as they refer to very common species (especially homo sapiens). Personally: I'm still normally going to say "gull" rather than larus, but if I know for sure I've got a Larus fuscus I might well use the species name rather than "Lesser Black-backed Gull." - Jmabel ! talk 06:24, 14 April 2024 (UTC)Reply
This whole thing about using species names or not seems rather tangential. Is there a reason it can't be ironed out or further clarified after the guideline is implemented (assuming it is. Otherwise, the conversation doesn't really matter anyway). --Adamant1 (talk) 06:48, 14 April 2024 (UTC)Reply
Not a strawman but showing how ridiculously bad these specific proposed recommendations are. What's in your mind regarding common sense does not undo what's on paper/text. As Adamant1 said, those things can still be fleshed out later on and I support the guideline for adoption except for this part. Prototyperspective (talk) 12:01, 14 April 2024 (UTC)Reply
To clarify: I still oppose this part. It doesn't diminish the overall support since details like that could also be changed later on and because a recommendation doesn't mean it has to be applied while Latin names may be useful in some cases. But this part really needs to be removed. You know humans are organisms right? Are file titles really recommended to use e.g. "Felis catus" instead of "cat"? I also oppose the part about "Language preserving" – I want to use file titles of the most widely understood and on WMC most widely-used language, English, for probably all media I upload. I think RZuo raised a few segments of the text where weakening them away from "should" may be a good idea. Prototyperspective (talk) 12:02, 19 May 2024 (UTC)Reply
The following was removed from the draft: When it comes to organisms and botanical subjects, the scientific (Latin) name is recommended. Could this be reworded as When it comes to organisms and botanical subjects in a scientific context, the scientific (Latin) name is preferred, but local languages are acceptable.? I think it is useful to recommend using Latin names in scientific areas. Consigned (talk) 16:15, 19 May 2024 (UTC)Reply
I'd have no active problem with that, but it is getting fairly long. I'm wondering if we'd do better to have somewhere that we lay out weird exception cases rather than the main flow of the document. But, yes, I think that should be said. - Jmabel ! talk 16:55, 19 May 2024 (UTC)Reply
It's actually explained in the current upload process. Enhancing999 (talk) 16:58, 19 May 2024 (UTC)Reply
  •   Support per Adamant1. -Contributers2020Talk to me here! 15:27, 12 April 2024 (UTC)Reply
  •   Oppose There isn't a good policy reason why English must be preferred for file names. Status quo works, and is more fitting for a multilingual project. Abzeronow (talk) 20:46, 14 April 2024 (UTC)Reply
    @Abzeronow From where do you take that English must be preferred? The phrases on languages I see in the proposal are: These guidelines apply to names in English. Speakers of other languages may define guidelines for their language in the relevant translations. Paradise Chronicle (talk) 21:05, 14 April 2024 (UTC)Reply
    Probably from the discussion above, regarding an earlier draft. I did change it though. Mathnerd314159 (talk) 23:01, 14 April 2024 (UTC)Reply
  • We should at least take into account the principle of least astonishment. DS (talk) 22:15, 2 May 2024 (UTC)Reply
  •   Support as currently written, especially taking into account the principle of least astonishment.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:57, 2 May 2024 (UTC) - amended.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:34, 20 May 2024 (UTC)Reply
  •   Support per nom. this would presumably be a nice starting guideline for someone who may not know how to name things well or otherwise want a nice "standard" to stick to.
    something that I also would like adding as a possible template is {source} - {name}, this I have seen mostly batch uploads, such as in fonts (see Noto) and I have used for magazine issues at lipu tenpo illustrations. Juwan (talk) 20:03, 9 May 2024 (UTC)Reply
  •   Support. Thanks for your work in codifying something that is referenced in many places but lacks a guideline. It seems to accurately summarize the various other references to this topic as well as best practices followed today. Consigned (talk) 18:53, 16 May 2024 (UTC)Reply
  •   Comment @Ymblanter: @Robert Flogaus-Faust: @RP88: @RZuo: @Enyavar: You responded to the first version; if you haven't already, can you review the current proposal? Consigned (talk) 18:34, 18 May 2024 (UTC)Reply
    Sure. Is there a link? --Enyavar (talk) 18:40, 18 May 2024 (UTC)Reply
    @Enyavar it is updated in-place at Commons:File naming. Mathnerd314159 (talk) 18:56, 18 May 2024 (UTC)Reply
  •   Support Well, a lot of consideration and re-writing has gone into this, and as long as this is just a guideline (no new restrictions on uploading will directly follow from this, right?) for anyone read and consider when naming files, I will gladly   Support this, also per MikePeel and Adamant: Better have a good-practice guideline rather than having none. I checked the oppose-voices and and didn't find compelling arguments against the new proposal. I have a feeling that English will remain the only additional "Language-specific guideline". --Enyavar (talk) 19:21, 18 May 2024 (UTC)Reply
    @Enyavar we already have such guidance, but this is actually a policy that can lead to blocks of non-compliant uploaders. Enhancing999 (talk) 22:21, 18 May 2024 (UTC)Reply
    I don't think we already have such guidance on naming files, we only have a policy/guideline on renaming (Commons:File renaming). Special:Upload currently just says Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg. but ought to link to a more detailed policy/guideline page with more information. Consigned (talk) 01:11, 19 May 2024 (UTC)Reply
    As far as I have read the guideline, there is nothing in there to announce sanctions against people who don't comply with it.
    But just to clarify: Would an uploader of material like File:Colorado -Adams County - Las Animas County (part)- - NARA - 17443770 (page 700).jpg get blocked, if they persist to upload material like the linked one, after this guideline goes into effect? Note how the name only indicates that this is a NARA document of any place in Colorado located in a county with a name alphabetically between "Ada" and "Las". That example file is following a naming scheme, but a very very bad one with respect to our guideline. Now, if such an uploader cannot be convinced to use a better naming scheme: would we use THIS guideline as a cudgel to block them? As it is currently outlined, I don't think so. The only consequences that the guideline announces, is that files which don't comply with the guideline, may get moved. --Enyavar (talk) 08:52, 19 May 2024 (UTC)Reply
    I don't think that that filename is horrible, and I would hope that a person who consistently uploads filenames like that wouldn't get blocked, as there is likely a good reason why the filename is so (e.g. bulk uploads). Enhancing999 does raise a good point - should the guideline clarify what the consequences are? Is there a policy somewhere that explains when guidelines become blockable?
    Personally I don't think that this guideline should be creating new blocking criteria - the same norms today regarding blocking for disruption and wasting community time (which could feasibly happen due to file name issues) ought to continue to apply. Consigned (talk) 11:09, 19 May 2024 (UTC)Reply
    Users are expected to follow guidelines. Or is it just users except NARA?
    Supposedly they are likely also to get in trouble with getting their filenames into neutral POV. Historic materials tends to not necessarily reflect current enwiki views on the topic. Enhancing999 (talk) 15:37, 19 May 2024 (UTC)Reply
    If an uploader wastes community time today by uploading useless filenames, e.g. IMG12345.jpg, and the community reaches out and they continue to waste community time, I expect they could be blocked today. This guideline just helps to clarify the reasons why. That said the level of disruption would have to be quite high, and I don't expect "bad but not useless" filenames would rise to the level of blockable disruption, today or in the future with this guideline. Consigned (talk) 16:08, 19 May 2024 (UTC)Reply
    If this is your only point, we don't need the new guideline.
    Such filenames are already not possible today and were by the previous version. The explanation in the upload wizard is fairly explicit.
    If you think the guideline shouldn't be applied in some cases, but should be applied in others, the guideline should say that. Otherwise contributors might not appreciated to be blocked while some archive continues with the same. Enhancing999 (talk) 16:20, 19 May 2024 (UTC)Reply
    I agree that the guideline should make it clear what the consequences are of violating it. But it is a problem today that we might block on something that does not a clear guideline; users should not have to understand our file renaming procedure or vague community norms in order to learn how to best name files. Consigned (talk) 16:24, 19 May 2024 (UTC)Reply
    Are you using a socketpuppet account for this discussion? Enhancing999 (talk) 16:27, 19 May 2024 (UTC)Reply
    Lol, no. Do you want to continue this discussion on the merits of the argument? Consigned (talk) 16:31, 19 May 2024 (UTC)Reply
    In that case, you might not be aware of what current uploaders get as guidance. Try the usual upload process. Enhancing999 (talk) 16:34, 19 May 2024 (UTC)Reply
    As I've pointed out in other comments, to my knowledge the only guidance users get at Special:Upload is Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg. Is there other guidance that I'm missing? Consigned (talk) 16:37, 19 May 2024 (UTC)Reply
    Try to upload a file with that name and see what happens. Enhancing999 (talk) 16:39, 19 May 2024 (UTC)Reply
    @Enhancing999: I have never uploaded a file with the Upload Wizard (or maybe one or two just to try it, years ago). Does that disqualify me from discussing file naming? I think not. - Jmabel ! talk 16:58, 19 May 2024 (UTC)Reply
    Well, you don't seem to have problems picking good filenames and you don't lecture Commons about using English or Cyrillic.
    I do think you need to have some experience with Commons to contribute anything of substance to this discussion. Merely attempting to reason based on English Wikipedia article titles is obviously not working.
    From you personally, I'd expect you'd explain how archives should change their filenames to comply with the guideline so they can continue to upload. I would deem an explanation like "no it's doesn't apply to NARA; but only Flickr" as not acceptable. Enhancing999 (talk) 17:05, 19 May 2024 (UTC)Reply
    I believe there should be more guidance than that on how to choose a good filename. I think it would be helpful for that note on Special:Upload to link to a broader guideline on how to name a file. Consigned (talk) 16:53, 19 May 2024 (UTC)Reply
Please note: If there are dire consequences for not following the guideline, I will change my vote against it. The worst that should happen for "offenders" (unless it's disruptive material) should be consistent nagging to pretty-please choose better naming schemes, and maybe getting placed on a watchlist. Disruptive material (like obscene/insulting filenames, or notably on-purpose bad names to create a mess, like uploading penises as "cute teddy bear") gets people banned for other reasons anyway. --Enyavar (talk) 21:08, 20 May 2024 (UTC)Reply
  Oppose including but not limited to
  1. "The name should not consist primarily of a broad location, such as File:Paris 319.jpg, Ontario hill, or Japan train station, where the location is so large that only someone who knows the area very well can identify the image."
  2. "For example, File:Michaeljackson.jpg should have included some information to distinguish itself from files in Category:Michael Jackson."
  3. "For place names, the basic name of the place, without a whole bunch of localizing addenda, is the best, e.g. "Denver" instead of "Denver, Colorado" or "City of Denver"."
  4.   Strong oppose "Refer to the Neutral point of view and No original research guidelines of Wikipedia."
  5. "Language preserving – Follow the conventions of the source(s) appropriate to the subject and avoid translation or romanization unless these are present in the source(s). If a subject has strong ties to a particular language, the name should use that language."
RZuo (talk) 05:52, 19 May 2024 (UTC)Reply
whoever came up with these ideas probably have never dealt with multiple writing scripts.
say i find a photo of Zelenskyy on the ukrainian govt website to upload. i have zero knowledge of cyrillic alphabet. how am i supposed to use ukrainian written in cyrillic? or a photo of a mountain in tibet on a tibetan blog. how many commons users can write tibetan?
how many users know the tibetan mountain well enough so that "The name should not consist primarily of a broad location"?
Commons:Village pump/Archive/2024/05#Tram construction users dont know about the place at all, so they should not upload?
this discussion has no merit at all because what led to this discussion is still not revealed for 2 months now. jokers want to exclude photographers' names from filenames? such absurd proposal if started on commons gets discarded straight. yet yall choose to be happily carried away by this absurdity that's hidden from users here. RZuo (talk) 12:48, 19 May 2024 (UTC)Reply
I think the important thing is that this guideline uses the word "should" rather than "must". How would new users know what to do in the scenarios you bring up today? We have no guidance for them, and some type of guide is better than a free-for-all. Consigned (talk) 12:54, 19 May 2024 (UTC)Reply
@RZuo Nowhere in the guideline it says you have to use Cyrillic for a Ukrainian file nor that you have to use a specific language for any file. Write in the language you are proficient in. Paradise Chronicle (talk) 13:11, 19 May 2024 (UTC)Reply
I think someone just threw out that point from the guideline. Enhancing999 (talk) 15:38, 19 May 2024 (UTC)Reply
Please note that the example with the broad location is an example from Commons:File renaming, which is a guideline already. This kind of nonspecific file names is even common in quality images that are supposed to have meaningful file names according to the rules. E.g., this is a major nuisance during quality image categorization, even more so if the description is exactly as meaningless and contains half a Wikipedia article of text about the city or the country, but nothing at all about what is actually shown on the photo. The rather common preference for this kind of essentially meaningless file names is one of the major reasons why I support even this very lengthy guideline. Renaming this kind of material would very likely enrage the authors because the new names would not match their naming conventions. Therefore, avoiding this by encouraging short but meaningful names would be great. However, a much shorter version of this guideline would be very much better, possibly with a link to the longer version for the extremely few people who wish to know more about the subject. --Robert Flogaus-Faust (talk) 22:27, 20 May 2024 (UTC)Reply
  • Here's the thing: I'm not quite sure what this does. It sets forth some best practices, but to what end? It doesn't say what should happen if a file doesn't satisfy these best practices, and that's probably a good thing because there's a lot of room for disagreement in the interpretation/application of these guidelines. It seems oriented towards getting the filename correct at the time of upload, but what happens when it's not correct? It doesn't address the issue that inspired it, which is about inclusion of the photographer name, but does open cans of worms by e.g. introducing the [English?] Wikipedia's NPOV policy. The relationship between this page and Commons:File renaming needs to be worked out as a fundamental element of how this page works in practice. In short, it's fine to say "please think about how to make your filenames precise" but when I think of making something a guideline I think of giving people a tool for enforcement. Absent clarity on what's to be done with this guideline, I'm inclined to   Oppose, with thanks to the proposer for putting work into a challenging project. — Rhododendrites talk |  21:55, 19 May 2024 (UTC)Reply
    • Guidelines aren't about enforcement. They're about telling people what constitutes normal good practice. - Jmabel ! talk 05:23, 20 May 2024 (UTC)Reply
      • Of course they are. Otherwise just have an "information page" or something. The whole point of having a big discussion to formally make something a guideline is to give it teeth. — Rhododendrites talk |  15:00, 20 May 2024 (UTC)Reply
        The guideline is to clarify existing practice regarding renaming, and to help uploaders create filenames that do not need to be renamed.
        As far as "teeth", I think the only thing this guideline really does is establish a standard for what filenames can be renamed to. So if a user is consistently renaming files to *worse* names according to this guideline, then there would be a strong argument to revoke their renaming privilege. Mathnerd314159 (talk) 17:43, 20 May 2024 (UTC)Reply
        But with renaming you have Commons:File renaming. Bidgee (talk) 19:38, 20 May 2024 (UTC)Reply
        How can you ask persistently uploading problematic filenames like "sdf.jpg" or "Jmse-10-01816-g001-550 hor.jpg" to choose beter filenames? And if they're willing to use proper names or are looking what proper filetitles would be, what page would give for guidance? I really don't get all this conservatism "if a policy on this doesn't exist since around the time of Wikimedia founding then let's make it near impossible for it to pass for no good reason". File renaming cited by Rhododendrites is only about moving files but this is about naming files at the time of uploading which is a separate subject and important for many reasons such as reducing workload and establishing good naming practices right from the get go (e.g. many problematic filetitles will never be changed). Prototyperspective (talk) 21:43, 20 May 2024 (UTC)Reply
        @Bidgee right, the current standard there is "A user repeatedly renaming files under invalid reasons can be stripped of the filemover privilege." If this guideline passes, there would be one more reason to consider a rename invalid (the filename is "worse"). In particular, for renames under reason 2, "change from a meaningless or ambiguous name to a name that describes what the image particularly displays", one would consider the various factors of the naming guideline and could conclude that the resulting name is not better. Currently, the renaming policy links the naming guideline, but it is not accepted as a guideline, so it cannot actually be cited as "common sense".
        Or something like that, I am not a wikilawyer. Personally I am done - I wrote the guideline, nobody has any more constructive feedback on it, it has been months. Y'all have fun. Mathnerd314159 (talk) 02:01, 21 May 2024 (UTC)Reply
Honestly I don't think the 15 different versions really helped. Especially since they were actively being changed while voting was going on, which at least IMO is a huge no no. You might try cutting it back and proposing something in a few months that just involves the basic points and makes it clear that it's only a guideline, not an enforceable guideline though. Since some people were/are still clearly confused about that aspect and it was never properly addressed. From what I've read so far I don't think anyone would necessarily reject a basic "guideline" about how to name files at the time of upload. There was some obvious things that could have been made clearer and done better from the get go about this particular proposal though. So it's not surprising that it didn't go anywhere. But again, that can probably be dealt with by simplifying it and not making the same mistakes next time around. --Adamant1 (talk) 03:36, 21 May 2024 (UTC)Reply
There were only two substantial versions, and I stated up front "I would revise the draft to accommodate any comments and then once the draft is in a good state I would overwrite the main Commons:File naming page and there would be a vote on whether to adopt it." The process has been going exactly as I envisioned it, save for the fact that people can't read and keep bringing up points that have been discussed to death. Mathnerd314159 (talk) 16:01, 21 May 2024 (UTC)Reply
From what I saw there was a vote on draft 1, draft 2, and then the "final proposal." That's to many iterations. It's just confusing and makes it hard to tell what exactly people have or are voting on. It's also rather tendentious to expect people to keep track of the various conversations, your edits, and repeatedly vote on the different proposals in the meanwhile. ou should have proposed and refined the draft in another venue and then done the final one here. Or conversely proposed the draft, gave it plenty of time for people to comment, and then edited it and created the final proposal after some time has passed. You can't just edit and propose 3 different versions of something in real time as the vote is happening though. There's no reason you couldn't have just proposed the draft to get feedback on it, made the changes, and proposed the final draft at some point in the future after you were sure all the kinks had been ironed out. --Adamant1 (talk) 23:03, 21 May 2024 (UTC)Reply

Usecase 2: COA edit

What's the impact for coats of arms? I see many replaced by files names "USA place COA.svg" like names. Is the general idea that people can continue uploading and we just have a guideline that suggests how they could do it better? Or just we terminate accounts and projects that don't follow it? Enhancing999 (talk) 08:35, 7 April 2024 (UTC)Reply

In my opinion editors should of course keep on uploading, but uploaders who in the past used bad/serialized filenames will now be able to get suggested that they should use more adequate filenames. In the past I was also reverted as I added some files into a bad filenames category.Paradise Chronicle (talk) 15:06, 7 April 2024 (UTC)Reply
The obvious impact would be that Commons:WikiProject Heraldry and vexillology#Naming of files would no longer say "There is no Commons standard for file naming", rather it could link to the guideline. (And I guess that would incorporate Wikivoyage's guidelines for place names by reference, which seem quite relevant here). And as you say, @Sarang seems to have made "LLL unitname COA" the recommended pattern - the "spelled-out" criterion would recommend expanding COA to "Coat of arms", and the concision criterion would recommend putting the place at the beginning. So I would say "Coat of Arms, Place, LLL" or "Place Coat of Arms (LLL)" are better naming schemes, more similar to the French and Italian styles. Mathnerd314159 (talk) 20:43, 7 April 2024 (UTC)Reply

Usecase 3: Several images in some photo contests edit

The proposal may be more suitable in the case of randomly-named image files that were submitted in some photo contests. Examples are the following image files that were submitted in the more-recent (like 2020s) editions of the Philippine leg of Wiki Loves photo contests, mostly organized by meta:PhilWiki Community:

The images themselves are good in terms of resolution and quality, but they have obscure file names. "File:Coastal lake.jpg" remains unidentified to the point that I cannot categorize it properly. For "File:Humbled by the Mountain.jpg", I resorted to asking the photographer off-wiki (on Messenger) just to determine the specific mountain for categorization purposes. Some file names do not exactly describe the images but only describe them in poetic or flowery sense, which I think should not be acceptable as hindering proper categorization and usability of files. JWilz12345 (Talk|Contrib's.) 02:22, 10 April 2024 (UTC)Reply

@Enhancing999 and @Paradise Chronicle, here is the third usecase. JWilz12345 (Talk|Contrib's.) 07:10, 11 April 2024 (UTC)Reply
If anyone wants another example check out the files in Category:Images misdescribed as postcards. In that case there's a bunch of normal photographs that someone decided to name as postcards for some reason when that's clearly not what they are images of. There's no legitimate reason files should be named that way to begin with though. --Adamant1 (talk) 07:18, 11 April 2024 (UTC)Reply
I'm not saying files shouldn't have descriptions, categories, annotations or structured data to describe the images. Quite to the contrary. The samples here lack much of it. Weirdly people may support the above proposal or complain about it, but don't bother adding or fixing them. Commons is also platform for collaboratively describing images.
File:A Blooming Flower.jpg as name avoids problems we on project chat with some species database. Photographers may not be biologists and should be able to upload images without consulting one before. When even specialists get the species wrong, other information (photographer, id, date, location) would be the more stable filename.
Interestingly, I don't think the guideline specifically addresses more abstract descriptions (such as "Humbled by the Mountain"). Enhancing999 (talk) 09:24, 11 April 2024 (UTC)Reply
Such a description is fine, actually it is encouraged by the "correct" guideline ("The title given to a work of art by the artist that created it is considered appropriate"). The only issue is that it is a photo of a place without enough specific or precise information to identify the location. So if it was "Humbled by the Mountain (Tenglawan)" it would be better. Mathnerd314159 (talk) 15:26, 11 April 2024 (UTC)Reply

continued discussion edit

  •   Comment I think the wall of text now requires a new write-up with a summary. If I counted correctly there are now 9 support vs 7 oppose (assuming Enhancing999 maintains the opposition; at least 3 of the oppose-votes were without rationale or clearly disproven explanation).
    I don't see why a reasonable baseline policy wouldn't be needed and useful. Would a structured arguments tree (Pro/Con format) help to visualize/provide an overview of the different points made and their respective objections? Re the clearly disproven rationale: file names don't need to be in English per this draft; I would however suggest that if EN is configured as language it could be made to show a specified or machine-translated English title even when the filename (default and url) is different. Currently file names like "flower.jpg" "sdf.jpg" or "Jmse-10-01816-g001-550 hor.jpg" are prevalent and it would be very useful to have descriptive titles when scrolling through a category page for example or searching for files. Much of this policy can already be inferred from the file-moving reasons, so having a policy just provides some guidance and reduces filemoving workload etc. --Prototyperspective (talk) 09:48, 16 May 2024 (UTC)Reply
    As for my count it would be 8 support + the proposer vs 6 opposes but I agree with you on the classification of the oppose votes. Paradise Chronicle (talk) 22:21, 16 May 2024 (UTC)Reply
    Some of the support votes don't really go beyond what we already have, so why do you try to assess some of the reasons, but not others? Enhancing999 (talk) 16:23, 19 May 2024 (UTC)Reply
    It appears that some of the participants who support this are neither active users of Commons nor have actually uploaded files. -- Enhancing999 (talk) 16:35, 19 May 2024 (UTC)Reply

Prohibit copyleft trolling edit

Latest comment: 12 days ago64 comments27 people in discussion

Although we have blocked accounts in the past for copyleft trolling, it seems we do not actually have a policy that prohibits it. Last year, Flickr updated their community guidelines to prohibit copyleft trolling: "Failure to allow a good faith reuser the opportunity to correct errors is against the intent of the license and not in line with the values of our community, and can result in your account being removed." Should we adopt something similar? If so, how should it be worded? Here is some background reading on the topic for those that are unfamiliar with it: [1][2][3][4]. Nosferattus (talk) 17:42, 1 April 2024 (UTC)Reply

I would simply add to the Commons:Assume good faith guideline that this guideline also applies to third party reusers. And I would require users who have a contract for automated copyright enforcement to disclose this. GPSLeo (talk) 18:07, 1 April 2024 (UTC)Reply
I prefer GPSLeo's approach. --SHB2000 (talk) 05:03, 2 April 2024 (UTC)Reply
I also prefer to implement the approach suggested by user "GPSLeo", it's the best approach. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:03, 2 April 2024 (UTC)Reply
Change the ToS so anyone who uploads a file after date XXXX must give an opportunity to cure. Glrx (talk) 18:13, 1 April 2024 (UTC)Reply
This seems unworkable, since you're essentially advocating for deprecating pre-4.0 CC licenses. We don't have the power to force Flickr or Youtube to do anything, so that would basically result in cutting ourselves off from several massive sources of free content (especially around newsworthy current events such as protests). With GFDL the loss of content was minimal (any new content was mostly people intentionally choosing the GFDL to make their work as unfree as possible), so the tradeoff was worth it, whereas there is still a lot of new content being released under pre-4.0 CC (such as on some websites that do not even have a 4.0 option). -- King of ♥ ♦ ♣ ♠ 19:25, 2 April 2024 (UTC)Reply
No. It would just add a condition for using WMF websites. If you upload a work here, then you must give violators an opportunity to cure a license violation. It offers a benefit to people who use files uploaded by the creator. If a user is sued, the she can point to the ToS and argue that she was not given the opportunity. It does not change or deprecate any CC license. It just makes it unattractive for a troll to upload more works here because he would have to give an opportunity to cure. (It is not perfect. If a third party uploads a CC 2.0 work, then the original author has not agreed to the WMF ToS. Consequently, a troll might encourage others to upload his works here to get around the ToS.) Glrx (talk) 20:11, 2 April 2024 (UTC)Reply
A troll doesn't even need to get others to upload their works here - they can import their Flickr photos themselves with a Wikimedia account that is not obviously tied to their Flickr account, and we have no way of proving they are the same person. And because we are trying to defend against users who are trying to game the system, this is precisely the kind of thing that we have to assume they'll do if given the opportunity. The only way to close this loophole is to ban pre-4.0 licenses. -- King of ♥ ♦ ♣ ♠ 17:37, 3 April 2024 (UTC)Reply
I will agree in part because legal battles are expensive. One would hope that discovery would show the uploader is an agent of the creator. Glrx (talk) 18:16, 3 April 2024 (UTC)Reply
That effectively bars us from importing CC licensed work from elsewhere if the license version is less than 4. The user here cannot make any promises, if not the copyright owner, and the copyright owner doesn't have to agree to the terms of service in that situation. It's basically a condition you are trying to add to the CC licenses, which you really can't do. And disclosing contracts may have the same problem, if they just post stuff to Flickr and let others import to Commons. It's not an easy problem -- some people may not realize a company they contracted with uses those tactics. The licenses really need to stand on their own, but would be good to do something. Disclosing the contract status, if a user here, could be a help. Do we have a category for uploads from users known to use (or contract to use) tactics like that? Carl Lindberg (talk) 22:49, 3 April 2024 (UTC)Reply
Why don't we just adopt language similar to Flickr's policy? Is there any reason that would be a bad idea? Nosferattus (talk) 23:24, 3 April 2024 (UTC)Reply
Reading over this that sounds like the proper approach. Although I wonder if its something we need to consult with the legal department about or get their premisson to adopt considering the nature of the thing. --Adamant1 (talk) 23:58, 3 April 2024 (UTC)Reply
I've come across this which shows how serious Flickr are about reversing the trend. The poster reported a photographer who'd made a Pixsy claim against him to Flickr. I presume they must have received other complaints about this person, but after a month or two, the photographer was banned from Flickr and all his photos removed.
[5]https://copyrightaid.co.uk/forum/viewtopic.php?p=12772#p12772 Normanlamont (talk) 12:12, 6 April 2024 (UTC)Reply
I'm glad that Flickr is taking this seriously. However, doesn't deleting images expose all its re-users to copyright claims, since the original CC licence disappears (assuming the image is not available elsewhere)? Julesvernex2 (talk) 12:33, 6 April 2024 (UTC)Reply

I've read about this case and... this is sad. Anyway, I hope everyone is aware that issuing a "always assume good faith from reusers" clause would render the licenses of this site into something like: 

Hey, you are allowed to use all these files with no attribution or share alike licensing whatsoever. Only in the unlikely event of the creator noticing your reuse, reaching to you and complaining, you might be required to include attribution or a similar license next to the photo.

I mean, there can be not only bad faith uploaders, but bad faith reusers too. Disclaimer: I have uploaded from Flickr a few images that turned to be created and distributed by (at least) one of these copyright trolls (this one). (And since then, every time I upload content from Flickr I fear the creator could be one of them). Strakhov (talk) 18:28, 4 April 2024 (UTC)Reply

Hi everyone! Currently, it seems that proposal #4 (the one I suggested) has several supporters, while the other ideas seem to have been of less interest yet. The discussion itself however has died down considerably, and I think that we could move forward with a cool head on this one.
While I am confident that "Copyleft trolling" is a good term for the phenomenon, my suggestion for the future help page is Commons:Copyleft lawsuit prevention, or Commons:Enforcement of open license terms (the one @Bluerasberry: suggested). Are there other suggestions? I think Commons:Policies and guidelines and Commons:Licensing are good locations where that help page may (eventually) be linked. But first, we have to draft what that page says, and the wording that @Jmabel: has suggested in proposal #3 is a good start, followed by more substantial advice for reusers who are getting law threats by Pixsy & Co. ; the notes of @Julesvernex2: are a good start there. --Enyavar (talk) 11:41, 11 May 2024 (UTC)Reply

Clarification of proposal edit

The proposal is not entirely clear. To clarify, I think the proposal should be:

Anyone who violates the licensing terms of any image on Commons should have a minimum 14 day grace period in which they can rectify licensing problems before charging the consumer with licensing fees or commencing legal action.

I agree with Bidgee that it isn’t clear what change is being requested.

Furthermore, we need some on-wiki way of showing when they were advised of the problems. Currently, as an example, Diliff is keeping all correspondence off-wiki and appears to employing a third party company to go after license violators. Enforcing licensing terms is not a problem, but the manner in which it is done very much does matter. - Chris.sherlock2 (talk) 04:13, 6 April 2024 (UTC)Reply

I think that wording is too specific and would lead to further arguments (e.g. "14 days from when?"). Also, it's not legal actions that are the problem, as copyleft trolls rarely actually take any legal action. It's terminating the license and using that to make legal threats that is the problem. I would prefer that we just state what we expect in broad terms. Nosferattus (talk) 07:51, 6 April 2024 (UTC)Reply
Doesn't CC-4.0 already have a 30-day grace period? I would oppose any policy that overrides this but support the general principle of the policy. --SHB2000 (talk) 07:26, 6 April 2024 (UTC)Reply
There is very little Commons can meaningfully do to enforce this, unless it is willing to allow contributors unwilling to accept the policy change to delete their uploaded media and leave. The CC version 2 and 3 licences say what they say, and contributions were made on the basis of what the licences say. Unless I've missed something, there's nothing in the old licences that allows Commons to retrospectively change those terms. Kahastok talk 17:27, 6 April 2024 (UTC)Reply

Proposal #2 edit

I propose that we add the following wording to the end of Commons:Assume good faith#Good faith and copyright: "It should also be assumed that third party reusers are acting in good faith. Failure to allow reusers the opportunity to correct errors in licensing or attribution before terminating a license can result in your upload privileges being revoked or your account being blocked." Nosferattus (talk) 07:54, 6 April 2024 (UTC)Reply

  •   Oppose The latter is excessive for simply wanting to have your photos attributed properly. SHB2000 (talk) 07:57, 6 April 2024 (UTC)Reply
    This is about sending a bill about many hundred euros to the operator of a small blog or a small non profit organisation. AGF does of course not apply when the file is used by Reuters, Adobe Stock or in a commercial video of Google or Amazon. GPSLeo (talk) 12:40, 6 April 2024 (UTC)Reply
    @SHB2000: I'm not sure I understand your oppose. How would this interfere with getting your photos attributed properly? You are still welcome to sue them or send threatening letters or whatever you want to do if they do not correct the attribution. Nosferattus (talk) 16:46, 6 April 2024 (UTC)Reply
  • OK, so your person who enforced the letter (rather than the spirit) of the old licences got blocked. Well, in cases like the recent one, they're not uploading anyway so why do they care? And if they're blocked, that also prevents them from engaging with the community and hearing the community's concerns and the community's responses to any questions they might have. Kahastok talk 17:34, 6 April 2024 (UTC)Reply

Proposal #3 edit

A different possible wording (this is just a draft):

A similar assumption of good faith should be extended to third-party reusers of content, especially reusers who cannot reasonably be presumed to be expert in copyright and licensing matters. It is important that people whose materials are hosted on Commons comply with the spirit, and not just the letter, of free-licensing. In particular, if an online use of an image by an individual or small organization does not give a proper credit, the individual or small organization should be given a reasonable opportunity to "cure" the problem before any demand for payment on threat of legal action. (CC-BY 4.0 and CC-BY-SA 4.0 overtly require a 30-day grace period for this purpose; for differently-licensed images, Commons participants should certainly allow at least a 14-day grace period.) Not to do so constitutes "copyleft trolling."
There is generally no way to "cure" a use in print (as against online) or film/video (unless online), but still any demand for payment should not grossly exceed what might reasonably have been paid for use of the photo under normal commercial licensing.
We welcome our community members to extend such an assumption of good faith even to reusers who can reasonably be presumed to be expert in copyright and licensing matters, but that is not required. Stock photo companies (Alamy, Getty, etc.), media organizations (major newspapers, television and radio stations, etc.), large businesses (really anything past the "mom and pop" level), government agencies for anything other than small localities, major NGOs and international organizations (the UN and its component organizations; major non-profits such as Médecins Sans Frontières or the National Rifle Association, etc.) and companies large enough that they certainly engage with such issues on a routine basis can reasonably be expected to understand copyright and licensing. While we generally encourage that a similar assumption of good faith be extended here, it is not a requirement.
It is also not required to extend such an assumption of good faith to individuals or organizations that are demonstrably repeat offenders.
Commons users who make egregious legal threats or excessive demands of payment from reusers are subject to disciplinary action, up to and including being banned from Commons. Commons reserves the right to delete their work from our site or to retain that work and add warning notices of our choosing addressed to potential reusers, and/or to topic-ban these users from uploading and to blacklist their photos from being uploaded by others.

Jmabel ! talk 18:21, 6 April 2024 (UTC)Reply

Proposal 4 edit

Hey, sorry for only proposing this on the VP main page so far: I don't think we should make big fundamental changes that will disturb everyone. Instead:

  1. We first need a help page (landing page) that explains the concept of "copyleft trolling" to unsuspecting users (who will most likely only find it after getting stung, but better than no landing page at all) and where people can also go to alert the community about those who do use trolling tactics.
  2. Those specific users we then need to convince of switching to CC4 (they may continue using those firms, but with the 30 days grace period observed, I don't see dramatic moral/ethical issues).
  3. Those authors/users who we cannot convince of switching and who still file lawsuits, should in my opinion accept forced watermarks (not destructive ones, but like like here in the most extreme cases), so that reusers are given proper warning.

Only the final point would require a policy change, in that we as a community need to agree to make forced watermarks a regular policy - but only in established cases of copyleft trolling. --Enyavar (talk) 18:34, 6 April 2024 (UTC)Reply

  •   Support This sounds good. But the transfer from 2.0 and 3.0 to 4.0 is a big work. It will take time. Yann (talk) 18:42, 6 April 2024 (UTC)Reply
  •   Support This I can agree with. --SHB2000 (talk) 21:06, 6 April 2024 (UTC)Reply
  •   Support an excellent idea! - Chris.sherlock2 (talk) 22:14, 6 April 2024 (UTC)Reply
  •   Support Seems like a good start. Nosferattus (talk) 16:18, 9 April 2024 (UTC)Reply
  •   Neutral This proposal might be based on a misinterpretation of the CC BY 4.0 licenses. I checked the license for CC BY 4.0 which I use for my photos. It appears to say in section 6b that the license is reinstated if a copyright violation is cured within 30 days after the person violating the license discovers this (or if the licensor expressly reinstates the license). However, please look at the last sentence of section 6b: "For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License." IMO this could mean that you might still be sued or billed for the copyvio right away, at least before you actually correct the credit line. So you might need to add the watermarks even with CC BY 4.0 licenses. --Robert Flogaus-Faust (talk) 20:24, 9 April 2024 (UTC)Reply
    Nil Einne has raised similar concerns on another thread [6], we're trying to get feedback from Creative Commons and Cory Doctorow on this. Julesvernex2 (talk) 09:23, 10 April 2024 (UTC)Reply
  •   Oppose for 1, there are "copyleft trolling" but then you have those who rightfully seek damages for the violation of the CC license. You need to take care when drafting the landing page.
for 2, no way should it be 30 days, at a minimum 14 days is more than enough time for the violator to cure the violation.
for 3, what if the legal action/lawsuit was warranted, as the violator ignored all attempts to "cure"? Do we mark those too? Bidgee (talk) 01:31, 10 April 2024 (UTC)Reply
1) What is your idea of "rightfully" seeking monetary damage from re-users of a for-free-licensed image? If you can define how those hypothetical people are not copyleft trolls, we can work that definition into the proposed help page and say they are exempted from steps 2+3.
2) the duration is prescribed by the CC 4.0 license - I personally find it rather short, but I'm not complaining.
3) No, @Bidgee: If a creator switches to CC 4.0 license, I don't see problems with their content. If that creator still notifies people about their violations, gives them their due grace period, then processes them for their violations after they haven't taken the warranted action? Good for those creators, what else can I say? --13:52, 13 April 2024 (UTC) Enyavar (talk) 13:52, 13 April 2024 (UTC)Reply
That Medium article you link in 1) seems to be about people pursuing large damages and paying to send legal threats to small bloggers who attribute a CC image but miss some formality or even doing it correctly.
That's a pretty big jump from "collecting from companies that should know better just taking images off the internet with no attempt to credit the creator", which from my understanding of the proposal would still be prohibited without allowing a 30-day grace period. AlexandraAVX (talk) 07:28, 7 May 2024 (UTC)Reply
The trolling legal firms are pursuing large damages without regards to the size of the "offending party": they threaten bloggers, charitable organizations, and companies all alike (except that big business usually pays for professional stock images in the first place); and the troll business model apparently pays itself. / The 30 days grace period is a feature of CC 4.0, and has little to do with the proposal. My proposal was just an idea how to bring as many creators as possible to update their licences. Other CC-license platforms like Flickr (to my understanding) are much more proactive in banning users who engage in copyleft trolling. For Commons this is hopefully the start of dealing with the problem. --Enyavar (talk) 13:13, 7 May 2024 (UTC)Reply

Proposal 5 edit

  1. Make a landing page Commons:Enforcement of open license terms
  2. Be informational, define relevant concepts, link to articles
  3. Have no rules or guidance at this time
  4. Develop rules on the talk page there

There are already lots of subproposals here and I do not think we will untangle much without longer discussion. For some things Wikimedia Commons should ping the Creative Commons community and other stakeholders, perhaps Flickr, to be in sync and aware of each other. Other issues may need legal clarification. This seems like a potential months-long project. These other proposals should proceed, and I see the Wikimedia Commons community as the best place to develop these ideas, but this is discussion is too big for this board. Bluerasberry (talk) 00:32, 7 April 2024 (UTC)Reply

I think you overestimate the ability of the Common community to have productive long-term discussions about thorny topics. Notice, for example, that Commons has no policies on harassment, legal threats, personal attacks, civility, dispute resolution, child protection, or many of the other policies that most Wikipedias take for granted (and it's not for lack of trying). If nothing comes out of the current flurry of interest, I doubt any productive reforms will be made regarding copyleft trolling (at least until the next major incident). Nosferattus (talk) 18:11, 7 April 2024 (UTC)Reply
@Nosferattus: In most of these things you list, we inherit policies from the WMF rather than having specific policies of our own. - Jmabel ! talk 20:43, 7 April 2024 (UTC)Reply
I also think that we should go forward incrementally here, just like Bluerasberry suggests. So first, implementing the landing page idea, and discussing further action from there. --Enyavar (talk) 12:00, 11 May 2024 (UTC)Reply

User viewpoint edit

As the user whose reporting of a photographer's activity using Pixsy started this whole discussion, I've been encouraged by another user to add my views. I'm not a photographer or a Wikipedia administrator, I'm writing just as an ordinary user. I want to address:

· the small time 'offender's' viewpoint

· Pixsy's modus operandi

· the photographer's viewpoint

· the proposals so far

All the cases I reported involved charities or very small-bloggers. Other contributors mentioned others. When Pixsy claims damages it's very threatening and quite a shock. I'm not asking for pity here, bear with me. The way the demand is worded asserts clearly that ignorance of copyright, carelessness and a willingness to correct the attribution will have no effect on the demand. You MUST pay a large amount of money, and quickly, or you will have legal action taken against you which could result in you paying a much larger amount in legal expenses. So in each case we're talking about someone who is shocked and scared. In many of the cases quoted the offender tried to contact the photographer to see if something was negotiable, to no avail. Not everyone did. At least one was so afraid they closed down their website and business completely. In my case I didn't try because Pixsy said they represented the photographer and communication should only be through them.

(I'm using Pixsy as an example here because they were involved in these cases - as you know there are many organisations working in this field.)

In my case, and I'm sure in the other cases I reported, had I been simply been reminded 'you didn't attribute that photo correctly (and if you don't then ...)' I would have immediately corrected it. I wouldn't need a 30-day grace period.

I'm well aware that during the discussions that followed my report, there's been scant sympathy for Pixsy and similar businesses, even from supporters of the photographer, however I still feel I should reiterate the user's point of view.

In this case the photographer expressed some regret that small users were 'caught up' in what he sees as a legitimate process. Looking at Pixsy's Trustpilot page shows many photographers praising them for recovering thousands of pounds from illegitimate commercial use of their images. It seems that in many cases they're actually providing a valuable service to photographers. However, when it comes to images that are licenced under CC we can see that: a) Pixsy does not distinguish between careless use of CC and abusers who, for example, re-sell photos, change metadata, use them in advertising campaigns etc. Indeed in my experience, Pixsy automatically categorises websites as 'commercial' and CC use as breach of licence. (I know that technically it is, but that is an expedient according to Cory Doctorrow.) b) Pixsy offers little justification for the amount they charge. Their justifications change over time and are never verifiable. c) Pixsy offers no suggestion that this can be resolved in any way other than paying what they demand. There's no question of negotiation or of approaching the photographer. d) their legal arguments are not valid (too much to go into here but at least under UK law, and the UK court, their claims are simply incorrect)

From the photographer's point of view, there's obvious benefit; an arm's length relationship keeps it simple, and removes the need to spend valuable time looking into individual cases. I think, however, this gives them a skewed idea of how the claim process goes. The photographer Diliff for example suggests that because what he is eventually paid is in some cases less than the original claim, then some mitigation has been accepted and some negotiation has taken place. In all the cases I know of, this is not so. Many site owners will just pay up immediately out of fear and shock, with no challenge or negotiation. Others may attempt to negotiate, but this may never reach the photographer. (For example I offered to go the the UK mediation service instead of a full court case. Pixsy refused to even comment on this, so I have to assume the photographer was never told.) Finally Pixsy will offer a reduction or 'discount' after several months if the user shows they are going to argue. This is not presented as a concession by the photographer, in fact they say they are not authorised to negotiate but to speed things along they can offer a discount. So the photographer should be under no illusion that Pixsy are dealing with small users and CC claims in any 'softer' way than commercial abusers.

Also from the photographer's view, we are told they should be able to claim retrospective damage for the time the photo was used, and should be able to claim for the work involved in bringing the claim in the first place. This may work in the US, but UK courts will only look to reinstate the photographer to the position they would have been in had it been correctly attributed; and legal costs other than very small expenses such as travel are not reclaimable. As others have stated it's a false dichotomy to say the alternative to an unattributed photo is a paid licence - it's an attributed photo or a different photo altogether.

It's been suggested here and there on the web that claims for CC misattribution rarely reach court. I don't know if it's true, but even if it is, many people will have paid these companies immediately out of fear, so it's no consolation.

I was surprised how much discussion my report produced and the depth and care taken around the proposals for remedying the situation.

I won't comment on the proposals to delete this particular photographer's contributions or put other sanctions on him. Flickr have adopted a harder stance and at least one photographer has been completely removed because of Pixsy activity. But that's different governance, different situation. This is a matter for Wikipedia and the discussion here has been thorough.

Proposal 4 includes a landing page that explains the risk of misattribution. In my case that would have caused me to take better care of attribution. My failure to attribute was due to nothing but haste and carelessness; I normally attribute everything including libraries like Pexels. So it would have worked for me and, I imagine, most of the cases I reported.

The grace period - as I said in my case a 5-day grace period would have worked - it was an 'oops!' moment, but the CC4 30-day period, or the reduced 14-day period suggested are all perfectly good to me. However it requires photographers who use services like Pixsy to authorise them to issue a takedown notice before bringing out the heavy guns. They do have that choice, at least with Pixsy. Diliff for one argued against that, but I think his arguments don't stand up for the majority of cases, they were only about photos being used in a short term ad campaign. Clearly this is something between the photographer and their copyright chasing agency and WM have no power to force them to do anything; but an education programme for contributing photographers about the reasons for using CC4, bringing in the arguments of Cory Doctorrow and the change of policy at Flickr might help. Many photographers will, like Flickr, not want to be associated with the hounding of CC violators as collateral damage for photographers seeking redress for serious commercial theft.

With respect, I hope this isn't too much but keeps the discussion open and hopefully helps you towards a decision. — Preceding unsigned comment added by Normanlamont (talk • contribs) 11:28, 24 April 2024 (UTC)Reply

The problem is that you don't attribute photographers at all (you mentioned earlier). It's not a question of a mere detail that went wrong. (Did you also get claims for Getty Images? How did that work out?) Enhancing999 (talk) 12:04, 24 April 2024 (UTC)Reply
I normally attribute. That day I neglected one. If it had been drawn to my attention I would have corrected the error immediately. Normanlamont (talk) 12:18, 24 April 2024 (UTC)Reply
Enhancing999 Why do you mention Getty Images? I didn't. Normanlamont (talk) 10:51, 2 May 2024 (UTC)Reply

Feedback from Creative Commons edit

Yesterday I had the chance to speak with Creative Commons about copyleft trolling. I’ve summarised my understanding of their feedback below, a warm thank you to Kat Walsh, Anna Tumadóttir, and Cory Doctorow for their time!

  • The 30-day grace period in CC4 does indeed only apply to reinstating the licence, meaning that users are still liable for damages before the attribution was corrected or the image taken down. However, experience suggests that this makes the business model significantly less interesting for companies such as Pixsy, as most courts will hesitate to award material damages for temporary infringements. As long as there are CC2/CC3 licences out there, Pixsy has bigger fish to fry;
  • Upgrading to CC4 can only be made by adding the licence on top of existing CC2/CC3 licences. Existing attributions, if the user does not update the attribution to CC4, continue to be governed by the old licence. Existing misattributions also continue to be governed by the old licence, but Pixsy would have a harder time convincing a court to award damages. Again, bigger fish to fry;
  • In theory, deleting images of copyleft trolls does not impact existing attributions, as the licences are irrevocable. However, this business models hinges on fear mongering and information asymmetry, so anything that makes it harder for users to prove they were using the images correctly can help copyleft trolls. One possible solution is to leave the image page online, but only with a small resolution preview of the image;
  • Regarding Proposal 4, which currently gathers the widest consensus:
  • A landing page needs to fall short of providing legal advice but can nevertheless be very useful if it includes statements such as “Pixsy is less likely to pursue a case if you do X and Y” and “in scenarios Z and W, the likelihood that Pixsy takes you to court is small”;
  • Upgrading CC2/CC3 to CC4 may be the single most effective action to address copyleft trolling;
  • Forced watermarks run the risk of rewarding trolls with extra publicity and weakening the position of other photographers that do not have watermarks. Deleting images has proven to be more effective, although at the cost of potentially losing valuable content.

Pinging some of the users that raised these questions: @Nil Einne: , @Rhododendrites: , @Enyavar: , @Robert Flogaus-Faust: , @Normanlamont: --Julesvernex2 (talk) 20:25, 24 April 2024 (UTC)Reply

Thanks a lot from me, this seems indeed helpful. I fully agree that the landing page should not give legal advice - in fact, I only expected it to explain the concept of copyleft trolling, and urging (our uploaders) to change to CC4 and linking (the re-users who get threatened) to the page where they can report uploaders that have sued them. But helpful statements on how to withstand Pixsy's legal threats are also a good idea.
Upgrading the licenses is obviously the best way to proceed; but the "bad apples" (I mean those who already engage in copyleft trolling) are unlikely to do so. Four years after the CC-inventor published his article on the supposed Commons-troll from Serbia, the image of his mouse is still up under CC2 and actively used in WP articles.
We are completely lacking the teeth to do on Commons, where Flickr has it a policy to even ban users who upload in bad faith: There are no community rules that are in support of deleting images just because they are used for copyleft trolling. From experience, I don't think we can implement such drastic rules anytime soon: Just notice how many users seemed to support the idea that Diliff did not even do anything wrong - after all it was totally legal and backed by the Commons Rules, so why should anyone outlaw the legal rights of poor Diliff? Also speaking against deletion is that this robs current legal re-users of their proof that they downloaded it from Commons under that free license that they are displaying. The alternatives to deletion are, as I see it: giving copyleft trolls free reign on Commons (status quo, not preferable), or forcibly altering the images in some way. You report that we could only keep thumbnails (the CC lawyers suggestion); the other idea is watermarking the images (still my favorite). I also don't want to encourage watermarking, but if the watermark includes "do not remove this license text, or User:XYZ is likely to sue you", this should not advertise the practice (both of watermarking and of copyleft trolling) to most users, and seem more like punishment. --Enyavar (talk) 21:30, 24 April 2024 (UTC)Reply


Thank you for this, and for getting the discussion moving again. I’d like to ask a few questions.
Re the proposed landing page - when would this be shown? Is it when someone clicks on an image?
The proposer of Proposal 4 links to an image by the photographer Philpot as an example of watermarking. I assume some sort of similar discussion must have taken place regarding him and Marco Verch, who have more clearly and explicitly embraced the practice we’ve called copyleft trolling. I was surprised they are still allowed to do this and have pictures in WM but there must have been reasons. Can anyone point me to the previous discussions?
Finally I don’t know how these WM discussions work - how many people have to vote for one of these proposals to be enacted? Is there a closing date when a decision gets made, or are these discussions advisory to some committee who makes the decision and starts action? Normanlamont (talk) 16:29, 25 April 2024 (UTC)Reply
  • @Julesvernex2: "Pixy has bigger fish to fry". This completely misses the point. Pixsy doesn't care about enforcing copyrights. They are an extortion scam. They don't actually take people to court, they just harass and intimidate you until you pay them something. They don't actually monitor the infringements, they don't care what actions you take, they just send you various form letters with escalating threats and offers and then apparently keep 50% of the money. It's up to the photographer and photographer's lawyer to initiate any actual legal action (which they almost never do unless its a significant commercial use). Honestly, I don't think forcing people to use CC 4.0 licenses will do much of anything, but since this is the only proposal that has support, I'm supporting it. Right now one of Diliff photographs is on the main page of English Wikipedia because we haven't taken any action. This will probably cause hundreds of additional good faith reusers to get harassed by Pixsy and generate of nice bit of profit for both Pixsy and Diliff, at the expense of the entire free culture movement. We are getting completely exploited and it's sad that so many people are supporting this behavior. I hope we can work together to get this successfully addressed in some form or another. Nosferattus (talk) 17:17, 26 April 2024 (UTC)Reply
    "Pixsy doesn't care about enforcing copyrights. They are an extortion scam. They don't actually take people to court, they just harass and intimidate you until you pay them something." hyperbole. Most of law is actually about settling out of court, all with the mutual threats of actually going to court. We might not like it, but let's not pretend that this isn't normal. Maybe people are too young these days to remember w:Napster, but this is just how the legal system works in most place around the world. —TheDJ (talk • contribs) 17:35, 26 April 2024 (UTC)Reply
    I don't think it misses anything. All of the copyleft trolling cases I've read about involved CC2/CC3 licences, and even Pixsy seems to have gotten their facts about CC4 wrong ("However, users of images with a Creative Commons license release type 4.0 (or above) are granted a 30-day grace period in which they can resolve breaches of license terms, before it is considered copyright infringement.", [7]). Switching the analogy from culinary to burglary, no lock is unpickable but can nevertheless be effective if it takes too much effort to break in. I do agree though that continuing to promote these images in Wikipedia is perverse. Julesvernex2 (talk) 17:55, 26 April 2024 (UTC)Reply
    If the license difference matters to Pixsy, then yes, you are correct and I apologize. Nosferattus (talk) 18:01, 26 April 2024 (UTC)Reply
    No need! Julesvernex2 (talk) 18:20, 26 April 2024 (UTC)Reply
  • "Forced watermarks run the risk of rewarding trolls with extra publicity and weakening the position of other photographers that do not have watermarks. Deleting images has proven to be more effective, although at the cost of potentially losing valuable content." Forced watermarks largely prevent the images from being used on Wikipedia, which is how 99% of reusers discover them. So I think it is largely effective at reducing copyleft trolling. I too would prefer deletion, but it seems that the Commons community does not support this. Nosferattus (talk) 00:23, 2 May 2024 (UTC)Reply

Introduction of a new role edit

Latest comment: 24 days ago14 comments9 people in discussion

(This proposal is an improved version of this proposal where the issues suggested by users are addressed)

In this proposal, instead of bifurcating the role of sysop, I suggest introducing a new role known as "deletion administrators" where this group of users would be able to delete and undelete media (along with roles like renaming files, sending a message to multiple users at once, deleting and undeleting specific log entries and revisions of pages, merging the history of pages, and using higher limits in API queries). This proposal addresses two key problems highlighted by users in the previous proposal; first, the concern over the "presence of a common administrator," as blocking users and performing deletions naturally coincide when dealing with abuse. With deletion administrators, administrators would still be available to address vandalism promptly. Second, the issue of "productivity" is mitigated as users who are less familiar with tasks such as blocking and unblocking users, or adding user groups, can focus on resolving the COM:DR backlog.

In the prior proposal, Rodhullandemu noted that "Admins are expected to be conversant with all policies, but most will take on work most suitable to their interests and talents. So there's no need to have separation because we already have it on an informal basis." While this observation recognizes that admins naturally gravitate toward tasks they excel at, it also highlights the potential for backlog accumulation. This "informal basis" separation, therefore, does not sufficiently address Commons' operational needs. By formalizing the role of deletion administrators, we establish a clearer division of labor and ensure that tasks are handled efficiently, ultimately reducing backlog and enhancing overall effectiveness.

The criteria for this role would mirror those of interface administrators, with the distinction that administrators can assume the role of deletion administrator, or it would be oppposing the whole point of the proposal. Thanks, Contributers2020Talk to me here! 09:09, 17 April 2024 (UTC)Reply

The role of an Admin light with the permission to delete or undelete files is not possible because of the reasons already discussed in the past. But I also had the idea of a new user right with the possibility to delete and undelete galleries and categories as this often not critical and does not cause copyright problems. GPSLeo (talk) 12:10, 17 April 2024 (UTC)Reply
If you feel fit for handeling deletions and plan to focus mainly on that, I think you should apply for adminship even if you don't want to to more. I doubt the rest would make much of a difference for support/oppose.
Interface adminship is generally considered more risky. Enhancing999 (talk) 15:06, 17 April 2024 (UTC)Reply
Would it really be acceptable to the community if admin candidates run solely on the basis of deletions, and pinky-swear that they won't be involved in blocking and other abuse-prevention activities that require such privilege? I'm not informed on the impossibility of this proposal as @GPSLeo hasn't linked to the prior discussions.
I don't have enough visibility into the admins' cabal to see how they coordinate stuff, but it seems rather anarchic in terms of volunteering in specific interest areas, so there is no managed distribution of duties or labor. Small wikis as well as Commons really suffer from a lack of volunteers overall, and it would seem that the bar for entry to adminship is a huge hurdle for people who wish only to specialise, so we do have clerks, non-admin closures, and other unprivileged gnomes who pick up the slack.
In Unix, the sudo and doas interfaces, and fine-grained IAM roles in cloud services such as AWS, permit a granular division of permissions, because in the Bad Old Days they just handed over the root password/Administrator account to any salesman who needed to install software. Commons has a unique status among all the Wikimedia projects, and we often find that the MediaWiki software structure is inadequate to support our specialised operations. So the issues are both technical and social. I'm saddened that this proposal is not possible to implement as described. Elizium23 (talk) 15:56, 17 April 2024 (UTC)Reply
Deletions on Commons can have a fairly high impact, so this shouldn't be done lightly or as an experiment. Enhancing999 (talk) 16:01, 17 April 2024 (UTC)Reply
Enhancing999, I'd like to emphasize that in addition to proficiency in copyright matters, candidates applying for adminship undergo evaluation of their ability to effectively handle vandalism, discerning what qualifies as such and what doesn't. Adminship entails a significant qualification hurdle, and therefore reducing the number of people that can qualify for this priviledge. Given the immense backlog of deletion requests we're currently facing, it's imperative that we address this issue promptly to prevent reaching a critical threshold. I firmly believe that the proposal at hand represents our best opportunity to do so. The current workload on administrators exceeds expectations, underscoring the pressure they're under. Also, I am not suggesting that this role would be given to anybody, but the people who are deemed qualified by the community to handle the deletion part. Contributers2020Talk to me here! 16:13, 17 April 2024 (UTC)Reply
I think anybody who understands deletion requests knows what vandalism is. Enhancing999 (talk) 16:15, 17 April 2024 (UTC)Reply
Deletion issues are quite distinct from vandalism itself, which is a narrowly-defined subset of disruption. Enwiki has extensive documentation on this particular topic. We on Commons, being separate and unique from other projects, interpret "vandalism" and "disruption" with yet different nuances. Administrators deal with disruption enough to know, from experience, what type they're seeing, usually, but not always. It's perilous for a non-administrator to unilaterally declare disruption or vandalism, without training, experience or insight; accusations are flung around quite often at the boards.
Deletions and deletion reviews, like LTA and complex disruption cases, require community input and consensus, and that's a parallel issue: not only is there a lack of admins to push the mop around, but a lack of knowledgeable participants in deletion discussions to efficiently arrive at a decisive consensus. Admins participate so much in those discussions, that perhaps they should not waste their time until non-admin volunteers have weighed in and reached a decision!
Perhaps a unique role such as Copyright Czar would be appropriate here: drawn from the ranks of admins and others who are experienced with copyright issues, disruptions, and deletions, they could provide a continuum of expertise and labor. But as before, the bigger picture is an overall lack of volunteers and a lack of community interest/participation/person-hours for these tasks. So many Commons editors are really only interested in contributing or organizing content, because that's our mission, the project has a vanishingly small slice of the admin labor pie. Elizium23 (talk) 19:12, 17 April 2024 (UTC)Reply
I think you and me we both came across nil vandalism in the last six months. Likely because it's not much of an issue on Commons.
It's new to me that we seek consensus in deletion discussions. Are you sure that you didn't want to post on enwiki? Enhancing999 (talk) 19:18, 17 April 2024 (UTC)Reply
I don't think that this is a good idea, for a couple of reasons:
  • Deletion on Commons is the "hardest" admin-only task, in my opinion. It requires thorough knowledge of Commons policy, and of international and US copyright law. It's not rocket science, but it isn't a task that should be given to people we don't trust enough to make full administrators.
  • Relatedly: which people should have this role, but shouldn't be full administrators? (This is rhetorical: I'm not looking for names. But I can't think of a contributor who can be trusted with the deletion button but not the block button.)
  • Deleting and blocking often come together. Not always, but often enough that it's useful to have both tools in the toolbox.
  • I'm confused about your comment about productivity. Admins who don't want to block or add user groups, but do want to delete, are totally free do so.
Best, —‍Mdaniels5757 (talk • contribs) 19:35, 17 April 2024 (UTC)Reply
Yeah, as Mdaniels says, deletion is not a tool that we would want to give access to that we wouldn't trust with the other admin tools. I can think of at least one user that I'd trust more with the deletion tool than with the ability to block but that would be an edge case (No, I'm not naming names). Basically, there is no guideline that says an administrator has to use all of the tools available to them. I hardly ever use the tool to block (I've only used it once to prevent vandalism by an IP user). I can also agree that having both deletion and blocking can be very useful as deletion can be used for revision deletion (to deal with spam or inflammatory comments or the inappropriate disclosure of personal info). Abzeronow (talk) 03:37, 19 April 2024 (UTC)Reply
  Oppose I would support a category-namespace specific right as proposed above by GPSLeo, because that's a highly specialized area that's also badly backlogged, but at the same time, anyone that we'd trust to handle it would probably make a perfectly fine admin. The bar on this project is very low, at least compared to enWiki. The Squirrel Conspiracy (talk) 05:30, 19 April 2024 (UTC)Reply
  Oppose Per others. Although I'd support GPSLeo's idea. I can think of at least a few people who could probably have a category-namespace specific right but aren't quite admin material for whatever reason. It could also be a good hedge in to having more administrator rights. --Adamant1 (talk) 05:46, 19 April 2024 (UTC)Reply

Adapt DR notices edit

Latest comment: 22 days ago2 comments1 person in discussion

Dear community, I would like to share with you a way that really worked for me to only upload works in the PD. What made me learn most is that I received a few notices like this where it says that commons takes copyright violation seriously and could lead to a block. Now in this notice there is no mention of the seriousness of copyright issues or a block, nor in this one. Maybe there are other DR notices that I do not yet know and which could also be adapted in a way to prevent non-free uploads.

I suggest to adapt all eventualities of DR notices in a way that they include a phrase in which the seriousness of copyright violations and a possibility of a block are mentioned. Paradise Chronicle (talk) 21:42, 24 April 2024 (UTC)Reply

Another point that could be added to the DR notices is: that it is normal for new and sometimes also experienced editors not to know all the rules and that they should not worry for some undeleted files of theirs. Paradise Chronicle (talk) 09:13, 2 May 2024 (UTC)Reply

Reform VRT process! edit

Latest comment: 7 days ago15 comments10 people in discussion

Dear community,

I believe that the VRT verification system is awful and a major headache to all of us contributors. Major issues can be listed as:

  • Its extremely hard to get some (in my case, most) people (especially if there is distance, lack of technological understanding and language barrier) sent permission statements directly.
  • VRT permission text is scary. Some old people genuinely feel like "I am grifting them/trying to get them in some mafia style trouble" or that "they will allow selling their body like prostitutes" (I am not joking, that's a real quote I got from and old fellow) while they generate VRT request text and read the legal yada yada of it because CC-BY SA license clauses are explained in a scary way (and those fellows don't have any issues with clauses of those licenses when they are explained in a basic, non-legal-court-style-scary way).
  • It makes all of us lose our valuable time that we could be spending for something better, and outcome is not satisfying most of the time even when positive because we go through all the hustle of convincing technologically-illiterate old people to make scary legal consent on a piece of photo/vector recreation that in reality no one gives a single fly about.

End of ranting. So what is my solution(s)?

  • Allow third party/email forwarding verifications. It will save lots, lots of time and make both parties' job much, much easier. We contributors that spent most of their free time to help Wikimedia aren't grifters. Just try not being paranoiac and assume good faith from a regular contributor.
  • For VRT: Try using common sense time to time. The 60ish years old aunt won't give a fly about her father's black and white photo in the office from 70s having a free license. If she told me "Yeah, sure" that should be more than enough consent for an individual like her.

VectorVoyager (talk) 21:20, 1 May 2024 (UTC)Reply

How exactly would the third party/email forwarding verification work? Like should we just take any random users word that they got permission or eould they be required to send the VRT team copies of the emails? (I could maybe see that work with a email template that the person would have to sign or something, but I don't see how a random user emailing someone a vague question about it and them replying with something like "sure, whatever kid. Just stop bothering me." would ever hold up in court). --Adamant1 (talk) 21:42, 1 May 2024 (UTC)Reply
I think we accept forwarded mails if they have a signed document attached. For the problem you describe a possibility to send the permission as an actual letter could be a solution. We only would need to have a person at the WMF or a chapter who scans these letters. GPSLeo (talk) 05:48, 2 May 2024 (UTC)Reply
I believe scanned paper permissions are accepted, if done the proper way. They should be joined with some ID document, etc. And no, "Yeah, sure" is not a valid permission for a free license. We have daily dozens of people uploading copyrighted files under wrong assumptions about what is a free license. Yann (talk) 06:35, 2 May 2024 (UTC)Reply
For the family member above the simplest way would be to state that one user is allowed to upload and grant a free license in behalf of the copyright owner like we do it GLAM institutions. Then the copyright owner does not need to think about licenses and only needs to trust the person to whom they delegate the decision. GPSLeo (talk) 12:18, 2 May 2024 (UTC)Reply
An actual signed document would be a lot scarier than an email for old folks. Besides many grifters are able to convince them with email but when it comes to old-style signed verification old folks are more hesitant than any other way around. Maybe an "elderly friendly" verification process can be established that works with a video verification or "simpler and friendly" VRT mail text that states its not that of a big deal. VectorVoyager (talk) 18:57, 4 May 2024 (UTC)Reply
  •   Oppose I am not convinced that there is actually a problem with the VRT process, aside from that - like every process on Commons - it is critically understaffed. It feels like we're one Krd retiring from Commons VRT falling apart, but that's true for about half the project (CU will fall apart if Elcobbola leaves, for example.) The Squirrel Conspiracy (talk) 18:17, 4 May 2024 (UTC)Reply
    • There are several problems with the VRT process, not least the lack of transparency about who runs it and how (as the ongoing lack of answers to these February 2020 questions evidences), but the above proposal is a solution to none of them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 5 May 2024 (UTC)Reply
    • There are a lot of things on Commons (COM:HMS to add another example) like that. It's also on small-to-mid Wikipedias, Wikisource, etc. and most, if not all open source projects. Maintainence and communication is boring work, and very little people actively have time to do it, let alone to do it for a while. The problem gets worse once you realise VRT agents have to sign a confidentiality agreement. —Matrix(!) {user - talk? - uselesscontributions} 20:16, 16 May 2024 (UTC)Reply
  • Several years ago this elderly Wikiphotographer got a request from Warner Brothers who wanted a signed release for a photo of a Manhattan parade. This was not so much scary as annoying, as I had to download the document and the software to read its format, unjam my printer, print and sign, find my flatbed scanner, and remember how to operate it to send back. Darn nuisance; the picture was already released for free in Commons and I should have charged a $100 paperwork fee. My picture eventually became a background for a Manhattan barroom scene in the "Miracle on the Hudson" movie. I was kind of surprised Warner Bros didn't have an office within a couple miles of me in Midtown Manhattan where I could simply walk in and sign. I guess it would be a dream, to have sign-on-the-dotted-line services in several major world cities with a local Wikimedia Chapter. Or does some commercial chain such as Staples offer such a service? Jim.henderson (talk) 14:53, 9 May 2024 (UTC)Reply
@Jim.henderson: FWIW, I personally have a policy that if anyone wants paperwork filled out to give them more confidence about using my photo, that starts at $50 (and if it were something like Warner Bros. I'd probably say "since you don't want to use this on a free-license basis, what would you normally pay a commercial photographer or a stock company for a photo like this? I expect the same." - Jmabel ! talk 17:56, 9 May 2024 (UTC)Reply
It's probably tangential, but why wouldn't someone want to use it on a free-license basis? Like what's the advantage to having the original creator signing a form saying they can use the image when it's already freely licensed for any purpose, including that one, to begin with? --Adamant1 (talk) 19:29, 9 May 2024 (UTC)Reply
If it is not CC-0 this might be needed as there are cases where attribution is not possible or just not wanted. GPSLeo (talk) 19:37, 9 May 2024 (UTC)Reply
@Adamant1: in my experience there are two reasons: (1) publishers who want paperwork on file with someone swearing up and down that they really are the person who created the work and (2) institutions or businesses that have significant publicity/illustration budgets and would much rather pay someone than give a visible credit. On the latter front, I once got paid quite a bit -- I won't mention the number but let's say a normal month's rent for an urban apartment -- by a beer company that used one of my photos on a set of billboards (they also paid the person who was the subject of the photo about three times as much). Also, a few times when a museum has wanted to do a print to include a photo of mine in an exhibit, it would absolutely have gone against their policies not to pay me. The New Yorker even once paid me (modestly) because they wanted an artist to do a derivative work of one of my photos as an illustration. Etc. - Jmabel ! talk 14:40, 10 May 2024 (UTC)Reply
For an additional reason, for a commercial project I'm working on, I'm generally avoiding CC-BY-SA images. I feel I can follow a CC-BY license such that any reasonable licensor isn't going to have a problem. I'm not so comfortable using CC-BY-SA images, with a project that's by and large not CC licensed, in such a way that I know a reasonable licensor can't object.--Prosfilaes (talk) 19:18, 10 May 2024 (UTC)Reply

Showing cats of files in the mobile version of Wikimedia Commons edit

Latest comment: 8 days ago3 comments2 people in discussion

Hi!

When viewing a page of a certain file (e.g. File:Sulpture.jpg), we are able to see the associated categories at the bottom of the page. This section is missing in the mobile web pages version. I propose to add it!--PantheraLeo1359531 😺 (talk) 11:40, 12 May 2024 (UTC)Reply

Proposed that here at the Technical needs survey.
Technical development is overly neglected by WMF and simply putting up a banner and campaign could get more volunteer devs involved. Prototyperspective (talk) 13:37, 12 May 2024 (UTC)Reply
Well got to add that in this case I'm not sure what the issue is since it seems more likely the categories have decided by some at WMF to deliberately actively be hidden – it didn't really require any technical development to show them.
Depending on how they are shown, the needed development to undo what seems to be active category-hiding wouldn't need much development (it's just showing a link; that doesn't mean there could be better ways to show the cats than a simple link with some background color). If you or somebody knows or finds out why they have been hidden and/or what could be done about it, please reply. Maybe it has something to do with how search engines index WMC pages. Prototyperspective (talk) 12:22, 15 May 2024 (UTC)Reply

Proposal concerning images of quality/value edit

Latest comment: 8 days ago1 comment1 person in discussion

Hello everyone, I would like to report here to a broader audience a proposal that I have directly written in the related internal page (for better archive). It is here:

It concerns the evaluation procedures on image quality and related issues. Any comments or suggestions will be greatly appreciated. Thank you all! --teatroge (dm) 05:07, 16 May 2024 (UTC)Reply

Proposal to add perceptual hashes to SDC edit

Latest comment: 14 hours ago4 comments3 people in discussion

I asked this first on bot permission page, where they suggested that I should make this as proposal first.

So, I propose that the addition of perceptual hash (phash and dhash) values will be extended to all images on Wikimedia Commons as Structured Data on Commons (SDC) values. Currently, values are added only to a subset of images, such as images from Finna.

Background

Perceptual hashes are checksums which can be used to identify visually identical images even if they have been scaled, re-compressed, or subjected to minor alterations. Proposed hashes are effective for detecting if the images are identical but they are not effective for detecting similarity in cases involving cropping or rotation changes. Hashes are also implementation specific and in this proposal I am using Python Imagehash library.

For example FinnaUploadBot uses perceptual hashes to:

  • Confirm that images in the Finna repository match those on Wikimedia Commons, ensuring higher resolution re-uploads and metadata updates are done to correct images in Wikimedia Commons.
  • Prevent duplicate image uploads.
  • Find existing duplicate photos.
  • Update identifiers pointing to external repositories if they have been changed.

These are common use cases for developers of mass upload tools and usage could be extended for other tools also. Adding perceptual hashes to SDC would enable users to easily access the hash values without needing to download the commons image files first, allowing for wider use of the hashes. Additionally, SPARQL queries can be used to detect duplicate photos. Example query: https://w.wiki/A6qZ

Wikidata properties to be added to images

Example images with properties P9310 and P12563.

See also
Current status

Currently, we have hashes for 33 million photos out of the approximately 100 million in Wikimedia Commons in our database. Plan is to calculate phash and dhash values for all Wikimedia Commons jpg, tiff, png, and webp photos during the summer of 2024. There is also a REST API for querying the hashes. About 40,000 photos from Finna have phash and dhash SDC values.

Proposed implementation

For broader accessibility, adding hash values to SDC is the most straightforward approach. As adding hash values to all 100 million photos on Commons using bots is impractical, I suggest the following approach:

  • Begin by adding hash values to photos uploaded from GLAM archives and Flickr using bots. This would create a platform for tool creators to match photos between archives and check if a photo already exists on Commons. It would also serve as a shared platform with external parties such as GLAM and Flickr Commons to develop the idea further.
  • Investigate how to implement better methods for including automatically generated information in SDC without the need for adding these using bots. Other similar automatical values could include mime type, image width, image height, file size etc.

Feedback and insights from you will be invaluable for refining this proposal. Thanks. --Zache (talk) 16:43, 17 May 2024 (UTC)Reply

  Weak support and I agree this should ideally not be done by bots. See also Commons:Requests for comment/Technical needs survey/UploadWizardSDC. If there is interest I could add this to GLMA files as proposed with my bot. Just let me know. --Schlurcher (talk) 07:05, 23 May 2024 (UTC)Reply
  Support: This seems to me to be a good idea. Do you have any idea how you'll handle invalidating the hashes when a user uploads a new version of a file? --bjh21 (talk) 15:56, 23 May 2024 (UTC)Reply
One solution could be to track recent changes to index all uploads and then set the latest value as "prominent" and the rest as normal if there are multiple values. --Zache (talk) 20:38, 23 May 2024 (UTC)Reply

Purpose of the use of personality rights tag edit

Latest comment: 5 days ago1 comment1 person in discussion

I should make changes that apply the usage of {{Personality rights}} tag. Generally, the use of {{Personality rights}} tag does not apply to deceased persons, or people lived more than 100 years ago.

For example, the image of a living person (File:South Korea President Yoon Suk Yeol portrait.jpg) does have a {{Personality rights}} tag, while a deceased person (File:Dmitry Utkin passport photo (cropped enhanced).jpg) does not need {{Personality rights}} tag. 2001:4452:11E:F200:94DC:E923:5B60:B367 21:31, 18 May 2024 (UTC)Reply

Recent update to files upload edit

Latest comment: 4 days ago3 comments3 people in discussion

Please note that the recent update to files uploading has introduced a bug where to the files with the same name a number is added at the end of file description however the system now adds the same number while before the update the system was adding consecutive numbers i.e 01, 02, 03 etc. Could this issue be corrected please Kgbo (talk) 11:03, 19 May 2024 (UTC)Reply

Already adressed here: Commons:Upload_Wizard_feedback#Automatic_numeration_is_defekt and here Phab:T365107 --PantheraLeo1359531 😺 (talk) 19:16, 19 May 2024 (UTC)Reply
Pinging @Kgbo as OP.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:31, 20 May 2024 (UTC)Reply

Proposal for an "upload as derivation" button edit

Latest comment: 17 hours ago3 comments2 people in discussion

Hello community,

Given the somewhat intermittent and consistent issues with CropTool (see talk), I think a user-friendly alternative (read: backup) would provide some help to the community. Allowing a way, on an existing image, for a user to upload an image (such as an "upload as derivation" button) that doesn't replace an image, but automates the existing description templates, existing copyright templates, existing categories, and creating an extracted from template, so the user doesn't have to worry about that connection (and potentially fumbling it). Users can, and often do, make derivations of images outside of Commons, and not only just cropping. Often times, these new uploads may lose a previous detail or lose its connection with the source file because some of these derivation steps are ignored, forgotten, or are too cumbersome for the average user. --Engineerchange (talk) 14:12, 23 May 2024 (UTC)Reply

How would this differ from Commons:derivativeFX? - Jmabel ! talk 17:21, 23 May 2024 (UTC)Reply
Oh, this may be a today I learned segment for me. Thanks! The issues with CropTool have gotten quite frustrating. --Engineerchange (talk) 17:34, 23 May 2024 (UTC)Reply
Add topic
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=878934194"