RfC: Changes to the public domain license options in the Upload Wizard menu

An editor has requested comment from other editors for this discussion. If you have an opinion regarding this issue, feel free to comment below.

Should any default options be added or removed from the menu in the Upload Wizard's step in which a user is asked to choose which license option applies to a work not under copyright? Sdkb ^talk 20:19, 19 December 2024 (UTC)

"Removing templates from image pages" abuse filter: enable tagging or warning

In the description of "Removing templates from image pages" abuse filter, a note says "Removing warn until false positives go down. A lot of issues with category related templates. The tag "blanking" also seems inappropriate. A throttle may not be good for this filter since people working with categorization tend to do a lot of similar edits at a relatively fast rate.". As can be seen in the list of abuse filters, that's currently true: if the filter is triggered, it has no consequences at all. According to that filter's description page, "Of the last 377,416 actions, this filter has matched 52 (0.01%)". I think this number is small enough to tag or warn when the filter is triggered, so all cases can be reviewed and undone when neccesary. Some template removals can have a serious impact (for example, removing or replacing a license or license review template, by a vandal IP user). MGeog2022 (talk) 11:35, 18 April 2025 (UTC)

 Support, as proposer. MGeog2022 (talk) 11:36, 18 April 2025 (UTC)

 Support --Adamant1 (talk) 10:42, 19 April 2025 (UTC)

What I have seen in the last month is that warnings do not really help. Therefore I would suggest to make this a blocking filter for IP users and the warning for not autoconfirmed users. GPSLeo (talk) 10:34, 20 April 2025 (UTC)

+1 MGeog2022 (talk) 14:31, 20 April 2025 (UTC)

 Support As a regular at com:FILTERT, warnings won't work, the action should be disallow for all non auto confirmed users. Noting here that the filter (like all commons filters) will need to be rewritten for temporary accounts. All the Best -- Chuck ^Talk 19:25, 20 April 2025 (UTC)

Maybe an exception could be made so non-autoconfirmed users can remove templates from the files uploaded by themselves. MGeog2022 (talk) 11:01, 26 April 2025 (UTC)

Sorry, I was mistaking autoconfirmed users for autopatrolled users. Not all autoconfirmed users can be automatically trusted, but the abuse prevention doesn't need to be disallow, if the template removal edits are marked in a way that they can all be patrolled later. MGeog2022 (talk) 14:58, 26 April 2025 (UTC)

Not all autoconfirmed users can be automatically trusted. Well, maybe more than I think. Perhaps it's highly unusual that a vandal becomes autoconfirmed before detected. Many people here know it much better than I do, for sure. MGeog2022 (talk) 15:01, 26 April 2025 (UTC)

Self uploaded files are the main case of this as people remove deletion templates from their uploads without addressing the problem. GPSLeo (talk) 15:50, 26 April 2025 (UTC)

1 or 2 more weeks of margin can still be given, but I think that, if no one has any objection, this change should be implemented (by someone who can do it), taking into account what @Alachuckthebuck and @GPSLeo have said, to prevent the proposal from being archived due to inactivity. MGeog2022 (talk) 18:45, 6 May 2025 (UTC)

I made a copy of the filter that is blocking these edits for anon users Special:AbuseFilter/328. GPSLeo (talk) 13:05, 18 May 2025 (UTC)

@GPSLeo, thanks. Then, when the original filter is modified to block it also for non-autoconfirmed users (I suppose this is the intention), this can be marked as solved. MGeog2022 (talk) 14:29, 18 May 2025 (UTC)

@GPSLeo, are there any plans to also change the original filter, for non-autoconfirmed users, or will it be enough with the new filter for IP users only? For example, maybe all edits by non-autoconfirmed users with bad behavior are usually reverted, so it's not so important. In any case, I reply here so the proposal doesn't get automatically archived until it's clear that it has been fully solved. MGeog2022 (talk) 13:25, 4 June 2025 (UTC)

I am not sure. I think half of the edits currently hit by the non blocking filter are fine. But I created a new tag to see patrol these edits. GPSLeo (talk) 13:50, 4 June 2025 (UTC)

@GPSLeo, OK, in fact, my initial proposal was about tagging or warning only. If you think that this is fully addressed now, you can mark it as solved. Thanks for your work in it. MGeog2022 (talk) 20:04, 4 June 2025 (UTC)

Flag galleries

There are many galleries with flags. Many of them are absolutely usable even if currently incomplete like Flags of municipalities of Angola or similar. But there are other galleries with a scope that would result in tens or thousand files being added to the gallery like Gallery of Flags in 3:2 or Flags of country subdivisions. And there are galleries they could be useful but are currently used as political battleground and sandbox by IP users like Sovereign-state flags or with totally unclear definition Flags of stateless nations. Some of these pages where once clearly defined like Flag map of the world (original page) but at some point got expanded without prior discussion and no clear concept again primarily by IP users.

We need some way to deal with this. I think we should definitely delete the overly broad or unclear scoped galleries and restore the useful galleries to a version where they had a clear scope. Then we should protect them from IP edits. GPSLeo (talk) 10:52, 27 April 2025 (UTC)

 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:29, 27 April 2025 (UTC)

 Support doing somthing, but I think normal DRs and protection should do the trick. All the Best -- Chuck ^Talk 03:36, 28 April 2025 (UTC)

•  Support Probably the same should be done for galleries of national symbols and coats of arms. --Adamant1 (talk) 08:19, 28 April 2025 (UTC)
•  Support Agreed. Too many people push their flags and flag maps of Mycountristan and Myethnicia without sources. --Enyavar (talk) 08:42, 28 April 2025 (UTC)

 Support. Gallery pages about flags should be used for specific collections of the flags of closely related entities, e.g. flags of nations, flags of states or provinces within a country, etc. Collections of unrelated flags like "flags in 3:2" are handled adequately by categories; rollups like "flags of country subdivisions" are too broad. Additionally, I'd note that we have a whole mess of year-by-year flag galleries which are completely unmaintainable and which, in most cases, barely change from year to year. I'd propose that we get rid of most of those as well - collections of historical flags at specific, stable points in time could be useful, but we certainly don't need one for every single year. Omphalographer (talk) 21:15, 28 April 2025 (UTC)

I could definitely see some value in a gallery of national flags for a period (certainly longer than a year), but part of what would make it valuable would be precisely to note the changes in that period, whether it is Canada moving away from incorporating the Union Jack in its flag, the U.S. adding stars as it added states, the many changes of flags during the decolonization of Latin America or Africa, or the adding and dropping of Communist symbols from flags. - Jmabel ! talk 03:18, 29 April 2025 (UTC)

Couldn't you just do that with a regular gallery for flags of a country without it being based on a time period ("by year" or otherwise) though? Like what's the point in having a gallery specifically for flags over time when the same thing can be done with a regular one? --Adamant1 (talk) 03:39, 29 April 2025 (UTC)

You could for any one country, but it wouldn't show patterns like the wave of decolonization or the fall of Communism in Eastern Eruope. There is definitely value in a visual representation of such things, and Commons galleries are a good tool for showing it. - Jmabel ! talk 17:44, 29 April 2025 (UTC)

A timeline of changes to flags in a region could also be a great idea for a gallery. But what I meant there were collections along the lines of "flags of Europe in 1815" (i.e. post-Congress of Vienna), where there's a substantial difference from modern flags, not only in the designs of the flags but also in the nations represented. Omphalographer (talk) 18:37, 29 April 2025 (UTC)

•  Comment There are three separate problems being discussed here: 1) Galleries where the majority of images that should be in that gallery are non-free, and therefore won't be on Commons for the foreseeable future. 2) Galleries that don't seem to serve a clear purpose or provide a benefit separate from a category covering the same content. 3) Galleries as a venue for ethnic/geopolitical edit warring and vandalism. I'm not sure if the 'a gallery for every year, most of which are substantially similar' concern is an issue or not (apart from issue 3). In my opinion, we should be getting rid of galleries where issue 1 or 2 are the issue. For issue 3, that's a behavioral issue that should be addressed through the page protection and blocking policies. The Squirrel Conspiracy (talk) 21:54, 29 April 2025 (UTC)
•  Support - These are just honey pots for pointless edit wars. Delete them. Nosferattus (talk) 17:26, 4 May 2025 (UTC)
•  Support per others. --Yann (talk) 14:07, 12 May 2025 (UTC)

 Comment And there are galleries they could be useful but are currently used as political battleground and sandbox by IP users. The solution for this is page protection, not deletion. It would set a very bad precedent if a page is deleted because of political edit wars, propension to vandalism, or the like. Lots of very useful gallery pages could potentially be lost if things are managed in such a way. MGeog2022 (talk) 18:49, 13 May 2025 (UTC)

Here I'm talking about galleries such as Sovereign-state flags. Of course, other flag galleries created only for political advocacy purposes, should be deleted. MGeog2022 (talk) 19:10, 13 May 2025 (UTC)

 Support I think IP editing should be disabled. I agree that there are some useful contributions, but in most cases, they result in vandalism. They might be useful for Wikipedia, but definitely not for Wikimedia Commons. Incall ^talk 18:04, 19 May 2025 (UTC)

 Comment Don't delete the Flags of municipalities of Angola and Flags of country subdivisions, as both are notable enough to keep those. Alexphangia Talk 18:38, 7 June 2025 (UTC)

The Angola gallery is absolutely fine as it has a clear scope. The subdivision is also fine as there is a clear definition to only include first level subdivisions what is a reasonable size. But someone already started to also add historical countries with their subdivision. This is something that needs to be removed to prevent to gallery from also becoming an unusable unclear collection of files. GPSLeo (talk) 18:51, 7 June 2025 (UTC)

@GPSLeo I cleaned and fixed the Flags of country subdivisions. Alexphangia Talk 20:41, 7 June 2025 (UTC)

• Mostly  Support. One excepion is Sovereign-state flags, which has recently been kept after discussion here. However, all the 'per year'-galleries listed at Template:Sovereign-state flags should be deleted together with all galleries without a clear and well-defined scope. --TU-nor (talk) 14:44, 10 June 2025 (UTC)

Enforce Cross-Wiki upload restrictions

In August 2024 we had a clear consensus that we need to restrict cross-wiki uploads using the the mw:Upload dialog. That decision was announced on meta multiple times (most recent) and also tracked on phabricator phab:T370598. But nothing happened to make this technically working in a good way. Therefore I propose that we demand a technical implementation to restrict uploads using the Upload dialog. Upload using this feature should only be possible to users who are (auto)confirmed ether on Commons on the Wiki where they are using the Upload dialog or even more restricted. If there is no solution until August we change our already existing AbuseFilter to block all uploads using the Upload dialog by users how are not (auto)confirmed on Commons. This would mean that users see the upload feature when editing but the message that they do not have sufficient rights is only shown after the upload process. GPSLeo (talk) 11:09, 15 May 2025 (UTC)

 Support with Jmabel's caveat below.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:27, 15 May 2025 (UTC)

 Support as long as we can provide clear messages explaining what is going on when people are refused this possibility. - Jmabel ! talk 17:50, 15 May 2025 (UTC)

•  Support – This should be the first technical step to implement what the consensus has already agreed on. George Ho (talk) 04:46, 17 May 2025 (UTC)
•  Support We should just implement the abusefilter right away.--Bedivere (talk) 05:16, 17 May 2025 (UTC)

  @Bedivere: Please and thank you.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 06:53, 17 May 2025 (UTC)

  @Jmabel: Can you endorse this as an enwiki Admin?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:02, 25 May 2025 (UTC)

  • @Jeff G.: I'm not sure what you are asking for. How would that mean anything beyond my support above? - Jmabel ! talk 00:16, 26 May 2025 (UTC)

•  Support ASAP. 0x0a (talk) 05:39, 17 May 2025 (UTC)

 Support, any reasonable measure to prevent copyvios is good. MGeog2022 (talk) 14:30, 18 May 2025 (UTC)

 Support, by MGeog2022. Incall ^talk 17:58, 19 May 2025 (UTC)

•  Support --Yann (talk) 15:47, 25 May 2025 (UTC)
•  Support unfortunately, the interface used to upload through the visual editor is inadequate to handle/screen uploads -- information about licensing/ownership isn't sufficient, and it will upload even if the user never actually saves their edits (with no communication to the user that this is the case). Hopefully there will be improvements, but in the meantime it's too much of a risk to continue allowing this. — Rhododendrites ^talk |  23:17, 25 May 2025 (UTC)
•  Support as it currently is, as everyone has already mentioned, it's a hazard waiting to cause confusion again. I'd actually disable it even for people who are autoconfirmed on only the non-Commons wiki, as it doesn't take much to become autoconfirmed and you still may have no idea what Commomns is. The Tduk (talk) 02:36, 26 May 2025 (UTC)
• What will a rejected uploader see in the UI? Can they be redirected from there to Special:UploadWizard instead? whym (talk) 09:02, 26 May 2025 (UTC)

  

  I created an example on how the message would look like. GPSLeo (talk) 21:05, 28 May 2025 (UTC)

  And I noticed that warning messages are not possible. When the warning message is shown there is no save button visible. GPSLeo (talk) 21:08, 28 May 2025 (UTC)

  I'm a bit confused. Does File:Example_for_Upload_dialog_filter_message.png show what you want, but something impossible currently? If so, what would be possible instead, and what is the blocker to be resolved in the long term? whym (talk) 08:27, 30 May 2025 (UTC)

  This is the filter in production (I made it blocking uploads by the account TestLeo) that works. The thing that does not work is showing a message in warning mode of the filter that allows uploading after confirming the warning. The warning mode shows the same way as the blocking mode with the proceed button greyed out after closing the message through the dismiss button. GPSLeo (talk) 09:10, 30 May 2025 (UTC)

  Thanks, I think I understand it now. I wonder if it's a bug to be filed and resolved in the AbuseFilter side, if not in the upload dialog. whym (talk) 09:48, 1 June 2025 (UTC)

  The problem is in the Upload dialog and if someone touches this tool to make warning abuse filters working they could just implement the hiding of the tool for users with insufficient rights. GPSLeo (talk) 16:09, 1 June 2025 (UTC)

  Now I'm confused. Why would we use a filter that only warns the user and then allows the upload? kyykaarme (talk) 17:32, 1 June 2025 (UTC)

  The idea with the warning was to notify users that this tool will be limited soon. But it would not be that informative anyways as most users who see the message are autoconfirmed until the blocking for not autoconfirmed users is in force. GPSLeo (talk) 17:51, 1 June 2025 (UTC)

  Ah, now I understand. And I agree that the warning is not necessary, because the blocking will only affect newbies, and they are often editing for the first time when they also try to upload an image. Do you know if it's possible to translate the filter notice to other languages or is it only going to be in English? kyykaarme (talk) 17:06, 2 June 2025 (UTC)

  Yes it is possible to translate the message but without the support of the translate extension. GPSLeo (talk) 18:57, 2 June 2025 (UTC)

  I think a better wording for the "headline" would be "You do not have sufficient rights on Commons to perform cross-wiki uploads." Clearer about what rights are in question, and about what exactly they cannot do. - Jmabel ! talk 23:27, 28 May 2025 (UTC)

• Shall I create a Phab task asking implementation to restrict the Upload dialog then? I see consensus so far. —George Ho (talk) 12:42, 1 June 2025 (UTC)

  There is already a task phab:T370598 that was created after the initial decision. I also already added a comment about this new decision here. GPSLeo (talk) 16:12, 1 June 2025 (UTC)

  Nonetheless, I think I made the task broader than intended, didn't I? From what I read, the upload dialog and FileEx/Imp are different tools, and there's yet to support restricting other tools that aren't the upload dialog, especially at the Meta RFC discussion. I'm thinking about creating a child subtask (to that existing parent task). George Ho (talk) 00:12, 2 June 2025 (UTC)

  I think there are no other tools they work like the Upload dialog. File import is already restricted. GPSLeo (talk) 05:06, 2 June 2025 (UTC)

• It seems that the assumption behind the proposal is that cross-wiki uploads by new users are worse than average. How do we know that is true? I compared uploads by new users with cross-wiki-upload tag and all uploads by new users in the same date range. I found no evidence that CWU is worse in terms of the ratio of deleted uploads. One example: 15110 uploads and 5193 deleted (34.4% deleted) regardless of tags vs 3455 uploads and 968 deleted (28.0% deleted) for the cross-wiki-upload tag, both between January 11 ("20250111") and January 30 ("20250130"). This is only a quickly done database query. I'd be happy to correct any mistake I might have made (or you can fork it and run a modified query, if you want). --whym (talk) 06:11, 8 June 2025 (UTC)

  The statistic would need to be cleaned from out of scope deletions they are much less problematic than copyright violations. All files uploaded through the cross-wiki upload are in use and therefore in scope unless they are removed from the article. But that is complicated to evaluate. GPSLeo (talk) 08:11, 8 June 2025 (UTC)

  I checked a (admittedly small) sample of deleted cross-wiki uploads by new users (from the data above). It looks like fairly a lot of them are due to scope issues. (scope, copyright, scope, copyright, scope, scope, copyright, scope, scope, duplicate) It looks like this is because the associated page, typically a draft, is deleted, too. I did the same for all deleted uploads by new users, and in fact, more of them were due to copyright issues in my sample here. (copyright, scope, copyright, copyright, scope, copyright, copyright, copyright, copyright, copyright) whym (talk) 09:44, 17 June 2025 (UTC)

  In my opinion the issue is not whether they're worse than the average: the issue is that they're problematic and that's why something needs to be done. The WMF's own study showed that newbies trust that because they're able to upload an image with a couple of clicks it must be fine, because otherwise Wikipedia wouldn't let them do it. Then they get slapped with a deletion notice and told they're infringing on someone's copyright. If newcomers upload deletion-worthy images with the UW as well, then that can be addressed by modifying the Wizard. With the cross-wiki tool the newbies don't even have a chance of finding out what they're doing wrong before they've already done it. kyykaarme (talk) 09:01, 8 June 2025 (UTC)

  I see this message in the cross-wiki upload dialog: "If you do not own the copyright on this file, or you wish to release it under a different license, consider using the Commons Upload Wizard" (link), and you are supposed to agree to "I attest that I own the copyright on this file, and agree to irrevocably release this file to Wikimedia Commons under the Creative Commons Attribution-ShareAlike 4.0 license, and I agree to the Terms of Use" (link) before uploading. Newbies might ignore it or fail to understand, but I don't think it's completely accurate to say they are not given a chance to know. It's not too difficult to modify these MediaWiki messages to include more information - we don't need the apparently non-existent developer resources for just changing text. whym (talk) 09:20, 17 June 2025 (UTC)

• I think there is already consensus by then to favor the proposal, but I can stand corrected. --George Ho (talk) 08:06, 16 June 2025 (UTC)

"Culture of", "Society of" and similar categories

Abstract categories like "Culture of X", "Nature of X", "Politics of X" and "Society of X" are now widespread (where X is a country, region, or a city). But the problem is that such categories often get messy without following a consistent definition across a given topic. So, my proposal is to define the categories as follows:

• Nature of X – non-human aspects of X, like environment, landforms, organisms etc.
• Society of X – human aspects of X.
  • Culture of X – topics of X related to arts, beliefs, cuisine, customs, festivals, philosophy, religion, science, technology, traditions etc.
  • Politics of X – topics of X related to government, elections, royalty etc.

Sbb1413 (he) (talk • contribs • uploads) 08:23, 17 May 2025 (UTC)

Nature of X – non-human aspects of X, like environment, landforms, organisms etc. — where to put human-made parks or similar aspects of landscape architecture in this case? Where to put photos of flowereds that are maintained by a city's administration? Where to put agriculturally used fields? Also, where to put human-made water canals? Or what about rivers that got altered by humans (e.g. Category:Straightening of the Rhine)? Nakonana (talk) 09:17, 17 May 2025 (UTC)

I would move most what is currently in Nature of categories to the also existing Geography of categories. I think Nature of should only contain close up photos of individual plants or animals but then also if they are cultivated. GPSLeo (talk) 09:50, 17 May 2025 (UTC)

I oppose hiding "culture" under "society". Not intuitive for the average end user.

I'd put royal families under "society", but probably not under "politics", as a rule (though of course ruling monarchs do belong under "politics". I think it is ridiculous, for example, to have things like the current irrelevant Bonapartist and Bourbon claimants to the French throne under "politics"; similarly, some highly collateral relation of the British royal family.

I'd put parks both under "nature" and (indirectly) under "culture". - Jmabel ! talk 18:44, 17 May 2025 (UTC)

@Jmabel: Yeah, I confused royalty with monarchy, and the latter is a form of government. Regarding "culture" under "society", although I see how unintuitive it might be to put "culture" under "society", I know that separating the two is not always a good idea for the follwoing reasons:

• Culture refers to shared aspects of the society of a given region.
• Having two categories separately can confuse people. Especially categories like "ethnic groups" and "religion" would be put under both "culture" and "society" if they are categorized separately.

A better compromise would be to have a unique sortkey for subcats like "culture", "economy", "people", and "politics" under "society", so that they don't appear "hidden". Plus, a navbar can be used to access the important categories, albeit being "hidden" by larger categories. Sbb1413 (he) (talk • contribs • uploads) 04:48, 18 May 2025 (UTC)

Please remember, this is more about helping people find things than about ontology; the latter is more of a Wikidata concern. If people won't think to look for "culture" under "society", then it does not matter how ontologically correct it is. And there is nothing wrong with having a fair number of categories be under both, it's not like it has a significant cost. - Jmabel ! talk 19:43, 18 May 2025 (UTC)

As an aside: it's important to avoid excessive generalization in "TOPIC of PLACE" categories. An example of how this can be taken way too far can be seen at Commons:Categories for discussion/2025/05/Category:Cultural history of New South Wales, where a relatively small number of photos, mostly of grain silos, got spun out into dozens of effectively unrelated categories like Category:Cultural history of New South Wales. Omphalographer (talk) 20:21, 18 May 2025 (UTC)

Separate categories for humans and people

There has been objections to put people categories under animal categories for various reasons. On the other hand, the main reason given to support putting people categories under animal categories is that humans are animals. So, to better facilitate on how things are categorized, I have proposed to have separate categories for humans and people. Here, the human categories will cover certain aspects of humans as animals (like human activities, human fossils, etc.), while the people categories will focus on the individuals in more social aspects (like people of certain gender, occupation, state/territory/region, religion, ethnicity, etc. and also people in art like paintings and sculptures). Here's the list format of my proposal for the topic X:

• Nature of X
  • Animals of X
    • different taxonomic ranks of X
      • Humans of X
        • Human activities in X
        • Human fossils in X
• People of X
  • People of X by ethnicity
  • People of X by gender
  • People of X by occupation
  • People of X by religion
  • People of X by state/territory/region

So, that gives more flexibility regarding when to consider humans as animals or people. And it impedes the necessity of explicit categories like Category:Non-human animals. Sbb1413 (he) (talk • contribs • uploads) 18:35, 22 May 2025 (UTC)

• this example is just silly, bordering on a "strawman" agruement. why on earth would we need to make a category like that? HUMANS/homo sapiens are a sub-cat (several layers down) of the biological kingdom of "animalia". ANYONE who understands basic taxonomy would know that. ergo, it is AUTOMATICALLY UNDERSTOOD that animals not categorised as homo sapiens are "non-human". it is like suggesting that we would need a category for "things that ARE NOT red" (which we could create & populate, but it is not exactly necessary :P). Lx 121 (talk) 22:10, 16 June 2025 (UTC)

Any ideas about this? Or I can go ahead to implement it, although I will use Homo sapiens instead of "humans" when referring to humans as animals, as using "humans" can be confusing to end users. Sbb1413 (he) (talk • contribs • uploads) 06:56, 27 May 2025 (UTC)

• no end user who is at least moderately fluent in standard english would be confused by the use of "human" as equivalent to "homo sapiens"; if anything, "homo sapiens" would be the term requiring a higher level of education to recognise (as well as being longer). Lx 121 (talk) 22:22, 16 June 2025 (UTC)

I would appreciate if you hold off. I don't see any reason to think that this being ignored here means people think it's a good idea. I'm not necessarily saying it is a bad idea, but it's presumably a large change, and should have some sort of consensus behind it. - Jmabel ! talk 19:16, 1 June 2025 (UTC)

Maybe it would be a good change but could you maybe describe what the implied / subsequent / required changes would be? I can't see that. Prototyperspective (talk) 20:06, 1 June 2025 (UTC)

@Prototyperspective: My proposal is something like this:

• Homo sapiens: Humans in biological/paleontological contexts, like human body, human life, human fossils, and also the pre-civilization history of humans.
• People: Individual humans, categorized by name, gender, ethnicity, religion, occupation, state/territory/region/country, etc. Depictions of individuals in art also belong to this category, and also generic humans.

The changes require include:

• Create "Homo sapiens in X" for each "People of X".
• Categorize "Homo sapiens in X" taxonomically (or under "Animals of X"), but put "People of X" directly under "X".
• Categorize "Human life in X", "Human body in X" and others under "Homo sapiens in X", and "Female people of X", "Scientists from X" and others under "People of X" (or appropriate subcats).

Let me know if more clarity is needed. Sbb1413 (he) (talk • contribs • uploads) 05:33, 16 June 2025 (UTC)

•  Oppose as confusing.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:32, 1 June 2025 (UTC)

  So the main difference is that one (homo sapiens) deals with people as a species while the other (people) desls with individual people or groups of people. Is that correct? Laurel Lodged (talk) 07:15, 16 June 2025 (UTC)

•  Weak support - I can see the ontological reasoning behind this proposal... but we need to narrow this down. The 3G-Reservoir was created by "human activities", but I don't think an anthropogenic landscape change should be categorized under "Animals of China". BUT, if we use this additional tree to categorize pre-historic human activities (fossils; life reconstructions of Denisovans/Neandertals; maybe even paleo-to-neo-lithical cultures) and refrain from looping into modern-times humans, then this has merit. It makes no sense to have a loop/hierarchy from Category:Nature of California via the "Homo Sapiens" categories to Category:Actors from Hollywood, Los Angeles.
  If there is no media about prehistoric homo sapiens activity from Stratford, we don't include a category tree about genus homo, and certainly don't include Shakespeare categories. And we also do not make categories like Category:Human activities in Vernawahlshausen for single files like this. Would this be agreeable? --Enyavar (talk) 11:46, 16 June 2025 (UTC)

• HUMAN is species-specific, PERSON/PEOPLE is socio-cultural (for want of a better blanket term?). i.e.:

all "humans" are "people" (debatably at least xD)

BUT

not all "people" are "humans".

- in fiction, culture, religion, under law, & other socio-cultural concepts, & we might not get non-fiction extraterrestrial sentient beings anytime soon (although the betting odds on finding alien lifeforms of some kind are getting closer), BUT the questions of AI sentience & personhood are upon us now, & in the next 10 years it's going to get way more complicated.

in principle, ALL media files depicting or about humans should be filed under some meta-category of "human". (& nominally we could have "human" as a subcategory of "people"; as in "human-persons" vs "non-human persons?)

how we treat "personhood" is trickier. until now the loose/rough default has been to use "person" categories mostly for identified individuals (people by name, notable or otherwise).

i am flexible on whether we want to use a "double entry" -type system where files get both "human" & "people" categorisations. OR we could try to hammer out a "hybrid" categorisation terminology for "human people/persons" VS "non-human people/persons".

BUT for clarity, specificity, & plain old disambiguation, we need to be labeling human-related materials as "human.

& HERE is what wikipedia/en & wikidata have to say on the subject:

https://en.wikipedia.org/wiki/Human

https://en.wikipedia.org/wiki/Person

&

https://www.wikidata.org/wiki/Q5 - human

https://www.wikidata.org/wiki/Q215627 - person

(& you will note that BOTH projects very clearly DIFFERENTIATE between the 2 terms.

Lx 121 (talk) 21:46, 16 June 2025 (UTC)

• i have no strong opinion on whether to use "human" or "homo sapiens" in the category names. "human" seems more compact & efficient; but whatever practical "standard practice" we use with other species nomenclature is fine with me.

BACKGROUND INFORMATION - this matter has been a "pet project" of the user Sbb1413 for some time, & across multiple discussions.

in particular this user created & then "CLOSED" (in favour of their proposal, which they went on to apply) this discussion:

Commons:Categories for discussion/2024/08/Category:Male humans - created by the user

[] - CLOSED by the same user, who then went on to apply the proposed changes.

it seems to me at least somewhat improper for the same user to start a discussion, then close it themselves, declare victory, & apply the changes they wanted. especially with only limited conversation & no clear consensus supporting the proposed (wide-ranging) changes.

it is also worth pointing out that, based on the evidence, user Sbb1413 seems to have somewhat limited fluency in the english language? i am not trying to be mean in saying this, but it seems a fairly obvious point based on their own written comments. Lx 121 (talk) 22:02, 16 June 2025 (UTC)

& just to be clear  Oppose this proposal in its present form. "human" could debatably be treated as a sub-cat of "persons/people", or we COULD implement a "double entry" system where we put files into both categories, OR we could hammer out some hybrid terminology like "human-persons" vs "non-human persons". BUT "SPLITTING" human-related media files between "human" & "people/person" is just dumb, confusing, & thankless wasted effort/a hell of a lot on unnecessary work. Lx 121 (talk) 22:18, 16 June 2025 (UTC)

Proposal to convert Fake SVG to timed deletion template

There are just under 2,500 fake SVGs - which Commons defines as files that use the .svg (vector file) extension but are entirely composed of raster (non-vector) data.

If I have some time, I'd like to go through them and either reupload them under raster image formats or nominate them for deletion. Once we get the number down though, I think it makes sense to convert {{FakeSVG}} to a timed deletion notice (a "fix this or it will be deleted 7 days after being tagged" template like {{Dw no source since}}). I can't think of any good reason to host raster graphics under a vector format. The Squirrel Conspiracy (talk) 00:31, 3 June 2025 (UTC)

Many are in use though...? --Jonatan Svensson Glad (talk) 00:38, 3 June 2025 (UTC)

•  Oppose. Fake SVG files are legitimate images; they will have a modest bloat because the underlying JPEG or PNG file goes through another level of encoding. A few years back some Commons users debated ripping out the underlying bitmap image, uploading it, and then deleting the original SVG. That seems an enormous waste of effort. The files work right now, so they can be left alone. If they are used, then great. If they are not used, then leave them around and do not spend any effort on them. Many of the bitmap-only files could be (or should be) improved to use the SVG vector format, so you get into this strange cycle of uploading the embedded PNG file but then immediately tagging that PNG with {{Convert to SVG}}. The proper course is to consider {{FakeSVG}} as an invitation to improve that SVG file by uploading better versions rather than a slightly misused format that should be eliminated. See Category:Fake_SVG#Replacing_fakes_by_real_SVG Glrx (talk) 01:34, 3 June 2025 (UTC)

•  Support The files that are in use should be removed from other projects and replaced with better versions first. Otherwise, I'd probably support it. I'm actually kind of surprised there isn't already efforts being made to phase the files out. I'm willing to support this when, or if, that happens though. --Adamant1 (talk) 07:23, 3 June 2025 (UTC)

  I guess I wasn't clear. That was always my plan. The Squirrel Conspiracy (talk) 14:21, 3 June 2025 (UTC)

@The Squirrel Conspiracy: OK. Thanks for clarifying things. I support it then. --Adamant1 (talk) 01:27, 4 June 2025 (UTC)

remove mandatory username verification from username policy

The previous proposal now archived at Commons:Village_pump/Proposals/Archive/2024/11#username_verification_at_Commons was closed without conclusion.

As the given arguments prevail, I'm repeating the proposal:

Commons:Username policy since Special:Diff/355439634 says: "Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization."

It has never been Common sense since then that account verification is mandatory at Commons. There are currently only 550 transclusions of Template:Verified account.

Compared to Wikipedias, either company accounts are discouraged completely, or account verification is done to lay open concflicts of interest, or to grant company accounts some leeway when uptating employee numbers or similar without proof. Nothing of all that applies to Commons, account verification doesn't make any sense here, not least as it doesn't and cannot replace file permissions. The Volunteer Response Team doesn't have procedures for account verification at Commons, nor any capacity to handle them.

At Commons:Volunteer Response Team/Noticeboard once in every while there are discussion about such verification, sometimes requested by third party users, sometimes requested by the affected users themselves, but in nearly all cases for no practical reason, but just because the policy says so.

To adjust the username policy to common practice and common sense, I suggest to replace:

Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization.

to:

Use of the names of organizations is allowed on Commons. Account verification, proving that you are or represent the respective organization, shall happen only in controversial cases.

Please comment. Thank you. --Krd 14:35, 4 June 2025 (UTC)

• Support I agree with the stated proposal to remove the current text. I care so much about this issue that I wrote manifestos for reform at en:Wikipedia:Identity verification and Commons:Role account. My further opinions are beyond the scope of this stated proposal, and I could accept this proposal as is, but I do not like perpetuating the current system of identity verification even though this proposal would reduce it. As an alternative or supplement to this proposal, I would like to reform the identity verification process to be public with what users post on-wiki rather than private in VRT email, especially for corporate identity verification. If the process were more public and automated, then organizations could verify their own identities at will instead of getting a haphazard private review, and the wiki community could better review their identity evidence. This proposal is not about identity verification in general, but only about corporate identity verification. I think it would be too disruptive to quickly reform all of our processes, but starting only with corporate identity verification is a great start. Perhaps we could have a recommended user page template for corporations, and if they want to verify identity, then they fill it out and post to their userpage. Bluerasberry (talk) 15:09, 4 June 2025 (UTC)

  • If There are currently only 550 transclusions of Template:Verified account then where is the problem? If companies and other orgs don't want to have to verify which doesn't all that much effort, then they could just use a name that isn't their company name.
  • Could you or Krd, please respond to the concern and reason for why this policy exists, namely the potential problem of impersonation and otherwise misleading people (for example making them think badly about the org)?

  All in all I see no need for this change but a very clear problem that would result from it. Prototyperspective (talk) 10:35, 6 June 2025 (UTC)

• I saw the policy grounded in the wish to alleviate any fears about mischievous impersonifications, as it is actually already worded "[...]proving that you are or represent the respective organization." This is IMHO sensible and should be kept, I do not see the verification as proxy for copyright statements or the like. Regards, Grand-Duc (talk) 15:12, 4 June 2025 (UTC)

  How could such mischievous impersonifications look like at Commons? Is there any know case? Who can handle this in the future, if VRT cannot? Krd 15:35, 4 June 2025 (UTC)

  Before I could construct a hypothetical case, Jmabel said something below (-> "doing some borderline shitposting") that is likely in the same vein as my thinking. I do not know about an actual case, and as VRT handles the "Benutzernamensverifizierungen" in DE-WP, I do not see any technical hurdle to do the same for Commons (may it be a manpower issue?). Correct me please if I'm wrong. Regards, Grand-Duc (talk) 22:51, 4 June 2025 (UTC)

  As I already mentioned in my initial post, the fact that other projects do it is a moot argument. Perhaps it makes sense for them, perhaps not, but Commons is not Wikipedia. If one user misbehaves, they will be blocked, and then perhaps renamed, but that doesn't mean all user have to verify because one could or could not do wrong. Krd 04:11, 5 June 2025 (UTC)

   Oppose per Grand-Duc's explanation. And maybe one could allow/better-enable orgs to prove they actually run the account without VRT involvement. Prototyperspective (talk) 21:33, 5 June 2025 (UTC)

• Re "The Volunteer Response Team doesn't have procedures for account verification at Commons, nor any capacity to handle them": We do occasionally do account verifications (see {{Verified account}}) so that prolific uploaders who also upload their work elsewhere do not have to repeatedly send permissions to VRT. To me, whether verification is required does not depend on whether the account represents an organization or a person - it depends on whether the account represents some person/entity that is famous or has an alternate online presence (such as social media or personal website) that would make it theoretically possible for someone to impersonate them by downloading their images from their website and uploading them to Commons. -- King of ♥ ♦ ♣ ♠ 17:00, 4 June 2025 (UTC)

I'm trying to understand how this fits in with other policies. (1) If an account is verified as belonging to an organization, and that account uploads content for which that organization clearly holds copyright, am I correct that we can skip the VRT process for those uploads? Because that is the main context in which I have seen accounts with organizational names used. (2) If we do not require that accounts with names of organizations be verified, am I correct that we will still have to have a process by which an organization can say, "That account does not represent us" and have it renamed or blocked? For example, someone could wreak quite a bit of havoc opening an account as, say, User:General Motors or User:UNESCO and doing some borderline shitposting. - Jmabel ! talk 18:30, 4 June 2025 (UTC)

Per all VRT experience, account verification cannot replace any file permisison at all. That a file is uploaded by User:General Motors doesn't at all mean the GM company is copyright holder of the files they upload. For the exact scenario VRT does have a permission procedure, i.e. Category:Custom license tags with ticket permission. Krd 04:06, 5 June 2025 (UTC)

If they upload content with a free license on their website we normally trust them that they have the permission to do so. If they do not upload it to their website but directly on Commons we require additional proof beyond who operates the account? This does not make sense. Independent of this I think account verification should not be done on every Wiki but centralised on meta. GPSLeo (talk) 05:12, 5 June 2025 (UTC)

Yes, the VRT offers them additional support to make them aware that they mistaken and are not copyright holder, which is the case in the majority of such cases per my VRT experience. Creating the impression that an upload by a verified account is more trustworthy than an unverified account, puts additional risk on the re-user. You can of course say that it's not our business to care. That's a valid argument, but I'd disagree. We can achieve a better result and at the same time have less work, without user verifications. Krd 07:28, 5 June 2025 (UTC)

Support I agree with this. Nemoralis (talk) 19:56, 5 June 2025 (UTC)

•  Support admittedly this isn't something I have much experience on. Nor do I necessarily understand how it fits with other policies per Jmabel's comment. That said, Krd has enough experience on here to know what their doing and there isn't any obvious issues with the proposal from what I can tell. So it makes sense. Except for the parts that don't, but whatever. I trust Krd knows what their proposing even if I don't completely understand it myself. --Adamant1 (talk) 07:20, 6 June 2025 (UTC)

•  Support I have never requested verification differently as in the proposed phrasing. As a VRT agent however, I did process requests from institutions that requested verification because the username policy says so.

In general, it makes uploads done by accounts with for instance the names of GLAM orgs and (well known) artists more trustworthy, and those users don't have to request VRT permission for every image, or every batch of images, anymore since the account is already verified through VRT. The verification that the account actually is who they say they are, helps them to re-use images they own the copyrights to, and that for instance they might have used on their websites or in communications before. This brings down the work load in image patrolling, in deletion requests, in restoring deleted images, and in VRT.

However it does not mean they are knowledgeable on the topic of copyrights, and does not mean that, for instance, if any GLAM org would upload an image of a work by Karel Appel, there is no need to request a validation for this specific image. Commons users need to be aware that the verification tag is for the account, and they can still raise concerns about the individual image copyrights as they see them. Ciell (talk) 07:40, 8 June 2025 (UTC)

Proposal: Tighten upload process and related policy.

Given that uploaders are expected to know and understand the status of works they upload, I am asking for opinions about tightening the upload and related policy, for post June 2025 uploads.

Namely :

1. Unless a (revocable) trusted uploader status is held by a User, any upload from the which has date later between 1930 and 2005 (Essentialy the pre Commons era), is automatically flagged for license review, and is indicated as such, the relevant template being added during the upload process. Bot users, GLAM and bulk uploaders would be able to apply for "trusted" status.
2. Commons should keep a list of Users granted 'trusted' status.
3. Uploads utilising specfic 'exemption' licenses such as {{PD-USgov}} should include a rationale as to why the exemption applies. In respect of 'non-renewal' of US works, this rationale should ideally include original registration numbers in the Catalog of Copyright Entries or Copyright Record Books,(Commons trust it's users to have undertaken a reasonable effort to identify the status of a work.)
4. Uploads from Internet Archive, Hathi and Google should not use bare links, but the appropriate templates, with bare links being converted by an appropriate bot. As part of the use of these templates, the additional reviewed template should be added either by trusted uploaders, or during the license review. On new uploads, identifiable bare links, are bot migrated to the templated forms.
5. Works upload without a license, are 'auto-flagged; for deletion during the upload process, or by a bot subsquently.
6. Unchallanged speedy/copyvio deletions, are deleted on 'expiry' of the time period in the relevant template (admin bot enforced.) Striking this as comments below say this already happens.
7. Uncontested "Deletion requests" (Those that get no replies) are after the expiration of the consultation period, automated closes, with the files being removed, but with "Unedeletion information" being given when the request is auto closed.
8. Abolish "no consensus to delete" outcomes. A file is either 'Delete' or 'Keep' with a decision reached.
9. On uploads of books or publications, if multiple volumes, printings or editions exist, then it's the date of most recent applicable edition used to determine the license, if there is no information about earlier ones. (This would mean that if a 'Revised' edition of a work by the same authors exists, It is the revised edition that is used to determine if the status is acceptable on Commons, even if the earlier edition would otherwise be permitted. This is to ensure text integrity.)

ShakespeareFan00 (talk) 10:01, 6 June 2025 (UTC)

Didn't understand all the points you propose but  Oppose for now point Abolish "no consensus" outcomes. A file is either 'Delete' or 'Keep' with a decision reached. – if there is no consensus either way then it's not good to claim or call it otherwise; moreover I don't know what you even mean by that since files are already either kept or deleted. Also #5 Works upload… is already done. Prototyperspective (talk) 10:39, 6 June 2025 (UTC)

A firm decision has to be reached about retaining (Keep) or removal (Delete) with a clear rationale as to either outcome. "No conesnsus to delete" cannot be used as a reason for closing the DR, which typically favours a file being retained. If a file/media is retained a compelling rationale for doing so should be stated on closure (which could include a 'Withdrawal(Kept) if the nominator found new information for example. Most DR's I've been involed with end in a clear outcome.

Commons needs to have a 'can we realisticaly prove it's 'status' (and usability)' culture, rather than a 'retain because we couldn't work out what was wrong' culture. Quite a lot of the contributors I've dealt with have the former rather than latter stance though, and such a shift, would to my viewpoint, further the sort of academic approaches Wikimedia projects aim for. ShakespeareFan00 (talk) 12:30, 6 June 2025 (UTC)

"No consensus for deletion" is a necessary rationale for DR closures that concern COM:SCOPE rather than questions concerning copyright. Not all DRs are about copyright issues and therefore consensus might matter. Some cases of De Minimis might also fall under "no consensus" (while others might fall under COM:PCP). Nakonana (talk) 13:11, 6 June 2025 (UTC)

1. There's already the user group "autopatrolled" for that, I think?

7.  Oppose Such DRs shouldn't be auto-closed / automatically deleted, because a lack of replies doesn't necessarily mean that there's no opposition to the DR. It could just mean that the DR in question did not attract anyone's attention and that nobody has looked at it (yet). It still requires at least one human user to assess the validity of the DR rationale. A bot cannot make such an assessment based on such a non-indicative criteria as "no replies". "No replies" doesn't say anything about copyright, SCOPE, etc. Nakonana (talk) 13:21, 6 June 2025 (UTC)

Do new uploads get auto tagged for license review with the specfific template? Autopatrol is for page contents typically. ShakespeareFan00 (talk) 16:29, 6 June 2025 (UTC)

Not a specific tag for license review, but autopatrolled means that the upload doesn't show up in "recent uploads" (or at least that's how it was explained to me here). Nakonana (talk) 17:11, 6 June 2025 (UTC)

Yup. One example could be a bogus DR that was overlooked or too absurd to be commented. --PantheraLeo1359531 😺 (talk) 20:10, 18 June 2025 (UTC)

•  Oppose Although purely procedurally. The upload/deletion process clearly needs to be tightened and there's some good ideas here about how to do that. I don't think it's a good idea to combine 9 different ideas into the some proposal. Each one needs it's own separate discussion and consensus. Otherwise it's just risks this turning into a potshot of random support and oppose votes without a clear outcome and no way to deal with it. --Adamant1 (talk) 13:56, 6 June 2025 (UTC)

@Adamant1: Another idea not listed here, is going to be controversial, and that is that the Upload process should look for specific authors, titles or publishers, and warn during the Upload process. PG has a set of Renewals for post 1964 "Books" (Commons also has a complete run of the CCE to 1978!), and if those sets of data were in Wikidata, it would not only be useful Biblographic data to have, it's potentially a means of having a more friendly Wikimedia way of doing pre upload screening, warning uploaders, rather than "Never uploaded anything by Disney!" filters more aggressive rights holder want to mandate on hosting sites. Of course getting that Data in Wikidata would be a Mars-shot project of itself. :( ShakespeareFan00 (talk) 15:55, 6 June 2025 (UTC)

That's an interesting idea. I thought about something similar awhile back where the uploader could put the creators name in and it would check the copyright status of their works on Wikidata. Since that information exists for a lot of people, if not individual works yet. Although it would take them putting in the name to begin but it's better then nothing. Maybe a lot of this stuff can be semi-automated once AI gets better. Who knows. Something needs to be done about the amount of COPYVIO that gets uploaded on here though. --Adamant1 (talk) 16:01, 6 June 2025 (UTC)

Some books and editions have Wikidata entries, but as always it's as case of someone needing to put the data in the system. ShakespeareFan00 (talk) 16:29, 6 June 2025 (UTC)

Principle of least astonishment

Commons:Principle of least astonishment (motivated by this discussion) discusses how the principle of least astonishment applies to Commons, followed by a closer analysis of a tricky case, the nude and partially nude "Geekography" photographs by Exey Panteleev, and proposes a specific way of handling the latter, which has been the subject of multiple DRs and other lengthy discussions, so far with no generally satisfactory conclusion.

Currently Commons:Principle of least astonishment has status only as an essay; I would like to see it adopted as a guideline (possibly with some minor rewordings) so that we can agree that the proposed way of handling Panteleev's photos is something we can enforce as consensus. The short version: in general, these are in scope, but they should not be categorized under the technical topics that they reference, because people looking up technical topics would reasonably expect these categories not to contain NSFW content. - Jmabel ! talk 17:57, 6 June 2025 (UTC)

•  Support as proposer. - Jmabel ! talk 17:57, 6 June 2025 (UTC)

•  Support Strongly. Something like this is badly needed. People shouldn't be forced to view nude photographs on here when they aren't looking for them. --Adamant1 (talk) 18:02, 6 June 2025 (UTC)

 Support makes a lot of sense. Prototyperspective (talk) 18:21, 6 June 2025 (UTC)

 Question How is this intended to work with structured data? Are these files also banned from having the categories where they were removed to be added as structured data? GPSLeo (talk) 18:40, 6 June 2025 (UTC)

@GPSLeo: I don't have a strong opinion on that, but I can see it could become important as search leans more heavily on SDC. Would it be OK with you if we confine this proposal to the general "least astonishment" principle and its application to categorizing these, and then separately take up the SDC aspects? - Jmabel ! talk 21:32, 6 June 2025 (UTC)

For search this proposal does not solve the problem anyway as the search also uses the file name and description. For the search the only solution would be filters they can be applied during search. This is also the reason why I am sceptical with this proposal as it only covers the category system that is the least important for people looking for photos. GPSLeo (talk) 04:56, 7 June 2025 (UTC)

Realistically both need to be dealt with. Even if categories aren't the main way people look for images. Like it's OK to show people porn when they aren't looking for it just because less of them will see it going through the category system then they will searching for an image. --Adamant1 (talk) 05:22, 7 June 2025 (UTC)

If we would have a gadget that allows hiding for all photos with depicts statement vulva or penis this hiding of these files could work on category pages and in the search. If we had such a gadget we do not need to care about the categorisation as everyone could just enable the filter. GPSLeo (talk) 05:44, 7 June 2025 (UTC)

has characteristic → NSFW ? Jerimee (talk) 15:30, 7 June 2025 (UTC)

We do not need a special tag. Simply looking for depicts (P180) human penis (Q8124), human vulva (Q116196473) and maybe some other statements should we sufficient. It only needs a tool that allows hiding photos with such statements on every page. But of course creating such a gadget is not that simple if it should not result in very poor loading times. The request for such gadget is already eight year old phab:T198550. GPSLeo (talk) 17:23, 7 June 2025 (UTC)

Anecdotally, I've found that P180 statements that mention anatomy with sexual connotations often get reverted without comment. Jerimee (talk) 21:25, 7 June 2025 (UTC)

They are often added as simple spam or to photos where these body parts are barely visible. I also would not add a NSFW tag to these photos. GPSLeo (talk) 04:39, 8 June 2025 (UTC)

@GPSLeo: Bosses and other authoritarians have no respect for "de minimis" depictions.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 04:46, 8 June 2025 (UTC)

@Jeff G.: Probably people who do that are just tagging for later use with AI algorithms or something. I see the same thing with categories a lot and that's at least my guess. I can't image anyone who uses this site to begin with really about it outside of that though. --Adamant1 (talk) 05:03, 8 June 2025 (UTC)

@Adamant1: Would you care to rewrite that post more clearly?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:20, 9 June 2025 (UTC)

I am talking about photos like this File:Fotothek df n-11 0000457.jpg or this File:1983-07-Bugsinsee-RalfR-img08012016 036.jpg. GPSLeo (talk) 05:25, 8 June 2025 (UTC)

@GPSLeo: The objections could include "unclothed" for both and "OMG full frontal nudity" for the second. I don't object, but prudes could.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:23, 9 June 2025 (UTC)

 Question: are there any ways you foresee this guideline being applied which go beyond nudity? One potential example which comes to mind would be images of visibly dead animals (e.g. carcasses at butchers, roadkill, etc). Omphalographer (talk) 00:17, 7 June 2025 (UTC)

I was going to ask if this approach was going to be applied to 'ideologicial' subjects, like materials from certain political groups that are trigger material for some people? ShakespeareFan00 (talk) 12:15, 7 June 2025 (UTC)

Both of that makes little sense to me. What would make sense to me is not showing media depicting dead or dying people in unexpected places and/or enable users to have them blurred. Prototyperspective (talk) 12:19, 7 June 2025 (UTC)

The sort of situation I have in mind is "if I open up the category for skunks (or whatever), I should expect to see pictures of them alive, not flattened on the pavement". Which isn't to say that we shouldn't have those photos at all, but rather that they should be categorized separately, even if the resulting category is small. It feels like another case of the same underlying principle of "don't show the user potentially distressing things in places where they didn't expect to see that". Omphalographer (talk) 21:37, 7 June 2025 (UTC)

Not sure what you mean precisely by "ideological subjects". If you mean things like political flags, those are typically going to be expected in the categories they're in. Omphalographer (talk) 17:00, 7 June 2025 (UTC)

Yes. And don't forget female hair. And piano legs... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:47, 10 June 2025 (UTC)

 Support Long overdue --Kritzolina (talk) 06:29, 7 June 2025 (UTC)

 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 08:23, 7 June 2025 (UTC)

 Support. Jerimee (talk) 15:31, 7 June 2025 (UTC)

Leaning oppose on this. It seems like a guideline based entirely on an unusual case. Why isn't a simple finding of consensus not to categorize the Geekography images according to their "geek" topics sufficient to deal with that? What other cases would this be applied to. The lack of other examples is what worries me, as it opens the door to a wide range of arguments over what is or is not "astonishing". There is also the issue raised above that it does nothing for the main way people find images (by search). This seems to me like yet another case where finishing the job of implementing SDC would help. Some sort of major aspect/minor aspect distinction of the ability to default search to excluding images with some NSFW/nudity/violence/whatnot flag(s) -- things our category system simply doesn't do. — Rhododendrites ^talk |  20:44, 7 June 2025 (UTC)

I beg to differ. The first 25% or so is a guideline, and this is certainly not the only case the guideline applies to, but this case shows well how complex it can be to apply the guideline it in practice. Doubtless there will be other cases eventually worth adding. - Jmabel ! talk 00:31, 8 June 2025 (UTC)

•  Support per proposal. Yann (talk) 22:37, 7 June 2025 (UTC)

Isn’t it kind of already recommended that categories only be used for things that they couldn’t realistically illustrate? Like an image of the Eiffel Tower that incidentally includes a squirrel should not be in Category:Squirrels. Similarly we wouldn’t put File:Boxing Glove.jpg (NSFW) in Category:Boxing gloves even though it incidentally includes a boxing glove. Dronebogus (talk) 00:54, 8 June 2025 (UTC)

Yes, but the reason the Geekography stuff is a special case is that if these were not nudes, there are probably circumstances where they would be good illustrations for some of these topics, and unlike other places where such issues have arisen, our usual solution to that (make a subcategory) doesn't work well here. - Jmabel ! talk 03:55, 9 June 2025 (UTC)

if these were not nudes I see no reason for why that would be so and disagree. Writing a few words or painting a small logo on nonnude bodies wouldn't be useful illustrations either and for other subjects, such photos aren't useful. Prototyperspective (talk) 12:02, 9 June 2025 (UTC)

@Prototyperspective: so would you think File:Wikipedia pastrami.jpg should not have any category related to Wikipedia? - Jmabel ! talk 23:45, 9 June 2025 (UTC)

I think the key part / disagreement is about you describing them as [good] illustrations [for some of these topics]. What I said is that they don't really illustrate the subjects (and especially not well). The file you linked to is in that cat via only "Things named after Wikipedia". Btw, Category:Named-after categories would be one of the category-types one should be able to easily filter away with a click when looking at a cat with the deepcategory view since those are only in some way related but not really about the subject / useful in that viewmode. Prototyperspective (talk) 09:34, 10 June 2025 (UTC)

 Question is this proposal only intended to stop soliciting images of nude people in categories, or is there another motive? I am not concerned with the effects of stopping nude images, and I support this proposal if that is its only application. I am concerned that the whole idea is introduced with something that has nothing to do with nudes: "We try to keep a similar structure for category names with similar purposes. E.g. if we have a category Category:1968 in the United Kingdom we should have Category:1968 in England, not Category:England in 1968." Hmmm. So if this principle is consequently applied, then a lot of categories need to be reconsidered, including the above example, actually. We DO have Category:England in the 1960s but not Category:1960s in England; and the same on the century-level Category:England in the 20th century, not Category:20th century in England. By now, I have become familiar with this contradiction in the naming-principle, but for the first years, I always had trouble finding the correct category name. So yes, this has regularly astonished me. I am not opposed that this establishes a standard either way, and preferably location first, since the <year in location> is the odd one out in the whole categorization scheme. --Enyavar (talk) 18:20, 8 June 2025 (UTC)

It is weird that we ended up with a different convention for decades and years for places, but at least each is applied more-or-less consistently across locations. Could our category naming be more consistent? Absolutely, and every so often we end up with some pretty big projects to apply consistency to some area. This particular one (decades vs. years for places) is probably a lost cause, because at this point it would involve renaming hundreds of thousands of categories. Should have been caught 15-20 years ago, but wasn't. - Jmabel ! talk 03:52, 9 June 2025 (UTC)

Briefly, I don't think it's a lost cause but also not that it's important. In general, it would be best if decade-first cats redirected to the cats with naming schemes of decades last or vice versa so ideally doing something with some scripts/bots would be best; also I doubt it's hundreds of thousands of cats but since they should all be in some meta-category like categories by decade, it shouldn't be too hard to build a script to address this so it's standardized and the other naming scheme cat title is created as a redirect. Prototyperspective (talk) 12:00, 9 June 2025 (UTC)

I also don't think that this is a lost cause. We'd need to establish general agreement on the matter, but with a large quorum and not the usualy ~10 support voices.

I just wanted to clarify that this "principle of least astonishment" is currently mainly about nudes, but that would only be one application. There might be other category-related issues where people might be "astonished", and they would then be correct in wishing to apply this principle. --Enyavar (talk) 13:41, 12 June 2025 (UTC)

What to do with mass uploaded PDF/DJVU which are not in use or verified?

Back in 2020 Fae and others uploaded a substantial proportion of the IA's collections. There was a reasonable good faith assumption at the time that these would be integrated into Commons and ultimately Wikisource, and that at some point the files would be checked for compatibility with Commons and Wikimedia objectives.

This didn't happen, and subsequently, it has been found that due to the metadata provided, and asepcts of the upload process used, widespread license errors, a number in copyright works (both PDF, dju and image media), and faulty metadata has resulted.

So what is the sensible response to this, given that asking Commons license reviewers to check every single upload is a farcical task, as is requesting a wipe of all unused files?

I'm against in favour of a massive 'nuke' delete, given that I have found compatible items, which HAVE subsequently been useful to Wikisource, without needing to re-upload them from IA directly. However, something has to be done, to avoid the 'problem' files becoming a time-bomb of potential issues. Would a more nuanced removal of post 1930 file be a possible solution? (I.E WE adopt the Hathi-Trust policy approach, of only considering pre 1930 media 'safe', and only allow media after this date on a case by case review by appropriate experts.) ShakespeareFan00 (talk) 13:41, 8 June 2025 (UTC)

A lot of the work of getting rid of these, without throwing out the baby with the bathwater, does not need to be done by people who are officially license reviewers. In particular, anyone can mark clearly problematic files for deletion. - Jmabel ! talk 03:57, 9 June 2025 (UTC)

Specic howlers, include clearly post 1930 works in error marked as PD-USGov, which they clearly are not.

@Jmabel: Are you able to help provide some hints or filters? I favour the removal of anything post 1930 on the grounds that date can be looked for relatively easily without getting into soecfic nuances, (or need to check external catalogs.).. ShakespeareFan00 (talk) 10:14, 9 June 2025 (UTC)

I've stopped short of calling for a CCI on Fae, given that all thier uploads were made in good faith, based on the infromation (and tools they had.) . But if it's going to take a CCI to solve issues that have persisted since the left, I think it should be. Is there a process for iniating one? Files tagged in error as PD-USGov is the largest problem. (An aside is the quality of the scans in places, but that's not something Commons generally worries about) ShakespeareFan00 (talk) 10:14, 9 June 2025 (UTC)

Some key areas I've noted:

Seed catalogs - Pre 1930 are PD-US and the license can be updated. I did some recatting this moring to diffuse the relevant categoru.

USPTO Library items, which are not US Gov works , but where tagged as such because they were tagged as FEDLINK collection items in the metadata. Some where PD-US, but not all.

Post 1978 Naval Postgraduate Student thesis. These are not PD-US-Gov works, despite some on Commons arguing that the writers of some of them are serving military, in some instances. Many deleted items of this type were not and have not been authored by Federal entities ( Typically these are civilian, state or Foreign military.) Pre 1978 items have been considered no-notice(when none was found), but the collection includes items from various other institutions, and requires review.

Clearly post 1930 journals, tagged in PD as error, because IA had followed a library practice of recording serials date as the date of the first issue of the serial, as opposed to the cover date of the publication, in metadata, which was used in error during the upload process.

Flickr 'Commons' images tagged as PD by default, although examining the source publication proved the publciation and images were not.

and others...

Fae uploaded at least 500,000 IA items I think, and it's far far easier to make a bold decision and conclude the process to check these pre or post upload failed, or never happened, then it is to expect Commons users and viewers to do audits themselves that they would have reasonably expected a responsible library or archive to have undertaken beforehand. A broad post 1930 cutoff cull deletion would quickly resolve the issue, without the extended period of non-action from Commons Processes. ShakespeareFan00 (talk) 10:33, 9 June 2025 (UTC)

Not to say I think there should be a mass deletion of everything uploaded by Fae but they imported a ton of stuff from GLAMs that have questionable origins, licenses, Etc Etc. And a good percentage of the files have never been organized or checked to make sure they are PD. Like photographs that have no evidence of prior publication but they aren't being deleted because of coming from a library or wherever. Deleting everything post 1930 would obviously be an option but then there's a lot of post 1930 stuff that's still PD in the USA and it wouldn't deal with pre-1930 works that haven't been published before either. Individual DRs for a million files to make its done right obviously wouldn't scale. But then again, I'm probably against a mass culling. So I don't know. It doesn't seem like there's a good solution here. --Adamant1 (talk) 15:49, 9 June 2025 (UTC)

All books which are in the public domain are also in scope. So I oppose deleting any of them. I have quite a number of reservations about Fae's uploads (notably poor categorization), but I don't see any reason to delete them. Yann (talk) 16:48, 9 June 2025 (UTC)

Books have to have some plausible educational value. If I took a random assortment of non-educational freely-licensed photos off of Flickr and made them into a book, they wouldn't ipso facto become educational or in scope. That said, to your main point, I would certainly prefer if we didn't delete Fae's uploads en masse, but I can understand why someone would want to, as copyright violations need to be taken seriously and Fae evidently just noped out of the project years ago and will not be around to fix the mess personally. —Justin (koavf)❤T☮C☺M☯ 16:57, 9 June 2025 (UTC)

Take this for example.. Category:Henry G. Gilbert Nursery and Seed Trade Catalog Collection needs splitting by year, and the erronous USGove licenses need upadting to PD-US , PD-no-renewal, PD-no-notice etc.. NONE of these are US Gov works, post 1925 files just got tagged with it as these were under a USDA collection...I've been attempting to diffuse manually, but barely made a dent. ShakespeareFan00 (talk) 17:44, 9 June 2025 (UTC)

There's definitely a problem of some of these government collections including works authored by non-government entities, probably by accident. I seem to recall finding a couple of PDFs of mid-20th century novels (unambiguously under copyright) in one of these collections, and I wouldn't doubt for a moment that there's more buried in there. Omphalographer (talk) 20:09, 10 June 2025 (UTC)

Addition of more options in visual uploader

I have noticed there is a lack of commonly used public domain options in the visual uploader.
I have seen logos liscensed wrong
I propose this addition. {{pd-textlogo Cyberwolf (talk) 15:48, 10 June 2025 (UTC)

This is intentional as there would be to many incorrect licensed uploads. If we could get a special mode only available for users with autopatrol rights such a mode could include tags like {{Pd-textlogo}}. GPSLeo (talk) 17:13, 10 June 2025 (UTC)

But- all logos are incorrectly liscensed as a ultimate result. We are actually in violation of copyright laws by letting people upload stuff under cc as they have no right to set a liscense. I estimate 70% of logos are liscensed wrong. So I don’t think the intentional effect even work to the extent I see it, it increases mis Liscensed images Cyberwolf (talk) 22:22, 11 June 2025 (UTC)

Is there a summary of all filters that run on commons?

I am a staff member of Wikimedia Taiwan. I just found out that PDF files uploaded by new accounts will be rejected by the filter when I was conducting a workshop last Sunday. Fortunately, this only reduced the results of the workshop I had planned by half. If my only goal was contribution on Commons, nothing would be accomplished that day. There was no way I was aware of this filter when planning the course because my account no longer triggers it.

I know the filter rules can't be made public, which would allow people to bypass him. But is it possible to get some summary so that organizers can avoid this situation? Reke (talk) 23:26, 10 June 2025 (UTC)

@Reke: I believe you should be able to see all public information at Special:AbuseFilter. Let me know if that doesn't work.

By the way, as a staff member with a reasonable amount of on-wiki activity, you can almost certainly request and receive autopatroller rights (Commons:Requests for rights#Autopatrol). I'm sure in that circumstance we'd waive the usual minimum number of edits. - Jmabel ! talk 00:18, 11 June 2025 (UTC)

Thank you. I could upload pdf file without problem, get autopatroller rights for me is helpless for the workshop. I was successful when I demonstrated it, but all the students who had just registered successfully on site were blocked by the filter at the last step. Reke (talk) 05:30, 11 June 2025 (UTC)

May I ask what you're doing in the workshop which involves uploading PDFs? Use of this file type on Commons should generally be pretty uncommon. Omphalographer (talk) 00:19, 11 June 2025 (UTC)

If File:臺灣府署並建迎暉閣景賢舫圖說.pdf (from "last sunday") is an indication, maybe some documents from public archives? Regards, Grand-Duc (talk) 00:58, 11 June 2025 (UTC)

w:Wikisource commonly uses pdf-files and about 5% of Commons files are pdfs. In terms of number of files it is not so common than jpg, but it is more common than svg or png. --Zache (talk) 02:53, 11 June 2025 (UTC)

Perhaps I misspoke. We've certainly got PDF files, but the vast majority of them are uploaded en masse by a very small number of users - most users will never upload a PDF. Omphalographer (talk) 03:16, 11 June 2025 (UTC)

@Grand-Duc Thank you. Yes, the file is a part of all document we plan to upload.

I agree that PDF files is not common style. However, the museum that provided these files originally used this format to digitize the document. After this experience, when I hold another similar workshops in the future, I will convert PDFs into JPGs first. But I have to know in advance what filters are there, otherwise my account permissions won't trigger them. Reke (talk) 05:54, 11 June 2025 (UTC)

Please don't - the correct file format for text pages is PDF (or, better, djvu). not jpg. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:47, 14 June 2025 (UTC)

People attending chapter-arranged workshop are not "most users". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:46, 14 June 2025 (UTC)

Unless they upload en mass a whole book and more in png or jpg Cyberwolf (talk) 11:01, 12 June 2025 (UTC)

It is generally advised to let people create their accounts before the workshop that they are autoconfirmed during the workshop or if not possible just request confirmed rights for participants. GPSLeo (talk) 05:05, 11 June 2025 (UTC)

This can be difficult for some events. My event was held in Penghu, an island off the coast of Taiwan. Some participants are older and lack the skills to use 3C products. They need to operate immediately after watching the demonstration before they know how to register an account.

If this is a collaboration with a university, I wouldn’t worry about this issue because, in addition to asking students to pre-register for an account, even if they run into problems, I can help them apply for permissions after the demonstration course, allowing them to complete the work from memory in subsequent courses. But for the participants of this workshop, they won't have the next step if they don't complete the work on that day. Reke (talk) 05:41, 11 June 2025 (UTC)

Then you need to request confirmed rights. As we soon get an event organizer user group anyway I will propose that this group also gets the right to grant confirmed rights to users. I also stated creating a list of the filtered actions: Commons:User access levels#Specific actions. GPSLeo (talk) 06:43, 11 June 2025 (UTC)

Creating a Copyright Template for the Federal Reserve Bank of Saint Louis

Following several discussions and Deletion requests/Undeletion requests (Two main discussions/DRs: 1, 2), it has been determined that graphs and charts made by company the Federal Reserve Bank of Saint Louis (FRED) are all in the public domain, and that FRED’s Legal Page, which states, “You can do a lot of things with FRED data, graphs, maps, software, and mobile apps for your own personal, non-commercial use…Series with a copyright notice are owned by third parties and have special restrictions. Before using data with a copyright notice for anything other than your own personal use, you must contact the data owner to obtain permission. Unfortunately, the Federal Reserve Bank of St. Louis cannot give you such permission.” (bolding all done by FRED), is in fact, an invalid legal statement for their charts/graphs.

As such, I am proposing the creation of either a stand-alone licensing template, to help editors and uploaders understand the decisions made from these discussions regarding FRED’s invalid legal disclaimer. In my opinion, this would be much nicer and more beneficial than slapping a generic {{PD-chart}} (or as some have, an invalid {{PD-USGov}}) as the licensing template for a website with numerous images on the Commons. Pings for the users involved in those discussions: @Josve05a, @Jameslwoodward, @Abzeronow, @Ymblanter. WeatherWriter (talk) 13:55, 12 June 2025 (UTC)

I would support creating a new template {{PD-Federal Reserve Chart}} that explained that while the FED can create copyrighted material because it is independent of the Federal Government, time series charts rarely can have a copyright as they are almost always created by a computer and in most cases the underlying data are facts that cannot have a copyright. I would not support a template that did not limit itself to charts. Perhaps:

While the United States Federal Reserve System can create copyrighted material and claims copyright in this chart, the underlying data are facts that cannot have a copyright and the chart itself is almost certainly created by a computer and therefore cannot have a copyright. Even if created by hand, there is no creativity in plotting a time series.

.     Jim . . . (Jameslwoodward) (talk to me) 14:03, 12 June 2025 (UTC)

Small note, the template should actually be {{PD-Federal-Reserve}} or just {{PD-FRED}}, given all the images in question come from the Federal Reserve Bank of St. Louis. WeatherWriter (talk) 14:21, 12 June 2025 (UTC)

I don't see how this needs its own template. If the underlying argument is that these images are ineligible for copyright because they are charts with no creative content, {{PD-chart}} seems to cover the matter adequately. Omphalographer (talk) 19:12, 12 June 2025 (UTC)

Deemed approval of proposals

There are many proposals with very low discussion and voting participation. We currently do not have a clear guideline if these proposals are considered as accepted or not. I therefore suggest that we introduce a deemed approval policy: If there is no opposition against a proposal it is considered approved after a given time. The steps needed would be the following:

1. There is no opposition against the proposal indicated by an  Oppose mark.
2. The last comment on the proposal section was 14 days ago.
3. After the 14 days there is a "deemed approval warning" to be posted on the Commons:Village pump.
4. If there is no opposition after 7 more days the proposal is considered accepted.

GPSLeo (talk) 15:11, 12 June 2025 (UTC)

Lean toward oppose. There needs to be some support! I don't think a proposal that simply gets no attention at all should automatically be adopted.

Also, two questions to GPSLeo:

1. if your proposal were adopted, would my comment here be considered as not opposing because I didn't use the {{O}} template?
2. what if someone responds with a comment requesting a clarification, and the original poster ignores it? Does that not put things on hold unless someone overtly opposes? - Jmabel ! talk 18:41, 12 June 2025 (UTC)

For the first point I would suggest that user has to be asked if this should be considered as a veto against a deemed approval or not. Same for the second: The user with the question should be asked if this should be considered as opposing as long as the question is not answered. If the proposer and the user who had the question do not react I would consider this a dead proposal if there are no other users supporting it and not even the proposer reacts to comments. GPSLeo (talk) 19:56, 12 June 2025 (UTC)

•  Oppose. Policy? Why not a deemed denied policy? A proposal with little participation does not sound like something that should get automatic approval. Foundationally, deemed approval is dubious. We do not want involved parties closing a discussion; this lets involved parties do that. What about proposals that have been shot down in the past but are ignored today? Is this an opportunity for forum shopping? What about technical proposals that may have implications that few understand? If a proposal does not find good traction, then it should just fade away. Glrx (talk) 14:13, 14 June 2025 (UTC)

 Support. The de facto situation is that it seemed that only Admins were allowed to approve, and all active Admins were allowing many sections to just wither on the vine. In parliamentary proceedings, proposals sometimes start with "without objection ...", perhaps we could consider that here, with one "support" considered as "seconded".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:05, 14 June 2025 (UTC)

I would take lack of response as "not sure". Why not have a small scale trial when there is no substantial reaction? A trial might provide some data for people to discuss about. By trial, I mean something like "let's try holding this event just one time at a limited scale" or "let's try applying this rule for the next 2 weeks", without making it a done deal. whym (talk) 00:54, 15 June 2025 (UTC)

I've always understood a lack of response as tacit approval. Otherwise nothing could be done on here due to the inherently low participation with most discussions. But to me, if no one disapproves of something then it should be treated the same as approval. --Adamant1 (talk) 20:49, 15 June 2025 (UTC)