Commons:Village pump/Proposals/Archive/2025/01

Upload of preview images for existing svg files

If we'd allow the original uploader of an SVG file to provide manually generated reference preview png files we'd have a number of advantages:

1. The uploader could provide resolutions optimized for the purpose the SVG file was designed for.
2. The reference preview could show how rsvg-convert should have rendered the SVG file in case of unexpected problems. If it's the uploaders fault, we, the comunity could give helpful hints. Otherwise we could suggest workarounds or find an admin who might solve the problem.
3. The reference preview could reveal how the user agent (firefox e. g.) should render the SVG file. In case of differences the user might recognize the necessity to install a given font (listed in meta:SVG fonts) to have his user agent render the file the intended way.
4. The file might probably be used for its purpose in WP e.g. in spite of rendering problems with rsvg-convert.

Current example: I just uploaded file:Arab Wikimedia SVG fonts.svg. It started with <svg version="1.1" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" width="210mm" height="594mm" viewBox="0 0 3535 9999">. Client side rendering allows printing this file on 2 pages A4 with perfectly rendered characters. It was impossible though to have an automatic generated preview file with even a single character being readable. I had to change the attributes to <svg ... width="3535" height="9999" viewBox="0 0 3535 9999">. But now the informations on intended image and font sizes are gone. Vollbracht (talk) 00:58, 4 January 2025 (UTC)

•  Oppose. SVG intends to be scalable (i.e., no fixed size), so the notion of fixed or minimum sizes is counter to the intent. In general, SVG does not scale fonts linearly. Text that is a few pixels high will not be readable. Furthermore, font specifications and substitutions are problematic. SVG files that use text elements should expect font substitutions rather than exact rendering. Setting width and height is also problematic: do you want to specify a fixed size, do you want the image to fill its designated container, or do you want to be able to pan/zoom in that container? SVG also does not have the notion of a "page". Glrx (talk) 01:31, 4 January 2025 (UTC)

  SVG intends to stay in high quality when scaling. It's not limited to presentations that are size independent or tied to specific output media. SVG allows drawing a ruler that in original size has correct dimensions when printed or shown on a correctly installed monitor. Sometimes I want to pan/zoom my container. Sometimes I don't. SVG allows both (even scaling one axis only).

  And how does SVG scale fonts if not linearly?. What is pixels but a unit of measurement based on 96 dpi monitors? And, yes, SVG files that use text elements should expect font substitutions but within limits.

  My problem in the current example was that rsvg-convert took my mm information as based on 96dpi monitors as well. But per definition they are to be applied to different output media. So ideally preview images should have been generated for hor. 220 dots in total (for WP-thumb), 96dpi (for classic low res. monitors) and at least 300 dpi (for low res. laser printers). Vollbracht (talk) 02:42, 4 January 2025 (UTC)

 Oppose, mostly. Providing a preview at upload time of how Wikimedia's servers will render an SVG (and a warning if it fails to render) is a good idea, and one which I think should be followed up on. But allowing uploaders to override that preview with a custom image is not viable - it'd inevitably lead to situations where there's mismatches between SVG content and its previews, especially as files are updated. If you're unhappy with how an SVG is rendered, change the SVG to render properly, or file a bug if something is unambiguously wrong. Omphalographer (talk) 02:36, 4 January 2025 (UTC)

Yes! Mismatches between custom preview and updated SVG files are a problem. So in most cases we will avoid that rather than accepting such problems. But at least in some cases a solution could be defining a custom set of preview resolution definitions. By what chance do we have such a possibility sometime in the future? Vollbracht (talk) 02:53, 4 January 2025 (UTC)

What are you trying to accomplish, precisely? MediaWiki generates image thumbnails on demand - the set of resolutions listed on the file page is just a couple of guesses at sizes that users might want to look at, not the sum total of all sizes that can be generated. Omphalographer (talk) 03:30, 4 January 2025 (UTC)

The user provided an example for the problem and proposed a solution. It seems to me that them was perfectly clear about what them is "trying to accomplish". The MediaWiki software is faulty WRT SVG, and them proposes a fine workaround, that can be adopted immediatly, while the SVG problam has been there for many years and is probably to stay for many more years. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:00, 4 January 2025 (UTC)

Bø

Happy new year folks! "Caregory:Bø, Midt-Telemark" should be merged with "Category:Bø i Telemark", because it is the same city. Tollef Salemann (talk) 23:12, 4 January 2025 (UTC)

Some of pictures in "Bø, Telemark" refer to the former municipality, but the rest is just the city. Not sure what to do with some of it and what is the easiest way to solve it. Maps are of the municipality, but most of the stuff is the city and people from the city. Tollef Salemann (talk) 23:15, 4 January 2025 (UTC)

Disable the ability to nominate images with VRT permission for deletion or report them as copyright violations

I think the title is pretty self explanatory. Every once in a while someone an image that VRT permission for deletion based on copyright grounds. I've done it a few times myself. It always seems to just piss people off, but who can blame anyone for doing it when they are given the option. I've read through the guidelines and other related pages though and there doesn't seem to be a legitimate reason to nominate files with VRT permission for deletion. At least not from what I can find. It doesn't seem like VRT permission in general can even be challenged or questioned. It's not like pages can't already be locked for other reasons either. So nominating images with VRT permission for deletion or as copyright violations just shouldn't be an option to begin with. Adamant1 (talk) 21:49, 28 January 2025 (UTC)

 Oppose. VRT can make mistakes, and they don't make any determinations on whether files are in scope. Omphalographer (talk) 23:04, 28 January 2025 (UTC)

@Omphalographer: Wouldn't the solution in that case be to message someone from the VRT team about it so they can with it then? I don't think regular users should be nominating files for deletion because they think the VRT team screwed up when they don't have access to the same information they do. At least not without talking to someone from the team first, but at that point they can just delete it on there end if there's actually an issue with the permission. --Adamant1 (talk) 23:57, 28 January 2025 (UTC)

As a concrete example: a user can upload an advertisement to Commons and send permission to VRT, who will duly tag it as having permission. This should not obstruct Commons users from nominating that image for deletion because it is an advertisement. Omphalographer (talk) 02:02, 29 January 2025 (UTC)

 Strong oppose it saves lots of time. i use Help:VFC for "no permission" button(you get it). when there is so many files to prove they are actually copyvios, that option really helps. just mark it! "i think author should contact VRT". this is not a bad thing. if a person decides to upload it here, he already should know how to keep it on screen. actually i dont care if user dont know or cant read COM:VRT. modern_primat ^{ඞඞඞ ----TALK} 02:41, 29 January 2025 (UTC)

No offense, but I think your confused about what I'm proposing here. I'm not proposing that people shouldn't be able to mark files that don't have permission. I'm proposing people shouldn't be able to nominate files that already have VRT permission for deletion due to copyright concerns. Files with VRT permission already have permission, that's literally what VRT permission is and the files obviously aren't COPYVIO. Again, because of the VRT permission. Maybe chill and actually read the proposal next time. --Adamant1 (talk) 02:57, 29 January 2025 (UTC)

sorry, it was 5 am there. i was sleepy.

still, people have the right to nominate files despite files got permission. modern_primat ^{ඞඞඞ ----TALK} 16:24, 29 January 2025 (UTC)

 Oppose - We've deleted plenty of files with VRT permission for being out of scope or as outright spam, per Omphalographer. I do think that anything with a VRT ticket should go through regular DR instead of speedy if the concern is copyright, but that's easily solved by the admin hitting the button to convert the speedy to a DR in the very rare cases that someone tags a VRT'd file as a copyvio. The Squirrel Conspiracy (talk) 03:14, 29 January 2025 (UTC)

 Oppose though I would agree they should never be speedy-deleted on copyright grounds. Still, VRT are capable of completely missing the point of what is problematic about a particular file (e.g. an issue of lack of FoP that didn't cross their mind when a photographer gave an otherwise valid permission). The regular deletion process should always give enough time to loop back to VRT if needed. - Jmabel 05:39, 29 January 2025 (UTC)

@Jmabel: One of the people who voted for to be topic banned from ANU did so because I had nominated some files for deletion a few months ago that had VRT permission based on scope grounds, which they had a problem with. I don't really care either way, but if people are just going to be attacked, threatened and/or sanctioned because they nominated a file that has VRT permission for deletion based on scope issues then they just shouldn't be able to do it to begin with. There was also that whole row Yann and Rosenzweig got into over the studio Harcourt files, which probably could have been resolved by simply asking the VRT team about it to begin with instead of doing mass DRs.

No offense, but you guys just default to whomever throws the biggest tantrum about something in any given instance. I don't even disagree that VRT are capable of completely missing the point of what is problematic. I just don't think to deal with it should then be put on regular users who will just be attacked and bullied for someone else's mistake. The VRT team is more then capable of dealing with their own problems, or at least they should be. --Adamant1 (talk) 16:00, 29 January 2025 (UTC)

 Oppose No problem shown. Please provide examples. --Krd 06:45, 29 January 2025 (UTC)

@Krd: Commons:Deletion requests/Files in Category:Photographs by Studio Harcourt from sources which claim they are under a free license. A lot of the images in that and several other DRs related to Studio Harcourt have VRT permission. Yann and Rosenzweig got in a tiff over the whole thing and multiple users attacked Rosenzweig for questioning the VRT permission. --Adamant1 (talk) 15:50, 29 January 2025 (UTC)

The images in the mentioned DR do not have ticket permission. I cannot say what exactly is in the ticket, as I cannot read the language, but it's no permissnio, as the "VRT info" template is used (which in my opinion should be deleted because it causes nothing but confusion). Krd 16:02, 29 January 2025 (UTC)

@Krd: Fair enough. Thanks for looking into it at least. --Adamant1 (talk) 05:04, 30 January 2025 (UTC)

•  Oppose A single file may involve 1/ several copyrights (e.g. in case of derivative work) 2/ potential out of scope issues 3/ privacy rights issues. All this implying that a VRT permission, although partially valid, may be not sufficient to resolve all the problems. Everyone should have the ability to raise a previously unnoticed issue, and therefore to open a DR if necessary. Christian Ferrer ^(talk) 09:14, 29 January 2025 (UTC)
•  Oppose. Sometimes VRT is for the derivative work and not the underlying copyright. Second out of scope and advertising concerns. Glrx (talk) 17:38, 29 January 2025 (UTC)

I think we can considered this closed on a Snowball basis. - Jmabel ! talk 04:04, 30 January 2025 (UTC)

@Jmabel: Be my guest and close it if you want to. --Adamant1 (talk) 05:08, 30 January 2025 (UTC)

This section was archived on a request by: Jmabel ! talk 19:00, 30 January 2025 (UTC)

Restrict administrators from blocking or sanctioning users in certain instances

I'm not going to point fingers but there's been multiple instances over the last couple of years where I've seen administrators block people in cases where they we're clearly involved in a dispute with the user at the time and/or had very little participation in the project to begin with. Probably in the second instance it was because their canvased off site. Which should never be acceptable. So I'm proposing two things here.

1. An administrator should not be able to block or sanction a user that they are clearly involved in a personal dispute with at the time.

2. Administrator's who have little or no participation in the project should not be doing "drive by" blocks or sanctions, period.

Nor should an administrator who meets either criteria be able to deny an unblock request.

In both cases the block, sanction, or denial of an unblock request should be reversed as invalid. There's absolutely no instance where an administrator should be able to block someone to win an editing dispute or do so as a way to prove a point because they don't like the user or how they communicate. Let alone should an administrator who only superficially participates in the project be able to block or sanction people. There's enough well established, uninvolved administrators to block or sanction a user if their behavior is actually that much of an issue. Adamant1 (talk) 08:30, 9 January 2025 (UTC)

 Oppose There's clearly a specific incident that you see as a problem. If that's the case, you should go to Commons:Administrators' noticeboard and ask for a review of that specific administrator's actions. This proposal, as written, is a) too vague to be enforceable (what constitutes "involved" and "little participation"?), and b) already reflects community norms (if an admin is blocking someone to "win" a personal dispute, that's already a problem, hence me suggesting you go to COM:AN). The Squirrel Conspiracy (talk) 08:46, 9 January 2025 (UTC)

@The Squirrel Conspiracy: It shouldn't be that hard to figure out when an administrator blocked a user to get their way in a personal dispute. It's not that vague of a word. Also, you can say it's already a problem, but it happens pretty frequently on here and it's never reverted because people play defense for the admin or act like the user is making excuses for their behavior. There's no reason the block would be reverted if there's no guideline saying it's not acceptable anyway. By "little participation" I mean an administrator who has only made a few edits in the last year and/or has very little experience with the project outside of that issue. Again, it shouldn't be that hard to determine if an administrator is established here or not. Just look at their edit history. If it's essentially non-exiting and their clearly here just to block the user, but not do any other editing, then they aren't established enough. It's not that complicated. --Adamant1 (talk) 09:34, 9 January 2025 (UTC)

i would give weak support to this. but i agree with squirrel. modern_primat ^{ඞඞඞ ----TALK} 14:12, 9 January 2025 (UTC)

and also any admin should not give block to the user who get (personal)trouble with him in the past. that admin should just report him in com:an/u. modern_primat ^{ඞඞඞ ----TALK} 14:15, 9 January 2025 (UTC)

 Oppose. Admins are already elected partially due to their activity. Admins who are inactive are already automatically removed, and we already have deadminship procedures. Specific Admin actions may already be addressed at COM:AN.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:47, 9 January 2025 (UTC)

@Jeff G.: If this stuff already isn't acceptable why not make it a part of Commons:Blocking policy then? Seriously, if the proposal already reflects community norms then what's the difference if it's part of the blocking policy? --Adamant1 (talk) 10:06, 9 January 2025 (UTC)

I think it could be added somehow but not with the strict wording you proposed. Most blocks by involved admins are emergency blocks to stop ongoing harassment or edit wars. Such blocks need to be allowed as we do not have enough admins to always get a second opinion within a very short time. For unblocks we already have an uninvolved admin guideline. I think we should make the inactivity guidelines a bit more strict that the technical number of admins gets closer to the number of really available admins. GPSLeo (talk) 12:07, 9 January 2025 (UTC)

You make a fair point. I'm not necessarily looking to keep admins from being able to do blocks in cases of edit waring or harassment. So I don't have an issue with the specific wording being loosened or otherwise modified this is approved. Usually proposals are rough drafts of the final wording in the guideline anyway. Now that you mention it though the "drive by" blocking could probably be solved by just making the inactivity guidelines a little more strict. I don't have an issue with doing that either. --Adamant1 (talk) 12:22, 9 January 2025 (UTC)

 Oppose When I give a warning to an ill-behaved user, there's about a one-in-five chance that they then attack me. There is no way in the world that should disqualify me from blocking them because they have created a "conflict" or "dispute" with me.

On the other point: if someone has qualified as an admin, the community has decided that they generally trust this person's judgment. If they are now less active on Commons, that doesn't mean their judgment has deteriorated. I'm not terribly active on en-wiki, where I remain an admin. I still would have no hesitancy to block someone there if I ran across something egregious. - Jmabel ! talk 17:46, 9 January 2025 (UTC)

I will add, though: there is a problem with certain admins using a block when they are in a content dispute with someone, something where a block should never have entered the picture. At most, they should have brought that to COM:AN/U and let someone else make a decision. If some admin has a pattern of doing that repeatedly, someone should make the case to have them de-admin'd. But the problem isn't that they blocked someone they were in conflict with, the problem is that they blocked someone because they were in conflict with them. - Jmabel ! talk 17:51, 9 January 2025 (UTC)

@Jmabel: The problem is that someone who's blocked inherently can't take it to ANU. Then you end up with situations like what happened with Enhancing999 where he stopped contributing because his complaints after the fact weren't taken seriously. I've ran into similar situations myself. The fact is that it's much harder (if not impossible) to deal with a bad block after the person is unblocked. You can't call foul while blocked either because admins just play defense for each other and reject unblock requests by default regardless of the actual merits. So involved blocks just shouldn't happen to begin with. It's certainly not something that's worth losing otherwise productive editors over. --Adamant1 (talk) 22:50, 9 January 2025 (UTC)

Clearly, the person who has been blocked can't take it to AN/U, at least not for the duration of the block. The point is that someone else who sees a pattern of abuse by an administrator can.

@Adamant1: unless I'm mistaken, you've been banned from bringing issues to AN/U yourself, because it was perceived that you abused that. (Correct me if I am wrong about the ban.) I think that you are skating on thin ice here discussing particular AN/U cases here. I was going to let it slide because your initial proposal made a point of not singling anyone out, but now you have.

Since you bring up that specific case, I will briefly address it here but, again, I'd prefer you drop the matter for the reasons just stated. The only time User:Enhancing999 has ever been blocked, they were blocked for a week. I see nothing wrong with the process. There was a broad consensus to block. An uninvolved administrator. Taivo came in and decided the length of the block, and decided precisely that only this short block was in order. Frankly, Taivo may have been doing Enhancing999 a relative favor: someone else might have blocked them a lot longer. There was certainly nothing wrong with him coming in, sizing up the discussion, and making a determination. That is a lot of what admins constantly do on DRs and the like. It is no less appropriate on AN/U. - Jmabel ! talk 23:08, 9 January 2025 (UTC)

@Jmabel: I specifically avoided mentioning ANU in the original proposal and none of the instances that I have in mind specifically inolve ANU. I'm not topic banned from discussing administrator behavior in general either and if an administrator blocks someone that their in a dispute with it inherently doesn't involve ANU. THATS THE PROBLEM!!!!! So I don't see what the issue with this proposal is in that regard. The same goes for me refering to ANU in an off hand way. Correct me if I'm wrong, but it's not a violation of a topic to say ANU isn't the appropriate way to deal with something if someone else brings it up.

With User:Enhancing999 my issue is purely with how it was handled on his talk page after he was blocked. I don't care about, nor was I involved in the ANU complaint. But it's not an ANU issue at that point as far as I'm concerned. Say it is though, cool. Then I'll purely speak about my own experiences. At least in my experience I was blocked by a clearly involved admin (again, in a way that didn't involve ANU what-so-ever) and there wasn't any way to deal with it either at the time or after the fact. But apparently I should just accept that and not talk about it because I was topic banned from ANU a year later. Even though again, it had absolutely nothing to do ANU. Right. --Adamant1 (talk) 23:22, 9 January 2025 (UTC)

@Adamant1, I'm not involved, and I'm not an admin, but I can warn you to be extremely careful when dealing with you topic ban. @Jmabel has been incredibly patient and mellow with you, but you are reaching the end of the ROPE. Be careful with what you say next, and I would recommend taking a walk after writing your next post, but before posting it. All the Best -- Chuck ^Talk 01:02, 10 January 2025 (UTC)

I don't have anything else to say about it. The fact is that there isn't and never will be even the most basic standards for how admins behave or use their privileges on here. I have a right to say that something has absolutely nothing what-so-ever to do with ANU on my end if someone claims I'm violating the topic ban in the meantime though. I didn't say crap about ANU and I'm not responsible for what other people decide to talk about. Have fun shotting the messanger though. Its impossible to discuss anything on here from a general perspective without it turning personal.

No other website deals with problems in the same super pedantic, needlessly personal way that things are constantly discussed on here. There's been a ton of discussions over the years about admins unilaterally using their privileges to push their own personal opinions or way of doing things. Nothing is ever done about it though because this is exactly how every single conversation goes. All I'm asking for here is for there to be minor, basic standards for when admins are allowed to unilaterally block someone. But lets not do that even though its clearly a problem and leading people to not contribute to the website just because I'm topic banned from an unrelated area that has absolutely nothing to do with this. Adamant1 (talk) 01:41, 10 January 2025 (UTC)

BTW with Enhancing999, I had gotten into it with him over the exact same thing that he was blocked for a couple of days before he was blocked. Its absolutely within my right to discuss something that I was involved in and its not my problem that other people decided to escalate things or take it to a different forum after that. My bad for mentioning a conflict that I was personally involved though. I wasn't aware it would be such a big no no. --Adamant1 (talk) 01:48, 10 January 2025 (UTC)

I'm not trying to tell you to stop talking about that issue, I just don't want you to get blocked. Friends don't let friends get sanctioned, as Barkeep49 put it. All the Best -- Chuck ^Talk 04:49, 10 January 2025 (UTC)

OK. Fair enough. --Adamant1 (talk) 05:07, 10 January 2025 (UTC)

Require VRT permission from nude models

There are currently many cases of nude models requesting the deletion of photos where they are visible. We do not have a clear policy how to handle such cases and every solution has problems. I want to propose a new process to minimize this problem for future uploads.

I would propose a new guideline like the following:

"Photos of nude people need explicit permission from the model verified through the VRT process. This applies to photos of primary genitalia and photos of identifiable people in sexually explicit/erotic poses also if only partial nude. This also applies to photos form external sources with an exception for trustworthy medical journals or similar. This does not apply to public nudity at protests, fairs and shows where photographing was allowed. For photos of such events only the regular rules on photos of identifiable people apply. This applies to all photos uploaded after Date X. Within the process the people are reminded that the permission is irrevocable. Having such permission does not automatically put the photo within the scope."

As I think that would not be more than a hand full of cases per month I think this could be handled by the VRT team. If this new task is a problem for the VRT we could also ask if the T&S team could help in this sensitive area. GPSLeo (talk) 10:09, 11 January 2025 (UTC)

I thought the GDPR right "to be forgotten" makes a "irrevocable" model release impossible? What would such a guideline mean for fotos from pride parades? At pride parade there are regularly people with visible primary genitalia. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 11:33, 11 January 2025 (UTC)

I think there is no higher court decision on "model contract" vs. "right to be forgotten" but I would assume that the model contract is the superior right. If otherwise we would already have cases of known movies where some actors got themself removed from the movie. I will add a sentence on public nudity. I had this in mind but then forgot it when writing the draft. GPSLeo (talk) 11:41, 11 January 2025 (UTC)

Before putting new tasks on the VRT, please consider to speak with the VRT. Their current policy is not to process any personality rights releases, which also included model contacts, not least because they are unable to reasonably verify such releases. --Krd 11:50, 11 January 2025 (UTC)

I am aware that this is often more complicated than for copyright. But I think it is better to make a "delete if not verified policy" instead of keep everything and handle all the removal requests they also require identity confirmation. GPSLeo (talk) 12:07, 11 January 2025 (UTC)

How many removal requests have there been in the last 2 years? Krd 12:29, 11 January 2025 (UTC)

I do not know how many cases were handled privately by VRT and Oversight but for the cases starting as regular deletion requests I would estimate around ten to twenty cases in the last two years. GPSLeo (talk) 12:55, 11 January 2025 (UTC)

No offence, but can we make sure we are addressing a problem, and not a non-problem, before we make such expensive approach? I for sure don't see all such VRT requests, but I think I see at least half of them, and I have no memory of any relevant issue. If they happen, they are mostly such cases where consent initially was given and is going to be revoked later, which is a situation other addressed by the proposal.

Who is going to ask the oversighters, so that we know what we are talking about? Krd 17:26, 11 January 2025 (UTC)

The proposal seems sensible to me, as long as the VRT would be actually willing to handle such permissions, see Krd's comment. I would, however, add something exempting historical photographs too (for example, the photographs in Category:19th-century photographs of nude people), or photographs of now deceased people in general (photos taken when the person was alive). In Switzerland, for example, the "right to one's own picture" (Recht am eigenen Bild) basically ends with death, see de:Recht am eigenen Bild (Schweiz) and can't be claimed by family members; in Germany, family members can claim it for up to 10 years after the person's death (per de:Postmortales Persönlichkeitsrecht). Gestumblindi (talk) 14:41, 11 January 2025 (UTC)

I’d say if a nude model legitimately requests their picture be taken down, we just take it down; requiring VRT for each and every non-historical, non-nudist, non-self-shot photo of a nude person seems tedious and unnecessary. 10-20 cases is a non-trivial amount, but I’d think it’s a pretty small percentage of all the nude photography we host here. Dronebogus (talk) 15:24, 11 January 2025 (UTC)

i agree. modern_primat ^{ඞඞඞ ----TALK} 16:48, 11 January 2025 (UTC)

Something like this may be reasonable, but the considerations raised by User:Gestumblindi and User:Dronebogus are relevant. To list three exceptions I see:

• Historical photos, especially photos that were routinely published in their own era and whose copyrights have now expired. E.g. I cannot imagine doubting appropriate consent on a nude photo of actress Louise Brooks.
• Photos from societies and cultures where what is in the West considered "nudity" is simply considered normal (e.g. places in Africa or Pacific Islands where women do not routinely cover their breasts).
• Photos taken at public events in countries where appearing in public is de facto consent for photography. E.g. the many people who appear naked at the Folsom Street Fair, or Fremont Solstice Parade, or Mardi Gras in New Orleans. It is not practical to get VRT from a person walking by in a parade, nor do I see any need to do so in a situation where they have no legal expectation of privacy.

I would not be surprised if there are other equally strong cases for exceptions. - Jmabel ! talk 19:50, 11 January 2025 (UTC)

Yes, the part for historical photos should definitely be added and defined in a very broad sense (all photos older then 25? years). The second point is the reason why I made the complicated definition to exclude female breasts in non sexual contexts from the guideline. GPSLeo (talk) 20:37, 11 January 2025 (UTC)

The proposal was about primary genitalia. Now you introduce secondary gender specific body parts like breasts or a beard. There are societies that forbid a man to show a shaven face. Should we also require VRT permission for images of iranien or afghan men without a beard? C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 23:10, 11 January 2025 (UTC)

• The proposal would create very big issues (increase in work for VRT, increase of DRs towards nude pictures) to potentially solve very few (almost non-existent) issues. Christian Ferrer ^(talk) 08:41, 12 January 2025 (UTC)
•  Oppose A solution in search of a problem. The Squirrel Conspiracy (talk) 11:28, 12 January 2025 (UTC)

 Comment I'm very active in VRT and I've never see a case like this -nude models requesting the deletion of photos where they are visible-. I think we can handle it when the moment arrives. --Ganímedes (talk) 22:49, 12 January 2025 (UTC)

•  Oppose Unneeded and would cause a increase in deletion requests and a increase in work for VRT Isla (talk) 23:08, 14 January 2025 (UTC)

•  Support Assuming Jmabel's suggestions are implemented if it passes. Regardless, this seems like a reasonable proposal and I don't really think the arguments against it are compelling. God forbid the VRT team has to do a couple of more VRT permissions every now and then. --Adamant1 (talk) 03:16, 16 January 2025 (UTC)

  It's not about workload; the comment above was "Their current policy is not to process any personality rights releases, which also included model contacts, not least because they are unable to reasonably verify such releases." Unless this issue is adequately addressed, the proposal is a non-starter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:12, 16 January 2025 (UTC)

Fair enough. I must have missed that. I agree the proposal is probably a non-starter if its not worked out though. --Adamant1 (talk) 13:29, 16 January 2025 (UTC)

If we see a need for something we are currently not able to do we have to show this to get support from the WMF. The WMF will only help us finding a solution if there is a consensus in the community that there is need for this. We need the community decision that there is a need before we can talk about finding solutions. GPSLeo (talk) 13:41, 16 January 2025 (UTC)

 Oppose mandatory VRT permission. My proposal is: if a model makes a legitimate request to remove an image, we remove it, no questions asked. Dronebogus (talk) 18:27, 16 January 2025 (UTC)

As far as your proposal is concerned, I suspect that's more or less the case already, if someone knows who or where to ask - but I'd absolutely support a more substantial proposal to make that an official policy, and to make it better known. Omphalographer (talk) 02:41, 17 January 2025 (UTC)

Commons:Contact us/Problems mentions info-commons for issues about "Images of yourself". So in a sense, it's already handled in VRT, or at least our documentation says so.

We have 2 Commons-related community queues in VRT: info-commons mentioned in Commons:Contact us/Problems and permissions-commons described in COM:VRT. The latter page might make it look like permissions-commons=VRT, but that is not true. whym (talk) 10:32, 18 January 2025 (UTC)

•  Support with Jmabel's exceptions. Nosferattus (talk) 02:07, 21 January 2025 (UTC)

 OpposeWikibureaucracy--Trade (talk) 17:48, 25 January 2025 (UTC)

Expanding an explanation on the De-adminship policy

I would like to propose this text to expand the de-adminship policy, this text came as a result of this discussion on meta and also inspired by the current policies on English Wikipedia:

Administrators are expected to adhere strictly to the principles of respect and proper etiquette as outlined in the Universal Code of Conduct. Any administrator who repeatedly or egregiously violates these principles by engaging in disrespectful behavior, personal attacks, or actions that undermine the community's trust may have their administrative rights revoked. Administrators are accountable for their actions and must provide clear and prompt explanations when their conduct or decisions are questioned. Repeated failure to communicate, poor judgment, or misuse of administrative tools, as well as conduct incompatible with the responsibilities of the role, may result in sanctions. Such cases will be reviewed by a designated committee, which will evaluate the severity, frequency, and context of the violations, ensuring a fair and transparent process. Administrators must maintain proper account security, including using strong passwords and reporting any unauthorized access immediately, as compromised accounts may lead to immediate loss of administrative privileges. In cases where violations persist despite warnings or where the offenses are severe, the administrator’s rights may be permanently revoked to safeguard the integrity of the platform and its community. Reinstatement of administrative rights, if sought, will be subject to thorough evaluation by the committee, considering the administrator’s past actions, corrective measures taken, and the current trust of the community.

This aditional description in the current policy aims to uphold a respectful, accountable, and secure environment, ensuring that administrators act in alignment with the values and expectations of their role in our community Wilfredor (talk) 19:51, 24 January 2025 (UTC)

I think the process as it is is perfectly fine but it can be improved for sure. Clarifying that personal attacks and disrespectful behaviour is not okay seems like a good step however common sense applies. Also your proposal mentions a committee whose creation you do not elaborate further. In any case I would oppose creating a committee and leave the decision of desysopping in the hands of the community (i.e. voting). I don't mean to condone wrong behaviours but one off disrespectful comment or attack could be pardoned, the desysopping process should go for reiterative bad behaviour only. Bedivere (talk) 21:42, 24 January 2025 (UTC)

Also stating that "Administrators are expected to adhere strictly to the principles of respect and proper etiquette as outlined in the Universal Code of Conduct" is redundant since all users are expected to abide to that code of conduct, including admins for obvious reasons (it is literally verbatim) Bedivere (talk) 21:46, 24 January 2025 (UTC)

We all should keep in mind that the UCOC is the BARE MINIMUM for acceptable behavior, and we should expect admins to have a much higher standard than UCOC. All the Best -- Chuck ^Talk 21:58, 24 January 2025 (UTC)

Yeah, but the proposed wording is not stronger. I would not oppose a stronger wording at all (just fyi) Bedivere (talk) 22:14, 24 January 2025 (UTC)

@Wilfredor, Would you be willing to add a sentance into the proposed text stating that UCOC is the bare minimum, and should be well above the UCOC at all times. All the Best -- Chuck ^Talk 22:18, 24 January 2025 (UTC)

Unfortunately, this thing that seems to be obvious, I do not feel that it is being fulfilled. Wilfredor (talk) 22:48, 27 January 2025 (UTC)

Common sense isn't that common. All the Best -- Chuck ^Talk 01:32, 28 January 2025 (UTC)

It can be easily weaponized to serve personal agendas, though, so a good amount of good sense and discretion is strongly recommended when using it. Darwin ^Ahoy! 22:17, 24 January 2025 (UTC)

That's right. All I would support is stronger-wording the current policy and saying that personal attacks, poor behaviour are not accepted. But as it is now, there should be a discussion (always local) before initiating a proper desysopping voting Bedivere (talk) 22:27, 24 January 2025 (UTC)

Enable two new tools

Hi! As part of a project with User:Scann (WDU), I developed two new tools to edit Commons:

• AddFileCaption - Adds captions to the structured data of files in a given category
• AddFileDescription - Adds descriptions to the files in a given category

The tools are are already enabled in MediaWiki.org and eswiki, and we'd like to enable them in Commons too. For that, I'd need to add two new gadgets (technical details explained on the links above and here). I have the necessary permissions (I'm a global interface editor) but would like to ask the community for support, questions, ideas or concerns. Thanks! Sophivorus (talk) 13:30, 21 January 2025 (UTC)

Hi! Thanks for the mention. Just to clarify, this work was funded by Wikimedistas de Uruguay. Hope the community finds the tools useful! Scann (WDU) (talk) 13:52, 21 January 2025 (UTC)

•  Support Please them both autopatrolled only to avoid issues with SDC vandalism. All the Best -- Chuck ^Talk 19:24, 21 January 2025 (UTC)
•  Support Looks interesting. Although I agree with Alachuckthebuck that probably only autopratrollers should be able to use the gadgets. --Adamant1 (talk) 18:10, 22 January 2025 (UTC)

•  Support I don't think it needs to be autopatrolled however: these are captions and descriptions, and until it becomes a problem -- adding requirements like autopatrolled prevents it from being useful for campaigns and other newcomer activities. Like the ISA tool, the way to prevent bad behavior on SDC, is training the people using it, not limiting who can use it, Sadads (talk) 12:34, 24 January 2025 (UTC)

 Comment The tools should work the same way the ISA tool does, anyone that has an account can use it. These are not massive edits, there's no reason or purpose to limit who can use them -- they are precisely to make the Wikimedia Commons interface more intelligible and easier to use for newcomers. Scann (WDU) (talk) 12:49, 24 January 2025 (UTC)

It's usually just better to limit something new to a specific group of editors until it's been tested. That's less of an issue in this case since the tools are already in use on other projects though. --Adamant1 (talk) 12:52, 24 January 2025 (UTC)

The ISA tool is exactly an example for a tool that created lots of bad edits because people used it without reading the guidelines. GPSLeo (talk) 13:05, 24 January 2025 (UTC)

•  Support Very useful tools. As a campaign organizer I'd love to have these tools at hand to invite people to participate in new ways and engage with SDC, which is a powerful but neglected way of collaboration and engagement for new comers. That's why I think these tools should be available to everyone. The power that they potentially might give to bad actors for making vandalism, will be balanced giving anyone the chance to fix problems, and overall, to increase and improve the use of SDC. Mariana Fossatti (WK?) (talk) 16:44, 24 January 2025 (UTC)

 Done Well, I just enabled both tools, see Template:Add file caption and Template:Add file description. I also went ahead and added a "group" parameter that basically allows to limit the use of the tool to some specific group (e.g. user, autoconfirmed, autopatrolled, etc). The current default is empty (no restriction), but if vandalism starts to occur, the default can be set to some group. Hope they bring many valuable edits, cheers! Sophivorus (talk) 15:51, 31 January 2025 (UTC)

Should a "bot cleanup kit" exist?

In the last 6 months, Commons has had 2 bots have extended issues where they created tens of thousands of invalid edits.

Both times, I cleaned up the mess with massrollback and either account creator or a bot account. But it's a less than ideal solution, as I was hitting 2 thousand EPM while performing rollbacks, and these were not marked as bot edits. So my question is:

Should we create a tool/script/playbook, for doing bot cleanups? I understand bot owners are responsible for the edits made by their bots, but having dedicated tools to rapidly handle 75 thousand rollbacks without causing 5 mins of database lag would be nice. I have been asked frequently is why this can't be done slowly? The problem is that if for any reason, an affected page is edited, any error introduced by the bot can't be fixed easily, often requiring manual correction. All the Best -- Chuck ^Talk 18:30, 24 January 2025 (UTC)

We should require bot operators be able to cleanup mistakes they made with their bot. In the bot request they have to confirm that they can also revert the edits they made with the bot. If they can not guaranty this the bot can not be approved. GPSLeo (talk) 19:00, 24 January 2025 (UTC)

What GPSLeo said. Krd 04:23, 25 January 2025 (UTC)

@Krd, Seeing as you have handled most of the bot requests from the last 5 years, when does this check happen? And if a bot does mess up and make a bunch of junk edits, should we really be using the same bot to fix it? (unless we have a standardised script to do it, I don't think that's an option) All the Best -- Chuck ^Talk 04:50, 25 January 2025 (UTC)

There is no check, but it speaks for itself that if a bot operator messes up in large scale, they are responsible to at least help to clean it up, whatever it takes. Everybody who is running a real bot is able to do that. Perhaps we should consider to be more hesitant on AWB or js gagdet "bots" in the future. In order to understand the actual size problem, perhaps the 2 mentioned cases should be analyzed regarding what exactly went wrong. Krd 05:24, 25 January 2025 (UTC)

@AntiCompositeNumber was looking into the flickr goof last I heard. As to WLKbot, nothing went wrong per se , but rather the operator @Kim Bach jumped the gun on implementing something, and creating 3k categories that still need cleanup. Also, these were both full bots, not script/AWB bots. Their edits were fixed by a script. Also, @MolecularPilot updated the script, allowing for ratelimiting and marking bot edits (haven't tested the second part yet.) User:MolecularPilot/massrollback.js. Even if commons has our ducks in a row, once the tool exists and is documented, this can be used movement wide, having a much larger impact. All the Best -- Chuck ^Talk 21:42, 25 January 2025 (UTC)

Hi! The new version of massrollback supports ratelimiting (you tell it the max number of rollbacks to make in a minute) but it doesn't support marking them as bot edits if you're flagged. I'm working on this part now! :) MolecularPilot (talk) 23:03, 25 January 2025 (UTC)

Actually, it already did mark bot edits if your flagged, I forgot that I coded that part. So, yeah! :) MolecularPilot (talk) 08:42, 26 January 2025 (UTC)

Is it sufficient to use the existing mw:Manual:Pywikibot/revertbot.py? If not, what is missing? whym (talk) 12:03, 1 February 2025 (UTC)

Not all bots use pywikibot. And also, I'm not so sure a bot that just screwed up should be doing the cleanup. All the Best -- Chuck ^Talk 20:32, 1 February 2025 (UTC)

With the script linked above, you can specify the target user account whose recent edits are to be reverted. The target account doesn't need to be a Pywikibot bot, nor even a bot. whym (talk) 01:53, 2 February 2025 (UTC)

I didn't know that existed. I have user:chuckbot kicking around with pywikibot and a working backend, so I might do a bot request for that. All the Best -- Chuck ^Talk 01:57, 2 February 2025 (UTC)

RfC: Should Commons ban AI-generated images?

Should Commons policy change to disallow the uploading of AI-generated images from programs such as DALLE, Midjourney, Grok, etc per Commons:Fair use?

Background

AI generated images are a big thing lately and I think we need to address the elephant in the room: they have unclear copyright implications. We do know that in the US, AI-generated images are not copyrighted because they have no human author, but, they are still very likely considered derivative works of existing works.

AI generators use existing images and texts in their datasets and draw from those works to generate derivatives. There is no debate about that, that is how they work. There are multiple ongoing lawsuits against AI generator companies for copyright violation. According to this Washington Post article, the main defense of AI generation rests on the question of if these derivative works qualify as fair use. If they are fair use, they may be legal. If they are not fair use, they may be illegal copyright violations.

However, as far as Commons is concerned, either ruling would make AI images go against Commons policy. Per Commons:Fair use, fair use media files are not allowed on Commons. Obviously, copyright violations are not allowed either. This means that of the two possible legal decisions about AI images, both cannot be used on Commons. There is no possible scenario where AI generated images are not considered derivative in some way of copyrighted works; it's just a matter of if it's fair use or not. As such, I think that AI-generated images should be explicitly disallowed in Commons policy.

Discussion

Should Commons explicitly disallow the uploading of AI-generated images (and by proxy, should all existing files be deleted)? Please discuss below. Di (they-them) (talk) 05:00, 3 January 2025 (UTC)

Enough. It is a great waste of time to have the same discussion over and over and over. I find it absurd to think that most AI creations are going to be considered derivative works. The AI programs may fail that test, but what they produce clearly isn't. Why don't we wait until something new has happened in the legal sphere before we start this discussion all over?--Prosfilaes (talk) 06:21, 3 January 2025 (UTC)

 OpposeNo, it shouldn't and they are not derivative works and if they are uploaded by the person who prompted them they also are not fair use but PD (or maybe CCBY). They are not derived from millions of images, like images you draw are not "derived" from public works you previously saw (like movies, public exhibitions, and online art) that inspired or at least influenced you. There is no debate about that, that is how they work. False. the main defense of AI generation rests on the question of if these derivative works qualify as fair use. Also false. Prototyperspective (talk) 09:52, 3 January 2025 (UTC)

Most AI-generated images, unless the AI is explicitly told to imitate a certain work, are not "derivative works" in the sense of copyright, because the AI does a thing similar to humans when they create new works: Humans have knowledge of a lot of pre-existing works and create new works that are inspired by them. AI, too, "learns" for example what the characteristics of Impressionist art are through the input of a lot of Impressionist paintings, and is then able to create a new image in Impressionist style, without that image being a derivative work of any specific work where copyright regulations would apply - apart from the fact, of course, that in this specific example, most of the original works from the Impressionist period are public domain by now anyway. The latter would also be an argument against the proposal: Even if it were the case that AI creates nothing but "derivative works" in the sense of copyright, derivative works of public domain original art would still be absolutely fine, so this would be no argument for completely banning AI images. Having said all that, I think that we should handle the upload of AI images restrictively, allow them only selectively, and Commons:AI-generated media could be a bit stricter. But a blanket ban wouldn't be a reasonable approach, I think. Gestumblindi (talk) 11:12, 3 January 2025 (UTC)

We want images for a given purpose. It's a user who uploads such an image. He is responsible for his work. We shouldn't care how much assistance he had in the creation process. But I'd appreciate an agreement on banning photorealistic images designed for deceiving the viewer. AI empowers users to create images of public (prominent) people and have these people appear more heroic, evil, clean, dirty, important or whatever than they are. But we have this problem with photoshop already. I don't want such images in Wikimedia even if most people know a given image to be a hoax (such as those of Evil Bert from sesame street). Vollbracht (talk) 01:42, 4 January 2025 (UTC)

This discussion isn't about deception or usefulness of the images, it's about them being derivative works. Di (they-them) (talk) 02:12, 4 January 2025 (UTC)

You got the answer on "derivative works" already. I can't see a legal difference between a photoshopped image and an image altered by AI or a legal difference between a paintbrush artwork and an AI generated "artwork". Still as Germans say: "Kunst kommt von können." (Art comes from artistic abilities.) It's not worth more than the work that went into it. If you spend no more than 5 min. "manpower" in defining what the AI shall generate, you shouldn't expect to have created something worthy of any copyright protection or anything new in comparison to an underlying work of art. We don't need more rules on this. When deriving something keep the copyright in mind - no matter what tool you use. Vollbracht (talk) 03:34, 4 January 2025 (UTC)

Look at other free-upload platforms and you get to the inevitable conclusion that AI uploads will ultimately overwhelm Commons by legal issues or sheer volume. Because people. But with no new legal impulses and no cry for action from tech Commons, I see no need for a new discussion at this point. Alexpl (talk) 05:59, 4 January 2025 (UTC)

• As I understand it, there are three aspects of an AI image:

1. The creations caused by the computer algorithm. Probably not copyrighted anywhere because an algorithm is not an animal.
2. An AI prompt, entered by a human. This potentially exceeds the threshold of originality, in which case the AI output probably is a derivative work of the prompt. Maybe we need a licence of the AI prompt from the person who wrote it, unless the prompt itself is provided and determined to be below the threshold of originality.
3. Sometimes an AI image or text is a derivative work of an unknown work which the AI software found somewhere on the Internet. Here it might be better to assume good faith and only delete if an underlying work is found. --Stefan2 (talk) 11:54, 7 January 2025 (UTC)

Re 2: note that short quotes can also be put onto Wikipedia which is CCBY-SA and Wikiquote. Moreover, that applies to the prompt, but media files can also be uploaded without input prompt attached. In any case, if the prompt engineer licenses the image under CCBY or PD then it can be uploaded and I only upload these kind of AI images even if further may also be PD. Re 3: that depends on the prompt, if you're tailoring the prompt in some specific way so it produces an image like that then it may create an image looking very similar...e.g. if you prompt La Vie, 1903 painting by Pablo Picasso, in the style of Pablo Picasso, the life it's likely produce an image looking like the original. I also don't think that it would be good to assume that active contributors would without disclosing it do so. Prototyperspective (talk) 12:16, 7 January 2025 (UTC)

If you ask for La Vie, 1903 painting by Pablo Picasso, in the style of Pablo Picasso, the life, then you are very likely to get a derivative work.

If you ask for a picture of a cat, then there is no problem with #2, but you have no way of knowing how the AI tool produced the picture, so you are maybe in violation of #3 (you'll find out if the copyright holder sues you). --Stefan2 (talk) 12:53, 7 January 2025 (UTC)

•  Oppose Whatever the details of AI artwork and derivatives are, there's a serious lack of people checking for copyright violations to begin with and anyone who tries to follow any kind of standards when it comes to AI artwork just get cry bullied, threatened, and/or sanctioned for supposedly causing drama. So there's really no point in banning it or even moderating in any way what-so-ever to begin with. The more important thing is properly labeling it as such and not letting people pass AI artwork off on here as legitimate, historically accurate images. The only other alternative would be for the WMF to take a stance on it one or another, but I don't really see that happening. There's nothing that can or will be done about all the AI slop on here until then though. --Adamant1 (talk) 06:51, 9 January 2025 (UTC)

• Conditional  Support. I do not support an outright and total ban of any and all AI generated imagery (in short: AI file) on Commons, that's going too far. But I would support a strict enforcement and an strict interpretation of our scope policy in regards to such imagery. By that, I mean the following.

1. I support the concept that any upload of AI generated imagery has to satisfy the existence and demonstration of a concise and legitimate use case on Wikimedia projects before uploading the data on Commons. If any AI file is not used, then it's blanketly out of scope. Reasoning: Most Wikimedia projects have a rule of only hold verifiable information. AI files have a fundamental issue with this requirement of verifiability, as the LLM models (Large Language Models) used do not allow for a correlation between input and output. This is exemplified by the inability of the LLM creators to remove the results of rights infringing training data from the processing algorithms, they can only tweak the output to forbid the LLM outputting infringing material like song or journalistic texts.
2. I support a complete ban of AI generated imagery that depicts real-life celebrities or historical personnages. For celebrities, the training data is most likely made of copyrighted imagery, at least partly. For historical personnages, AI files will likely deceive a viewer or reader in that the AI file is historically accurate. Such a result, deceiving, is against our project scope, see COM:EDUSE.
3. I support the notion of using AI files to illustrate concepts that fall within the purview of e.g. social sciences. I could very well see a good use case to illustrate e.g. poverty, homelessness, sexuality topics and other potentially contentious themes at the discretion of the writing Wikipedian. AI files may offer the advantage in that most likely no personality rights will get touched by the depiction. For this use case, AI files would have to strictly satisfy our COM:Redundant policy: as soon as there is an actual human made media file, a photograph, movie or sound recording that actually fulfils the same purpose as the AI file, then the AI file gets blanketly out of scope.

I am aware that these opinions are quite strict and more against AI generated imagery. That's due to my background thoughts about the known limitations of generative software and a currently unclear IP right situation about the training data and the output of these LLM. I lack the imagination on how AI files could currently serve to improve the mission of disseminating knowledge, save for some limited use cases. Regards, Grand-Duc (talk) 19:07, 9 January 2025 (UTC) PS. For further reference: Commons:Deletion requests/Files in Category:AI-generated portraits.

Re 1.: some people complain that people upload images without use case, other people complain when people add useful media they created themselves to articles – it's impossible to make it right. Moreover, Commons isn't just there as a hosting site for Wikipedia & Co but also a standalone site. Your point about LLM is good and I agree but this discussion is not about LLMs but AI media creation tools.

Re 2.: paintings are also inaccurate. Images made or modified with AI (or made with AI and then edited with eg Photoshop) are not necessarily inaccurate. I'm also very concerned about the known limitations of generative software but that doesn't really support your points and doesn't support that Commons should censor images produced with a novel toolset. Prototyperspective (talk) 19:34, 9 January 2025 (UTC)

All the AI media creation tools, be it Midjourney, Grok, Dall-E and the plethora of other offerings are based upon LLM. So, any discussion about current "AI media creation tools" is the same as discussing the implications of LLM in practice, IP law and society. And yes, Commons wants to also serve other sites and usages (like school homework for my son, did so in the past and will do in the future). But as anybody may employ generative AI, there is no need to use Commons to endorse any and all potential use - as I tried to demonstrate, AI files are only seldom useful to disseminate knowledge, see Commons:Project scope.

Paintings are often idealized, yes, introducing inaccuracies. But in that case, the work is vouched for by a human artist, who employed his creativity and his knowledge based upon the learnings in his life to produce a given result. These actions cannot be duplicated at the moment by generative AI, only imitated. And while mostly educated humans will recognize a painting as a creation of a fellow human that will certainly contain inaccuracies, the stories about "alternative facts", news bubbles, deepfakes etc. show that generative AI products are often neither recognized as such and taken at face value. Regards, Grand-Duc (talk) 19:56, 9 January 2025 (UTC)

No, those are not the same implication. You however got closer to understanding the concept and basics of prompt engineering which is about getting the result you intend or imagined despite all the flaws LLMs have.
People have developed all sorts of techniques and tricks to make these tools produce the images they have in mind at a quality they'd like to have them. If you think people ask AI generator tools to illustrate a subject by just providing the concept's name like "Cosmic distance ladder" and then assuming it produces an accurate good image showing that you'd be wrong. Moreover, most AI images do look like digital art and not photos and are generally labelled as such. Prototyperspective (talk) 22:05, 9 January 2025 (UTC)

• Oppose per Prosfilaes it is not at all guaranteed that we're in a Hobson's choice here. Some AI images may well be bad, but banning them all just in case is ridiculous. --GRuban (talk) 21:53, 9 January 2025 (UTC)

•  Support with the possible exception of images that are themselves notable. Blythwood (talk) 20:22, 11 January 2025 (UTC)

Mostly support, but not for the reasons proposed. While I don't disagree with the argument that AI-generated content could potentially be considered a derivative work, this argument isn't currently supported by law, and I don't think that's likely to change in the near future. However, very few AI-generated images have realistic educational use. Generated images of real people, places, or objects are inherently inferior to actual photos of those subjects, and often contain misleading inaccuracies; images of speculative topics tend towards clichés (like holograms and blue glowing robots for predictions of the future, or ethnic stereotypes for historical subjects); and AI-generated diagrams and abstract illustrations are inevitably meaningless gibberish. The vast majority of AI-generated images inserted into Wikimedia projects are rejected by editors on those projects and subsequently deleted from Commons; those that aren't removed tend to be more the result of indifference (especially on low activity projects) than because they actually provide substantial educational value. Omphalographer (talk) 20:15, 20 January 2025 (UTC)

•  Oppose - No evidence there is actual legal risk. The U.S. Copyright office has declared many times now that A.I. generated images are not copyrighted unless they are clearly derivative works. Any case of an image being a derivative work needs to be handled on a case-by-case basis, just like any other artwork. If Commons is actually concerned about copyright issues with derivative works, we need to delete about a thousand cosplay images first. (No, I'm not saying that all cosplay images are copyrighted derivative works, but a lot of them are.) Nosferattus (talk) 02:02, 21 January 2025 (UTC)
•  Oppose if a replacement sister project is not established.  Support if a sister project like meta:Wikimedia Commons AI is introduced and AI images can be moved to that project. As I already stated in 2024, I believe that AI-generated images and human-made images should be kept separate in order to protect, preserve, defend and encourage the integrity of purely human creativity. S. Perquin (talk) 20:33, 22 January 2025 (UTC)
•  Oppose A blanket ban because "If they are fair use, they may be legal. If they are not fair use, they may be illegal copyright violations." is not accurate: as courts have already found in the United States, intellectual property such as a copyright can only be applied to a human person intentionally making a creative work, not a software process or an elephant or a hurricane in a paint store. Individual AI-generated works may well be copyright infractions, but that would be for the same reasons as if a human person made a work that was influenced by existing copyrighted works, such as being virtually identical to the source work. I am not a lawyer and nothing I write here or anywhere should be taken as any kind of proper financial, legal, or medical advice. —Justin (koavf)❤T☮C☺M☯ 22:54, 22 January 2025 (UTC)
• A blanket ban for copyright reasons would likely encompass a number of uses that would not violate copyright. If this is unwarranted, there may be smaller categories that are more reasonable to consider per Commons:PRECAUTIONARY. For example, AI images of living individuals we do not have a free copy of, might be one area this could apply. I recall there was an AI image of a en:Brinicle discussed previously and deleted, which very obviously resembled the BBC footage of a Brinicle, likely as that was the first ever footage of this phenomena and remains part of a very limited set, but it's hard to work that into a general prohibition. CMD (talk) 02:28, 23 January 2025 (UTC)

@Koavf: One issue with AI generated images is that we don't usually have a way of knowing the country of origin and they are currently copyrighted in the United Kingdom. Although they are PD in the United States. The issue is that policy requires something not be copyrighted in the country of origin, not just the United States. That's not to say AI generated images can't just be nominated for deletion on a "per image" basis when (or if) it's determined if said image was created in a country where they are copyrighted, but that goes against Commons:PRECAUTIONARY and no other images get a free pass from it in the same way that AI generated artwork seems to. I. E. some people have made the argument that there doesn't need to be a source for AI generated images "because AI", which clearly goes against the guidelines. Not to say I think there should be a blanket ban either though but there should at least be more scrutiny when it comes to where AI artwork on here originates from and enforced of the Commons:PRECAUTIONARY when it isn't clear. --Adamant1 (talk) 08:13, 23 January 2025 (UTC)

 Oppose nothing new provided here. Until there is a broad legal consensus they’re copyright violations, they’re legal. And we can’t ban an entire medium just because there’s a lot of justifiable controversy around it— how are we supposed to illustrate DALL-E itself in that case? Dronebogus (talk) 09:08, 23 January 2025 (UTC)

• Like Grand-Duc, Omphalographer and others said, I think it's better to argue from a COM:SCOPE standpoint. I think it's worthwhile to add illustrative examples to the said policy or to a subpage of it, if necessary - examples where an AI image is unlikely to be in scope, perhaps along with other similar materials like amateur artworks. --whym (talk) 08:56, 25 January 2025 (UTC)

 Oppose per Blythwood.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:39, 25 January 2025 (UTC)

 Oppose a blanket ban as per the OP; illustrations made by AI are potentially useful. However if we want to keep them, AI creations have to adhere to the Commons:Scope and should be judged more critically than other content. AI images that are just created and uploaded for no educative purpose, should get deleted, especially if someone makes them en masse. AI images intended for misinformation should also lead to user bans (on repeated offenses after fair warnings). Best, --Enyavar (talk) 22:23, 27 January 2025 (UTC)

 Support ban against AS (Artificial Stupidity), alternatively strict limitations:

• only users with autopatrol right may upload AI/AS-generated files
• upoad maximally 2 AI/AS-generated files per 24 hours

Mass uploading of nonsense has become a big problem and waste of resources. Taylor 49 (talk) 00:03, 5 February 2025 (UTC)

A skilled smart person aware of the issues & limitations can still use stupid tools to produce good results. I see neither mass uploading nor a big problem so far with AI images. Prototyperspective (talk) 00:11, 5 February 2025 (UTC)

 Comment Really? Commons:Deletion requests/Files uploades by User:DenisMironov1 Taylor 49 (talk) 00:28, 5 February 2025 (UTC)

In rare cases people upload a medium-sized batch of AI images. The filetitle already informs it's AI-generated. People DR'd it and it's gone.
No issue at all as far as I can see and less problematic than people uploading 100 20MB photos of the same mundane subject for which there already are >200 varied pics or 100 separate scans of bookpages instead of a pdf file. There aren't many cases of people uploading mid or large numbers of lowquality AI files and it's easily dealt with. I've been checking recent AI uploads for a long time and it on avg was only a few files per few days so moving slowly and easy to organize. Prototyperspective (talk) 18:09, 5 February 2025 (UTC)

 Comment I'd like to add some info to the discussion. Recently, Meta Inc. (the owner of Facebook) got caught torrenting from a shadow library, Anna's archive in occurrence: https://torrentfreak.com/meta-torrented-over-81-tb-of-data-through-annas-archive-despite-few-seeders-250206 for the purpose of training their models. So, it's IMHO not far-fetched to say that any and all AI generated media is akin to the Fruit of the poisonous tree - unless proven good, it may be sensible to assume that they would be likely a copyright violation. Regards, Grand-Duc (talk) 18:07, 10 February 2025 (UTC)

If you ever watched some pirated films or read a few downloaded books of a genre from which you learn or get inspiration from you can still produce a film or image of the same genre that is not a copyright violation. Prototyperspective (talk) 19:11, 10 February 2025 (UTC)

Yes, but "inspiration" is, in the same vein as curiosity and creativity, a purely human behavioural trait (well, simians, Corvidae, Psittacidae and several Odontoceti show these too). No machine is able to replicate that, so machine-processed copyvio data remain a copyvio. Regards, Grand-Duc (talk) 19:32, 10 February 2025 (UTC)

Yes, machines / software are different from humans. That doesn't change anything about the point made. Machines can machine-learn from copyright-restricted content and then produce free content as much as humans can biological-learn from copyright-restricted content and then produce free content if you prefer me to be more precise with the terminology. Prototyperspective (talk) 19:40, 10 February 2025 (UTC)

Major damage to Wikimedia Commons

As far as I can see, major damage has successively been done to Wikimedia Commons over the last few years by chopping up categories about people into individual "by year" categories making it

1. virtually impossible to find the best image to use for a certain purpose, and
2. virtually impossible to avoid uploading duplicates since searching/matching imges has become virtually impossible.

Here is a perfect exsmple. I have a really good, rare picture of her, but I'll be damned if I'm willing to wade through all the "by-year" categories to try to see if Commons already has it. The user who uploaded this didn't even bother to place it in a personal category. Why should they, with all the work required to try to find the category at all & fit the image in there?

I am mot objecting to the existence of categories "by year", Searching is the problem.

What if anything can be done about this mess which is steadliy getting worse all the time? Could some kind of bot fix it?

I really feel that this is urgent now and cannot be ignored any longer. The project had become worth much much much less through the problem described. Or have I missed/misunderstood something here? SergeWoodzing (talk) 10:00, 23 January 2025 (UTC)

This is a duplicate discussion of Commons:Administrators' noticeboard#URGENT! Major damage to this project. CMD (talk) 12:22, 23 January 2025 (UTC)

Yes, but the user was told there to bring it here. - Jmabel ! talk 17:28, 23 January 2025 (UTC)

Contemporary VIP´s produce a ton of images. Sorting them by year makes sense - otherwise you would have to deal with hundreds of files in one category. As for Wikipedia: Go to the most recent useable photo of "Sophie" and use that. And if it is not the most flattering... well that´s life. Alexpl (talk) 12:33, 23 January 2025 (UTC)

Uh, I don't think that's really what we ought to do. I've tried for many years always to use the best possible images. --SergeWoodzing (talk) 17:52, 23 January 2025 (UTC)

It feels like the fear is a bit too huge to me, but (if you're looking for images of Donald Trump), you can enter deepcategory:"Donald Trump by year" in the regular search for example, et voilá! You can see many Donald images at once without looking into each subcat :) (Also see COM:Search for tags and flags) --PantheraLeo1359531 😺 (talk) 12:51, 23 January 2025 (UTC)

Splitting images by year is often counterproductive, but that's necessary when there are a lot of them for one person. Yann (talk) 15:45, 23 January 2025 (UTC)

See Help:Gadget-DeepcatSearch and TinEye image reverse search among other things. Prototyperspective (talk) 16:04, 23 January 2025 (UTC)

Please! I have not suggested that images should not (also) be sorted by year, so there is no need to defend that kind of sorting. I've asked for a search remedy & will now try the tips we've been given here. Thank you for them! --SergeWoodzing (talk) 17:52, 23 January 2025 (UTC)

@SergeWoodzing: Another solution I've seen is addition of a flat category for all of a topic's files, to achieve your purpose but still allow for the granularity that others like to achieve.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:31, 23 January 2025 (UTC)

I agree with the general issue brought up by SergeWoodzing. "By year" in many cases only makes sense if a large number of files cannot be meaningfully sorted in another way. Non-recurring events, certainly. But things that undergo little changes from year to year, do not necessarily need atomized categories, and I also noticed that by-year categories are steady on the rise since 2018. Not always for the better. The following examples are not what literally exists right now, but it would be easy to find real cases just like them.

• I have recently encountered more and more "books about <topic> by year", and that means that either a very broad topic like "biology" is split up by year (which later makes it much harder to split the topic by "botany" vs. "zoology", or as "by countinent", "by language", or to meaningfully search the publications) or that a very narrow topic like "American-Mexican War" gets splintered into single-file categories. How can two books about the same war be categorically different because the one was published in December 1857 and the other in March 1858?
• "Maps by year" are my pet peeve. Nearly all maps before the 21st century had many-years-long production processes. The further back we go in time, the less the publication year of an (old) map matters, the categories should rather differentiate the location and topic, not the day/month/year of publication. An old city plan of Chennai, an old topo map of Rajasthan, and an old geological map of Bengal all from the same year, have so little in common that it is pointless to primarily group them under "<year> maps of India". (I have been vocal about this several times here on the pump already, and got some support too).
• "Tigers by year": I think everyone should see the absurdity. Photos of tigers should be grouped by location (zoo, country) or by growth stage (juvenile, adult...), not whether they were photographed in 1998 vs. 2015.
• Location by year. Without exif/metadata, one photo of Taj Mahal looks like the other, with no telling that one was created 2008 and the other 2021. It makes much more sense to primarily sort them by architectural elements (main building, gates, interior...) than by year. Thankfully, this is done too, but not always. And sure, with some events even two years make a huge difference, like Verdun 1913 and Verdun 1915; but many "non-changing" locations are fine without a by-year split-up.
• "Person by year" is the OP topic already. Actually, in my opinion this makes mostly sense as long as MANY files exist. If there are just 25 files of a celebrity, please do NOT split that collection up into 12 by-year subcategories. Doing so is a case of well-intentioned obstruction, as access just gets harder with no further benefit.

Much more could be said. So while I am cautiously supportive of several important use cases of by-year categories, atomization has to stop. --Enyavar (talk) 02:12, 24 January 2025 (UTC)

While I also find it annoying to search through "by year" categories, there's merit in them.

• Books about <topic> by year: Theories change and new discoveries are made. From a historical perspective, it is interesting what biologists from the 19th century thought and assumed about biological processes and how those assumptions and thoughts differ from those in the 20th century. There is merit in stuff like "history of medicine" and similarly there's merit in stuff like "history of biology".
• Maps by year: the year helps to determine the copyright status of a map (because not all take that into consideration when uploading files). The year puts the map in context, like right now with the war in Ukraine: maps of Ukraine produced by Russia in 2024 will look different from those produced in 2010, and they will also look different from those produced by Ukraine in 2024 despite being from the same year. Such maps show how borders have changed throughout the years (be it a factual change or be it because someone thinks that they have changed).
• Tigers by year: This may seem ridiculous now, but you have to keep in mind that everything will become history one day. Wouldn't it be cool if we had photos of mammoths by year? If we had them, we'd be able to determine precisely when their population started to decline and in what area first and in which area last, and eventually, we'd be able to tell in what year exactly the last mammoth was photographed. The "tigers by year" category only seems ridiculous if one assumes that things are not going to change throughout the years. I mean, what if tigers start to change evolutionary by starting to grow saber-tooths again? Wouldn't you want to know when and where exactly the change started to occur? Don't you think that future generations would want to know how tigers looked like in 1950 vs 2000 vs 2050? You might think that such a change would take very long, but a look at the German Shepherd dog says otherwise: the dog that was first entered into the breed registry in 1895 was quite different from the one we now know as a German Shepherd (see [1][2][3]). It would even make sense to have a category for "tigers in zoos by year" because it would document how conditions regarding animal welfare have changed over the years.
• Location by year: Things do change. There are repairs, there are implementations of new regulations (such as ramps for people in wheelchairs etc.), there is deterioration of condition, etc. A building can be gone in no time, even without there being some major events causing the change but just through neglect (see this building in 2023, 2023 vs. 2024).

I think it would be helpful if files were automatically added to hidden time-related (and maybe rough location-related) categories based on EXIF data (if available) instead of having to add this information manually and retrospectively[4]. It would save time for the uploader and it would help to focus more on content-related categories when categorizing a file, yet still keep time-related categories accessible for those interested in them. Nakonana (talk) 17:20, 23 February 2025 (UTC)

There are a lot of hypotheticals in your response, and I cannot see practical usability for most.

• Books: Category:1894 books about geography. Not helpful, because geography has so many sub-topics. The structured data approach would be much more helpful here, because you could search for "1890s books" & "Alps" & "books about geography", without having to click through each single by-year category. And you might think that Category:Books about World War I is rather specific already, right? The problem is that once we subdivided them by year (or language), we can no longer comfortably subdivide them by topic as well. 1919 book=1920 book=1926 book (books about the history of specific regiments in WW1); 1928 book=1919 book=1917 book (personal war testimonials/memoirs); 1919 book=1920 book=1923 book (books about naval warfare in WW1). By contrast, the by-year subcategories about WW1 books are fully arbitrary, depending how quickly an author produced their own book.
• Maps: Just a 'lil map of an American Civil War battlefield, be my guest and identify which year the map belongs to and copyright status. Photos are snapshots of reality, made in a second. Maps are not like that at all. Yes, context is important, but structured data can handle that just as well. Once you determine "category:1907 maps of Paris" you claim that this file is categorically just as different from "1908 maps of Paris" as it is from "2019 maps of Paris" - the situation is roughly the same as with the WW1 books above.
• evolution of sabretooth tigers by zoo by year? Because humans will selectively breed them for sabretooth traits like they bred German Shepherds? Oh-kay. Sure. I am aware that this is just an example, this could be any organism. Categories are the wrong tool to document such changes, though. And by-year categories are even wronger.
• Location by year. Eh. Yes sure, the Eiffeltower undergoes major architectural rearrangements every year, but we have all those by-year categories because we have so many photos of it; and not because we try to document all those changes in its construction. For most locations that are not overflowed by mass tourism, the structured data approach is best.

Categories should be there to group "files about the same subject/". If the same subject is "Press Conference in Brussels, 2014 July 13th" with several photographs uploaded: Yes, the presser category belongs into "July 2014 in Brussels", dated not just by year but even by month. By contrast, if there are in total three photos of a statue in the Brussels suburbs, these three should be grouped together primarily; the years in which each was taken is of secondary importance. And we do NOT need "1999 photographs of <some statue in Brussels-suburb>" vs. "2005 photographs of <some statue in Brussels-suburb>" vs. "2019 photographs of <some statue in Brussels-suburb>", for three files. --Enyavar (talk) 12:02, 24 February 2025 (UTC)

•  Comment I did a proposal a few months ago to confine "by year" categories to images that show a meaningful distinction by year. For instance something like a yearly event where there's actually a difference between the years. Whereas, say images of tigers per Enyavar's example aren't worth organizing per year because there's no meaningful between a tiger in 2015 and one in 2016. Anyway, it seemed like there was general support for the proposal at the time.

The problem is that there's no actual way to enforce it because people will ignore consensus, recreate categories, and attack anyone who disagrees with them. It's made worse by the fact that admins on here seem to have no will or ability to impose any kind of standards. They just cater to people doing things their own way regardless of consensus as long as the person throws a big enough tantrum about it. There's plenty of proposals, CfD, village pump and talk page discussions, Etc Etc. that should already regulate how these types of categories are used though. They just aren't ever imposed to any meaningful degree because of all the limp wristed weak pandering to people who use Commons as their own personal project. --Adamant1 (talk) 06:47, 24 January 2025 (UTC)

So should they ban you promptly for using a homophobic slur ("limp wristed"), or should they just let you continue going on your way ignoring consensus?--Prosfilaes (talk) 08:16, 24 January 2025 (UTC)

@Prosfilaes: I didn't actually know it was a homophobic slur. I just thought it meant weak. I struck it out though. Thanks for letting me know. Not that I was saying anyone should banned for ignoring the consensus, but if people intentionally use homophobic slurs then yes they should be banned for it. With this though it's more about the bending over backwards to accommodate people who don't care about or follow the consensus then it is sanctioning anyone over it. people should just be ignored and the consensus should be followed anyway. There's no reason what-so-ever that it has to involve banning people. Just don't pander to people using Commons as their own personal project. It's not that difficult. --Adamant1 (talk) 09:28, 24 January 2025 (UTC)

For this topic at least, I don't think I have seen actual attacks against other users, thankfully. SergeWoodzing has used some strong condemnations of the status quo in general on Commons, but I do not perceive his statement as an attack against some users. Now, Adamant points out the problem, which is that we seemingly don't have a guideline or even policy on which topics may be organized by year and which ones should rather not get a by-year categorization. I'm almost sure that people are creating by-year categories out of the best intentions, and mostly because they are boldly imitating the "best practice" of other users, ignorant of some consensus that may or may not have been formed among a dozen users in the village pump. Which means that such users have to be talked out of the idea individually once they start by-year categories for an unsuitable topic. --Enyavar (talk) 16:33, 24 January 2025 (UTC)

There's certainly an aspect to this where people indiscriminately create by year categories because other people do. But it still comes down to a lack of will and/or mechanisms to enforce standards though. You can ask the person doing it to stop, but they can just ignore you and continue. Then what? No one is going to have repercussions for ignoring the consensus by continuing to create the categories. I've certainly never there be any and I've been involved in plenty of conversation about over categorization. The person usually just demagogues or outright ignores the issue and continues doing it. --Adamant1 (talk) 16:54, 24 January 2025 (UTC)

Tbf I didn’t really know it was either. I wouldn’t even call it a “slur”— more of a general insult with homophobic connotations, like “sissy” or “pansy”. Dronebogus (talk) 17:57, 27 January 2025 (UTC)

 Support resolving concerns reported by user "SergeWoodzing". such "alternative overcategorization" by year, or even worse by state, makes useful files hard to find. Not for "Contemporary VIP:s" brewing gazillions of useless images, but for relevant topics, especially if the total number of files is low. Taylor 49 (talk) 00:18, 5 February 2025 (UTC)

The fix for this problem is to lobby the Wikimedia Foundation to finish implementing structured data on Commons, then use that instead of our antiquated category system. — Rhododendrites ^talk |  22:51, 23 February 2025 (UTC)

The category system is in no way antiqued. Structured depicts data is currently a barely populated totally-unused time sink where all of it can be captured by the categories. Display categories in a different way maybe – more like many other websites which have tags – or improve how categories can be queried, searched & qualified. Prototyperspective (talk) 00:41, 24 February 2025 (UTC)

I have to agree with Rhododendrites. Categories on Commons have become completely useless (mostly thanks to "by year" categories). Structured data is the best way forward. Nosferattus (talk) 00:57, 24 February 2025 (UTC)

If the reason you think these are "useless" is because of "by year" categories then that just shows how incredibly irrational and weak your argumentation would be. It makes no sense and is actively harming Commons based on some strange SD ideology that exists because people try hard to bury their head in the sand. The solution for this minor issue is simple: a) use other/by subject subcategories instead or b) use search methods like deepcategory:"Donald Trump by year" which can be made more accessible via a cat-search-box. Prototyperspective (talk) 01:43, 24 February 2025 (UTC)

c) finally implementing date sorting & range-filters including reading the data in the already-existent Summary template. phab:T329961#10041982

Wouldn't mind if the data in these templates would be synced/copied ~at once into structured data if that's the easiest/best way to implement it but categories are still best for subjects and would just be combined with such metadata in structured data (e.g. sort by or specify year on the category page). Prototyperspective (talk) 01:54, 24 February 2025 (UTC)

Structured Data is not an "ideology", it is just a good way to have files organized flexibly and without a rigid category structure. I argue that we need both categories and SD.

"By year" categories are often but not always handled terribly. I have no problem with "Category:1919 in Paris (10 C, 57 F)": it is a big place, and that amply filled category allows you to browse. I also have no problem with "1919 elections in Brazil (1 F)" because it is part of a whole scheme about a very specific topic. I do have a problem with "Category:1919 in Farmton-upon-Runlet, Ruralshire (2 F)", especially if that is the only by-year category from there until "Category:2013 in Farmton-upon-Runlet, Ruralshire (6 F)".

That last example from above shows the antiquated approach of using categories to build elaborate trees around singular files. "Category:<Church> in the 20th century" which has "Category:<Church> in the 1920s" which has "Category:<Church> in 1921". That last category could also be the single child category of "Category:<Town> in 1921" (for a town like this with a total of 3 photos in the whole 20th century). There is also "Churches in <country> photographed in 1921". Now that category should be handled by a structured data query, not rigidly coded into each file. The structured data would add a tag of "date=1921"; and if it later turns out that the 1921 photo was actually taken in 1905 already, only one little thing needs to get changed. --Enyavar (talk) 10:06, 24 February 2025 (UTC)

The primary problem with the hierarchical category system (along the language problem) is that it creates false statements. For example we have a mountain in a nature reserve with a communication tower on the summit. The tower in not part of the nature reserve. The tower is categorized unter mountain and the mountain under the nature reserve. Then we get photos of the interior of the tower we looking for photos of the nature reserve. This could be solved by building parallel category structures and only linking them as "see also". But this is far to complicated for people who do not work with the category system in the particular topic every day. GPSLeo (talk) 10:45, 24 February 2025 (UTC)

This thread is only about the "by year" category subtree, though? --Enyavar (talk) 12:05, 24 February 2025 (UTC)

I think not really. But the the same problem applies to by year categories also. GPSLeo (talk) 12:29, 24 February 2025 (UTC)

I agree that this is a problem but it's not a problem with the categories and isn't about statements (at least mostly; or entirely as of now). This is a problem if you use deepcat – e.g. using the Help:Gadget-DeepcatSearch – on the category about the nature reserves or even the grandparent cat about all nature reserves. However, I don't think your example is very good: in that case the tower including its interiors is actually part of the nature reserve and it would be fine to have these photos show up, they just shouldn't be all over the page and preferably more near the bottom of the results. It's still a problem that they show up in the cat "Nature" etc since "Nature reserves" are their subcat. In any case, here is how this can be addressed (and this problem warrants a separate thread):

• Tools for deepcat can be made so that one can easily adjust the depth and have it exclude special categories (it could use these some by default and have premade filters one can readily switch on): I've described this here at phab:T376440#10354943
• Some tool(s) are needed for contributors to more easily spot and fix miscategorizations. FastCCI is such a tool but most of the time when trying to use it, it somehow fails to load and more importantly, that is not its primary or a dedicated purpose of it but more some ancillary feature. The tool would function like so: first the user spots some image they think doesn't belong into the deepcategory results – for example I used this on a photo showing some road sign or sth somewhere underneath Category:Microscopic images relating to biology. Then they use that tool to quickly see how that image relates to the given category (the one I just linked) which would show the category-path from the image to the given category (the shortest one or all if there's multiple paths). Then the user identifies the miscategorization and fixes it which can involve adding a category-see-also or the creation of a new category or simply removing a categorization. One can't expect categorization to be good if people don't have such tools. English Wikipedia actually has the same problem but I guess to a lesser extent where e.g. articles about people, films and events were in the category tree about novels iirc. Please see talkFastCCI:Not loading, showing offoptic images, and proposal for a forked gadget that shows the cat-path why a file is in cat. This is important and the earlier it gets done the better and the more accurate the categorization tree and useful the deepcat results will be.

Prototyperspective (talk) 12:33, 24 February 2025 (UTC)

The category system is in no way antiqued. Structured depicts data is currently a barely populated totally-unused time sink where all of it can be captured by the categories - It's web 1.0 technology that's been replaced everywhere else on the internet. Manually creating semantic categories with no logic other than a basic hierarchy and piling them together. Nevermind the people by year, how about A of B in C in D type categories, where the [English-only] prepositions might be "in" or might be "of", and A, B, C, and D might be repositioned. Structured data makes all of that a non-issue. You're talking about depicts, but depicts was just supposed to be the first of many data points. Structured data being "barely populated" doesn't mean it's a worse system; it means it's not fully implemented or adopted. The only good argument I've ever seen for categories over structured data is "we already have it, and volunteers have put a ton of time into creating it, and they'll be unhappy/demotivated if we lose any of it". It's a totally valid point, but has nothing to do with it being a superior system... the strength of the argument comes from the value of volunteers. Similar argument, I guess, for consideration of economic devastation in coal-mining communities when there's a concerted push towards renewable energy. IMO the priority should be lobbying to finish implementing SDC, and then focus on bots that can translate category data into structured data so as not to lose that volunteer time. — Rhododendrites ^talk |  21:24, 24 February 2025 (UTC)

The last time I checked the semantic web was dead on arrival. At the end of the day most people don't know or care about structured data. There should really be a more modern, widely used (I. E. usable by most people) way to organize images. Be that tags or some other system but it seems like a pointless time sink to fully implement SDC when most people can't or don't want to use it anyway purely because categories suck. I don't think fixing the issues with SDC on here is going to magically create a market for it over categories either. It's just a convoluted, half-baked system at the core that there's no actual enthusiasm for. A solution looking for a problem if you will. --Adamant1 (talk) 22:29, 24 February 2025 (UTC)

It's semantic web technology/methodology and even if it wouldn't be, that something isn't the shiniest new concept doesn't mean it's antiqued. You can define how these categories via a) how the categories are titled and b) via the Wikidata items of the categories where they relation can also be defined. Similar methods&systems have not been replaced on other websites, that is false. They generally have well-visible (not at the bottom or even hidden) tags right beneath or above the image.

--- Just on top of this refutation of your points, Structured data makes all of that a non-issue is plain false. People don't take a minute to tag a picture in some sophisticated SD way, they only add plain depicts and either mark it as prominent or not and even that isn't done for >95% of files and not done sufficiently or as much for remaining ~5% (probably much less). Again, SD for metadata that is mostly in the EXIF data wouldn't be an issue. Reread what I wrote earlier about SD, it's not a better system which is also why it's barely used (read and written to) and why when it is written, it's just copying from the categories. The categories are currently better for example because they have category pages and because they have a category tree relation which is absent here and when you click the SD tag you just land on some Wikidata item. Maybe something that syncs categories to the SD wherever matching WD items exist would be useful but it shouldn't replace that which is currently useful and I don't see why much resources should be spent on something that is largely redundant and importantly not used at all except for some niche experiment tool used by virtually nobody that shows images based on SD depicts which could also be done (with much better results) by querying the Commons categories or using the Commons search (which needs improvements). There is no benefit, no need (agree with A solution looking for a problem if you will when it comes to depicts SD), and lots of drawbacks. Prototyperspective (talk) 23:31, 24 February 2025 (UTC)

Prototype, Adamant describes a notorious problem with SD: there are no standards which attributes should be applied to a file, and there is no easy way how to apply them; and as a result SD is used in most haphazardous (I love that word, it comes up so rarely. =) way possible, and also basically not used in total. The SD editor we implemented here on Commons is truly a disaster, and this proposal was my only point on the wishlist for the Community Call this year. I have no idea what became of the suggestion, besides the promise it would be brought up; but there is no protocoll or transcript. So who knows. Maybe @Sannita (WMF): can provide/link some insight what happened since? I'm highly curious.

Anyway, so yes, SD implementation is bad currently; but our category tree is mostly maintained manually, usually by combining several "SD terms" in one category name, and then searching for random files that fit the description, and place them in the category.

If I may compare Commons to a library: we don't use those pesky new-fangled book catalogs! They would allow indexing and consistent searching, but it's soooooo much work to compile them! Drag each book to the desk, input lots of info into a computer that the book already has printed in it anyway, and then bring it back where it came from. No, we just place each new book on the shelves which are all thematically organized and subdivided, and then we trust all readers to navigate the shelves. / Now, with the catalog, you could just assign barcodes to all the books, then search for them in the catalog and retrieve them easily, even with fully unordered shelves. / The optimal approach is however to catalog the books and also use the thematic shelves. And most public libraries do that, despite the double work. Shelves (i.e. categories) are great in general, except the overly specific - like "Tigers in European zoos in 2023" or "1944 diaries of women in World War II". Oh yes, there are the files that hit these two spots, but it's not a superior way to organize the library. --Enyavar (talk) 16:32, 25 February 2025 (UTC)

No, that is false. 1. He did not describe that as the problem in that comment at least. 2. That is not the problem at all.

Also it's good that SD is not used at all since volunteer time is valuable and adding redundant SD is a large waste of time ever and if anything should be disincentivized since we got many better things for volunteers to do than writing metadata that is of no use to anyone to 0.1% of files that is already present at the file. For example, by working on readily implementable things that could feasibly double or quadruple Wikipedia readership or improving the MediaSearch or adding content to Wikipedia. Those roundabout explanations for why SD would be useful or even needed are not convincing and based on pipedreams – SD won't magically allow the items to be tagged. If you want that to be done, it needs work on some bots or simply what I have proposed here. I don't see a reply of you there. SD will take "soooooo" much work while the easy-to-use familiar category system make things quick and easy with tools like cat-a-lot and there are several further ways of how to have things more reliably categorized, a second of which is reading the fields of the Summary template which can be used to set categories. If structured data is used for subjects, then make it read-only for users and automatically infer the tags from the categories. "Tigers in European zoos in 2023" would automatically get the SD "tiger" and year "2023" instead of some redundant doublework. In addition, people could use a deepcat viewmode in e.g. the Tigers category where the most useful images are sorted near the top (once again MediaSearch improvements) or use the daterange filter based on the date in the File information template (again see the phab issue). I think for tigers most people would not use such an overspecific cat and people should not move the file only into a year subcat but also into a subject-specific one and at wherever the scope of cats is what one is interested in, one could then use something like a successor of the deepcat gadget or FastCCI to have a modern nonoverspecific view to scroll through. By year categories are just a minor aspect of Commons, the solution would be to have year-categories set (semi-)automatically based on the date in the file info Summary template. Prototyperspective (talk) 00:28, 26 February 2025 (UTC)

People tend to act like the WMF and/or developers on here are just incompetent slackers but I image if SDC was really the be all end all people treat it is that they would be putting the time and resources into making it viable. This isn't rocket science. They must know it's a hot mess that know one wants. Tangentially, something that I think would solve some is better and or more descriptions templates for specific types of media. As it currently is for something like a postcard, we are forced to use the general description template or one for photograph. Both leave out fields that are important to postcards. But it would help make searching for them a lot easier if the publisher, photographer, location, subject were included in the file description and in specific fields for them. Then the categories for organizing postcards based on those criteria could be axed. Like a couple of thousand categories for postcards by publisher right now that are probably pointless, but the publisher isn't included in descriptions in a lot of instances. So it's really the only option there is to postcards by specific publishers baring people writing better descriptions or using creator templates. Creator templates are another thing like see alsos that are way under used on here BTW but there's already solutions to the problem SDC is meant to solve. People just need to use them. SDC is redundant at best, if not totally worthless at worst though. --Adamant1 (talk) 10:56, 27 February 2025 (UTC)

Then the categories for organizing postcards based on those criteria could be axed I don't see how that follows; instead one could use a mentioned functionality to read the fields of the file Information template to set the cat (semi-)automatically. Prototyperspective (talk) 13:49, 27 February 2025 (UTC)

@Prototyperspective: There's a postcard publishers that we're never going to have more then a few images of postcards for and/or where the publishers information just isn't available for whatever reason. Plus ton of them are just two letter initials, if even that. Not to mention a lot of publishers have multiple ways their name is printed on the postcards. Like there's at least a couple of publishers where I knew they published the same postcards because of how the stamp box is designed but a category like Category:Brown square stamp box (postcard publiser) isn't practical. It's not practical to create multiple "by publisher" categories for the same publiser based on if they used there initials, full name, Etc. Etc. on particular postcards. But something like a note about it in the description would be fine. There's also a huge problem with people categorizing images of postcard by publisher but not subject or location. The thing is categorizing an image of a building in a category specifically for that building. It just doesn't happen though. Hundreds of images get dumped in a category like Category:Postcards published by Detroit Publishing Co. and still aren't put in subject based categories years later. So "by publisher" isn't a practical, scalable, way to categorize postcards IMO. Categories are really only good for one or two criteria and in instances where those criteria are totally unambiguous. --Adamant1 (talk) 17:45, 27 February 2025 (UTC)

•  Comment I have been frustrated about categories for years. It is a pain to have to look through 100 categories with 1-5 photos in each category to find a good photo. Personally I think 100-200 photos in a category are more suitable because it is very fast to find a photo in a category. If there are 1,000 files in a category sorting in subcategories is a good idea. At least I know now that deepcategory can help a bit. --MGA73 (talk) 19:24, 24 February 2025 (UTC)

@GPSLeo: What you refer to as "The primary problem" is only a problem if you assume that the subcategory relation is always an is-a relation. And, yes, Pinging @Enyavar there is a bit of "ideology" involved: not in the idea of having SD so much as in the idea that SD is inherently superior to categories. This is almost always based on an argument comparing, on the one hand, what would happen if SD were used in something close to an ideal manner to, on the other, the actually existing state of categories.

And these two issues (failure to tag the nature of a particular category inheritance, ideological preference interfering with synthesizing the two systems) come together. Since the advent of SD, WMF has (as far as I can tell) devoted exactly no resources to improving categories. I don't think the neglect has been consciously driven by ideology, but ideology rarely functions on a conscious basis.

Leaving maintenance categories aside, and sticking to topical categories, the two biggest deficiencies in categories are, as noted, (1) lack of support for multiple languages and (2) lack of ability to express the relationship between a category and its parent categories. (Conversely, the largest disadvantage of structured data is that (3) users access it through an entirely different mechanism than the wikitext with which virtually all experienced Wikimedians are familiar.)

I believe all three of these problems are completely addressable. I won't go into details here, and I'm about to be traveling the next 5 weeks so this isn't a time for me to flesh this out, but if I were a developer trying to address these, here's the general directions I'd be looking at. If someone wants me to flesh this out, hit me up in early April when I should be more available again. Some of these involve integrating wikitext and SDC, some do not.

1) lack of support for multiple languages in categories. If a category has an associated Wikidata item (associated via Commons category (P373) in Wikidata, or possibly just with the interwiki link for the item; I'm going to skip that latter alternative throughout the rest of this and stick to P373), then a bot should be perfectly capable of copying all of the item names, in whatever language, including aliases, into a templated structure on the Commons category page. This would only need to be updated when the Wikidata item changes or the P373 value changes.

2) lack of ability to express the relationship between a category and its parent categories. I see several ways to address this; from an information-theoretic point they are very similar, and a mix-and-match via a bot is possible.

2a) A template-driven structure in the category to express its relation to each parent category. Probably optional, with the default to presume an is-a (instance of (P31)) relationship. It might be simplest to name these precisely from the P-codes of the relevant Wikidata items, ideally with a tool to make that more human-readable (see (3) below). Again, wherever Wikidata is aware of the category via P373, a bot could do an enormous amount of this work.

2b) An extension to "Category" in mediawiki that would allow an equivalent to 2a to go directly into the [[Category]] element. (e.g. a markup like [[Category:Seattle|P=276]] for Category:Buildings in Seattle to say it is located in Seattle. However, I think this is less good than 2a because (1) it would require a change to mediawiki rather than just to tools and (2) it is not good at expressing things like "this category is an intersection of year YYYY and place PLACE".

2c) I could imagine something more dynamic that does all of the calculation of Wikidata relationships among categories on the fly when needed. However, I would have to guess that is more computationally intensive, so a less good idea.

3) users access SDC through an entirely different mechanism than the more familiar wikitext. I believe this could be solved by a serialization/deserialization approach (serialization: SDC => wikitext; deserialization: wikitext => SDC). Presumably the relevant wikitext would be in the form of templates. Admittedly, the serialization side of this is much easier, so it might make sense to think of it first as a read-only mechanism. However, I could imagine a slow, steady implementation of the deserialization side to let more and more SDC content be edited through the wikitext editor. And, of course, something parallel could be done for less technically-inclined users, using the same approach the WYSIWYG editor on Wikipedia has taken to turn several templates into forms. - Jmabel ! talk 20:10, 24 February 2025 (UTC)

To a certain extent, what you are saying sounds like reinventing Semantic MediaWiki. But hey, maybe that is a better model for commons. SDC kind of just grafted wikidata on to commons, but commons does not have the same requirements as wikidata. I've only recently tried playing with SDC. So far I think its really cool, but as a newbie to SDC there are lot of ambiguities as to how the data is supposed to be (Is depicts anything in the picture or just the main things?). From what I've seen so far though, i think the big problem with SDC is UI. Its hidden away in a separate tab. Interesting and uninteresting data is mixed together (Why oh why do we a bot manually adding properties for SHA1 of files? That makes no sense. Why is something like a checksum displayed at the same prominence as the creator). More to the point though, there is no way to browse the results (Except externally). How can we expect users to care about entering metadata if they can never see the results? With a category, you click on it and get to see other things in that category. Not so with structured data. SDC is never going to succeed as a way to catalog commons if we don't implement the browse through the catalog part. Bawolff (talk) 05:07, 1 March 2025 (UTC)

Where do you find the time to be so involved on this website may I ask? It’s rather queer. Jon.schmon4862 (talk) 07:34, 19 March 2025 (UTC)

Make Commons:Civility, Commons:Harassment and Commons:No personal attacks a policy

Additional discussion (Make Commons:Civility, Commons:Harassment and Commons:No personal attacks a policy)

@The Squirrel Conspiracy Do you think it is good to close this that fast? There are many comments mentioning that there is some need to adapt the pages for Commons. If they are now a policy every not very minor change would require separate community confirmation. GPSLeo (talk) 08:45, 1 February 2025 (UTC)

That's fair, but if the proposed changes are uncontroversial, it should be easy to get a consensus for them, and if they are controversial, they shouldn't be in the policies in the first place.

Candidly, I'd like to think that after 15 years, I have a good sense for what does and doesn't get done on this project, and I suspect that no one is going to step up and rewrite the policies regardless of whether the discussion stays open for two weeks or not. Happy to be proven wrong, but there are lots of gaps in Commons' bureaucracy and infrastructure that have never been fixed.

If you want to revert the close, go ahead though. The Squirrel Conspiracy (talk) 10:34, 1 February 2025 (UTC)

As for the procedure, I would at least wait until one weekend is over, to include people who only find volunteer time in weekends. While I agree with the observation that there have been policy gaps for a long time, but I think the long time span also means that it wouldn't hurt to spend a few more weeks, or at the very least, the proposed 2 weeks. Using Template:Centralized_discussion or even MediaWiki:Sitenotice wouldn't be unreasonable for this, consdiering most users don't frequent to COM:VPP, but are affected. Sitenotice might be more suited for the final decision, though. whym (talk) 02:03, 2 February 2025 (UTC)

@GPSLeo: Do you think it was premature to promote those pages? I do. Whether we should un-promote them might be a different matter (unless The Squirrel Conspiracy voluntarily undo the changes), though. One remedy might be to recognize that they have community consensus at a general level, and that they are adapted policies and might still have rough edges in specifics. --whym (talk) 10:32, 7 February 2025 (UTC)

I think is was to early but I would just keep the discussions going in the current way and in some weeks make a final vote to get clear consensus on the final versions. GPSLeo (talk) 18:17, 14 February 2025 (UTC)

• I think Commons:No personal attacks talks too much about articles and article talk pages, which we don't have in general. And I don't know what would be the Commons counterpart to regular disagreements on Wikipedia talk pages. whym (talk) 11:58, 1 February 2025 (UTC)

  Good point! I'd love to see more thought on this. Jerimee (talk) 05:12, 1 March 2025 (UTC)

• See also an ongoing discussion in Commons_talk:Civility#Pre-policy_debates (started a few days ago). whym (talk) 02:18, 2 February 2025 (UTC)

  Similarly, I've started a discussion about making our new outing rules more Commons-specific over on Commons talk:Harassment. --bjh21 (talk) 09:40, 5 February 2025 (UTC)

In the past before these stringent rules even became "policy" I already saw at least weekly users clashing because of linguistic and cultural misunderstandings.

How many sysops remember to give the benefit of the doubt before wielding this weapon against minority users?

LOL.--RoyZuo (talk) 14:02, 5 February 2025 (UTC)

@The Squirrel Conspiracy and Matrix: FYI, the promotion of Commons:Harassment to policy has been undone. Nosferattus (talk) 14:22, 6 February 2025 (UTC)

To be clear, it was undone by Matrix.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:37, 6 February 2025 (UTC)

Sorry, I didn't see this discussion, I reverted my reversion. —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 18:46, 6 February 2025 (UTC)

I think this indicate that we could have advertised more before voting: putting a notice on the proposed policy page and its talk page. (Not the fault of the proposer - they specifically said voting was to be done later, not immediately.) whym (talk) 11:39, 7 February 2025 (UTC)

Is there some way we could specifically mark these as draft policy? - Jmabel ! talk 21:15, 7 February 2025 (UTC)

There's {{Proposed}} which is close and I think includes what you want. —Justin (koavf)❤T☮C☺M☯ 01:11, 8 February 2025 (UTC)

But does nothing to suggest that it is a largely agreed-upon draft, and we are just hammering out details. - Jmabel ! talk 04:21, 8 February 2025 (UTC)

Why not use someting generic like {{Notice}} to insert a short text describing that? I realize the repetitiveness but on the other hand, it's just 3 pages. whym (talk) 06:12, 23 February 2025 (UTC)

I think it would be a mistake to try to mark these documents as not-quite-policy. That would lead to arguments about which bits were really agreed upon and which bits weren't, which isn't going to help anyone. Much better in my opinion to accept that they're policy now, and to put our efforts into correcting any faults they might have. --bjh21 (talk) 22:18, 4 March 2025 (UTC)

Why not say both? We can say that they are policies, and that we are still (and we know we should be) making non-trivial corrections to them. It might be somewhat contradictory but I think it would be an accurate reflection of what people here in this discussion thread think collectively. whym (talk) 03:10, 30 March 2025 (UTC)