Commons:Village pump/Proposals

Welcome to the Village pump proposals section

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

Please note

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

Start a new discussion

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

CAPTCHA for many IP edits

There is a new feature that allows AbuseFilters to require a CAPTCHA before uploading an edit. I would like to enable this for many IP edits, especially IP edits on mobile. The aim of this is to reduce the huge amount of accidental and nonsense edits. Are there any concerns against this? GPSLeo (talk) 10:06, 18 August 2024 (UTC)[reply]

No, it would be good to reduce maintenance time to free up time for other tasks. However, I doubt this is enough and have called for better vandalism/nonsense-edit detection like ClueBot does it on Wikipedia here which may also be some context for this thread. Prototyperspective (talk) 10:25, 18 August 2024 (UTC)[reply]

Detection of nonsense after is was published is not our problem, this is possible with current filters. We do not have enough people looking on the filter hits and reverting the vandalism. We therefore need measures to reduce such edits. If we do not find a way to handle this we need to block IP edits entirely. GPSLeo (talk) 10:56, 18 August 2024 (UTC)[reply]

I think we rather need measure to automatically revert such edits. Detection is a problem if it's not accurate enough that it contains too many false-positives that people don't implement them. The proposal is not just about detection but also about what follows from there – for example one could also automatically revert them but add the edit to a queue to check in case the revert is unwarranted. Prototyperspective (talk) 11:00, 18 August 2024 (UTC)[reply]

We might to want to experiment mw:Moderator Tools/Automoderator. It won't probably work perfectly at a first experiment, but we will at least know some indication of where it works and where it doesn't. whym (talk) 01:18, 1 September 2024 (UTC)[reply]

Very interesting! Thanks for the link, it's very constructive and if possible please let me know when WMC enables this or when there is some discussion about enabling it.
It could save people a lot of time and keep content here more reliable/higher quality. I think there's not even auto-detection for when e.g. 80% of a user's edit have been reverted for checking the remainder and whether further action is due. Prototyperspective (talk) 23:18, 1 September 2024 (UTC)[reply]

I think we rather need measure to automatically revert such edits Absolutely yes. I think the risk of losing well-intentioned IP edits in Commons is quite low (for example, I had edited Wikipedia as an IP user many times before I registered, but I've never thought of editing Commons as an IP user). MGeog2022 (talk) 21:27, 26 September 2024 (UTC)[reply]

Capchas are supposed to stop robots from spamming, right? Why would this stop some random human IP user from posting “amogus sussy balls”? Dronebogus (talk) 14:05, 18 August 2024 (UTC)[reply]

Seconding this. CAPTCHAs should only be used to prevent automated edits, not as a means of "hazing" users making low-effort manual edits. Omphalographer (talk) 20:12, 18 August 2024 (UTC)[reply]

Maybe candidates could be edits that are currently fully blocked but have some false positives that could be let through?
∞∞ Enhancing999 (talk) 13:59, 27 August 2024 (UTC)[reply]

You did not consider the full rationale of OP, he wrote huge amount of accidental […] edits and this measure would be partly and probably mainly be about greatly reducing accidental edits. OP however failed to name some concrete specific examples which have been brought up in a thread elsewhere. I favor better detection of nonsense edits and automatic reverting of them but requiring captchas for IP edits on mobile or for certain actions may still be worth testing for a month or two to see whether it actually reduces these kinds of edits. Prototyperspective (talk) 16:43, 27 August 2024 (UTC)[reply]

I'd totally support requiring captcha's for edits on mobile in general, not just for IP addresses. I know personally I make a lot of editing mistakes on mobile just because of how clanky the interface is. There's also been plenty of instances where I've seen pretty well established users forgot to sign their names or make other basic mistakes on mobile. So I think having captcha's on mobile for everyone would be a really good idea. --Adamant1 (talk) 17:59, 27 August 2024 (UTC)[reply]

In Special:Preferences there is an option "Prompt me when entering a blank edit summary (or the default undo summary)". Enabling this seems like a good way to provide a chance to briefly stop and review what you are trying to do. I wonder if it's possible to enable it by default. A captcha answer has no productive value, but a good edit summary will do. whym (talk) 01:15, 1 September 2024 (UTC)[reply]

I'd support that as long as there's a way for normal, logged in users to disable it if they want to. I think any kind of buffer between making an edit and posting it would reduce bad edits though. Even ones that are clearly trolling. A lot of people won't waste their time if they have to take an extra step to post a message even if it's something like writing an edit summary. --Adamant1 (talk) 01:34, 1 September 2024 (UTC)[reply]

There is something to be said for en:WP:PBAGDSWCBY and en:WP:ROPE (I know, we don't ban here, just substitute indef for ban). — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:01, 1 September 2024 (UTC)[reply]

@Jeff G.: True. That's one of the main reasons I support requiring people to have an account since it seems to be much easier to track and ban editors that way. --Adamant1 (talk) 02:05, 1 September 2024 (UTC)[reply]

@Adamant1: Like it or not, we still have "anyone can contribute" right on the main page. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:17, 1 September 2024 (UTC)[reply]

@Jeff G.: Anyone can still contribute if we require accounts. I could see not requiring accounts if there was legitimate reason for it, but I've put a lot of thought into this over the last couple of years and can't think of one single legitimate reason why someone wouldn't be able to create one. We'll have to agree to disagree though. I can understand why they let IP edit Wikiprojects back in the day though, but the internet and people are just different now and the project should be able to adapt to the times. --Adamant1 (talk) 02:21, 1 September 2024 (UTC)[reply]

This does not help in cases this is about as theses types of edits always have auto generated edit summaries and no way to edit the edit summary. GPSLeo (talk) 04:32, 1 September 2024 (UTC)[reply]

Maybe that is a software problem to be fixed? It already says "(or the default undo summary)" after all. Reminding users to add a bit more to what's auto-generated seems like a natural extension. whym (talk) 18:54, 1 September 2024 (UTC)[reply]

The Wikibase UI does not have such a feature and in the many years of Wikidata it was not considered a problem that changing the edit summary is not possible. GPSLeo (talk) 20:24, 1 September 2024 (UTC)[reply]

Can Commons customize that in their Wikibase instance? It's not yet implemented in the Wikidata UI, but on the API level Wikibase supports edit summaries according to d:Help:Edit summary. whym (talk) 23:38, 1 September 2024 (UTC)[reply]

I make much fewer editing mistakes on mobile when I use my new portable bluetooth mini keyboard. Touch-typing in the dark, however, can still be problematic. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:52, 1 September 2024 (UTC)[reply]

One week test

There is definitely no consensus to use this feature for now but there were some people suggesting to make a test. Therefore I would propose that we make a one week test and then evaluate the results. GPSLeo (talk) 19:37, 2 September 2024 (UTC)[reply]

Why? How is that useful? No consensus to implement means no consensus to implement, period. I can guarantee it will not gain any more consensus with a test version. Dronebogus (talk) 21:08, 2 September 2024 (UTC)[reply]

There were some people suggesting to make a test. There is also no consensus against some kind of measure. GPSLeo (talk) 14:11, 3 September 2024 (UTC)[reply]

There is also no consensus for it. I feel like you’re just projecting whatever you like onto the discussion to make sure your proposal gets through somehow. It sucks when people don’t like your idea, but “seeing” consensus where none exists is not the way to fix that Dronebogus (talk) 19:54, 3 September 2024 (UTC)[reply]

Oppose. As I noted above, this is not an appropriate use of CAPTCHAs - their purpose is to prevent automated edits by unauthorized bots, not to prevent "accidental or nonsense edits". Omphalographer (talk) 20:42, 3 September 2024 (UTC)[reply]

Simple edit confirmation

Instead of a CAPTCHA it is also possible to show a warning and require the user to confirm their edit. I would propose to make a one week test where we show IPs a warning "You are publicly editing the content of the page." and they have to hit the publish button again but with no CAPTCHA. GPSLeo (talk) 15:59, 26 September 2024 (UTC)[reply]

Support Makes more sense. I think it's worth giving that a try but one week is short so somebody would need to have a good way of tracking relevant changes and creating some stats to see whether it's been effective. Or are there any better ideas what to do about Unregistered or new users often moving captions to other languages? Prototyperspective (talk) 20:58, 26 September 2024 (UTC)[reply]

Support A month is probably better though. --Adamant1 (talk) 21:05, 26 September 2024 (UTC)[reply]

Info @Prototyperspective and Adamant1: I made a draft for the message shown by the filter: MediaWiki:Abusefilter-warning-anon-edit. GPSLeo (talk) 09:29, 13 October 2024 (UTC)[reply]
1. link to Commons:Project scope directly.
2. put "If you are sure that your edit is constructive to this page please confirm it again." as last paragraph.
3. We also recommend you to create an account, which allows you to upload your own photos or other free licensed content.
RoyZuo (talk) 12:00, 18 October 2024 (UTC)[reply]

I suggest the warning message includes a link to a place where users can give feedback (complain) so that we might see how many users are affected; and the test period be 1 month. 1 week is too short. collect stats over the period as often as possible (daily?). RoyZuo (talk) 06:34, 18 October 2024 (UTC)[reply]

For the monitoring I created a tool [1]. The feedback is a problem as we had to protect all regular feedback pages due to massive vandalism and I think if we create a new page for this we would have to monitor it 24/7 and massively revert vandalism. GPSLeo (talk) 08:27, 18 October 2024 (UTC)[reply]

Interesting tool. Please correct the typo in the page title and add a link to some wikipage about it (where is the software code, where to report issues or discuss it, is it CCBY). It does show edits that were later reverted in the charts and not edits that are reverts by date right? Prototyperspective (talk) 11:03, 18 October 2024 (UTC)[reply]

I created a documentation page for the tool Commons:Revert and patrol monitoring. GPSLeo (talk) 11:01, 19 October 2024 (UTC)[reply]

Can you keep the data from start to now, instead of only 1 month? RoyZuo (talk) 18:16, 20 October 2024 (UTC)[reply]

The problem is that all edits become marked as patrolled after 30 days. It would be possible to also check the patrol log to get this data but it would be a bit complicated and would require to much API request for daily updates. For edit counts and revert counts it is not such a huge problem but also a bit problematic when requesting data for a hole year every day as edits might get reverted after a year. GPSLeo (talk) 18:40, 20 October 2024 (UTC)[reply]

You could just keep the data as it was right before all edits become patrolled, right? RoyZuo (talk) 14:00, 23 October 2024 (UTC)[reply]

When i first looked at the table data was starting from 2024-09-17. now you can keep instead of erasing data that "expire" after 1 month. RoyZuo (talk) 14:04, 23 October 2024 (UTC)[reply]

You mean just keeping the row in the table without updating the number of reverted edits? GPSLeo (talk) 14:43, 23 October 2024 (UTC)[reply]

From now on I will keep the data from the last day without updating it. In two month I will then need to update the design of the page, maybe I make a sub page for the archive data. GPSLeo (talk) 16:04, 25 October 2024 (UTC)[reply]

The feedback page is about this specific measure (double confirmation). it can be temporary, so that any existing users have a central page to complain. imagine if you always edit without login, suddenly this double confirmation kicks in and you get frustrated. you want to complain, but dont know where. so if we have a link for them to write something, and if anyone of them bothers to do, we can see how many are affected and why, etc.

once the measure becomes permanent, users should just take it as it is; no point in complaining. RoyZuo (talk) 11:51, 18 October 2024 (UTC)[reply]

We can give it a try. GPSLeo (talk) 10:30, 19 October 2024 (UTC)[reply]

I just added the regular abuse filter error reporting link with a different text. GPSLeo (talk) 16:01, 25 October 2024 (UTC)[reply]

If there are no concerns I would enable this for a first test. GPSLeo (talk) 06:35, 26 October 2024 (UTC)[reply]
I just enabled this for first test run. GPSLeo (talk) 13:19, 27 October 2024 (UTC)[reply]
I keep hitting this filter, every time I try to edit a page I keep getting this warning, which is odd. Also, we should track anonymous edits to see if this warning actually works or not, because it might just end up annoying only the productive people and not the real, actual vandals. -- Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:31, 27 October 2024 (UTC)[reply]

Almost everyone hit with this filter is a registered users with a Wikimedia SUL account, it's I barely see any unregistered users being warned at all... --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:34, 27 October 2024 (UTC)[reply]

Fixed now. I accidentally had an OR and not an AND between anon and mobile condition. GPSLeo (talk) 16:57, 27 October 2024 (UTC)[reply]

Do you think you could make it work better for "new external links" edits? Every time those happen (often when I'm NOT attempting to add an external link), I have to put in a different CAPTCHA twice for the same edit. 2603:3021:3A96:0:4E4:95C6:BC81:D2E1 21:31, 28 October 2024 (UTC)[reply]

If you get a CAPTCHA you triggered another anti spam mechanism that has nothing to do with AbuseFilters. GPSLeo (talk) 22:08, 28 October 2024 (UTC)[reply]

First results

After one week I looked at the share of reverted edits compared to all edits and it shows a huge decrease of reverted edits while the number of edits only decreased slightly [2]. When looking at the filter hits it also shows that many nonsense edits were not sent while most useful edits were confirmed. GPSLeo (talk) 08:05, 3 November 2024 (UTC)[reply]

@GPSLeo from when to when was the filter live? RoyZuo (talk) 18:09, 14 November 2024 (UTC)[reply]

The filter with current settings was activated on 16:55, 27 October 2024 and is still active. As there were no complaints I would just leave it on as it seems to have at least a small positive effect. GPSLeo (talk) 19:47, 14 November 2024 (UTC)[reply]

Notifications when one's uploaded files get used

Tracked in Phabricator
Task T77154

I think more feedback would make contributing much more fun and keep people engaged and facilitate them to contribute more, have a positive experience and remain motivated. There are several kinds of interactivity / feedback here, some already are implemented, some would be difficult to implement well, and some are probably not overly complex to implement with nearly no downsides but many advantages and high usefulness. I think is of the latter kind.

On Wikipedia, one can already get notified when pages wikilink to an article one has started. This is simply interesting to the person who created the article and encouraging.

Could similar notifications be enabled for when files one has uploaded get used on another Wikimedia project? It could show a This file {filename link} is now in use notification for either all file-uses or the first use per file.

One could enable/disable these notifications in the preferences, like on can for when a WP article is linked (and maybe at some point one could also exclude a select subset of one's uploaded files where one would like to not be notified). Inexperienced contributors don't learn when or whether their files are being used which must be pretty discouraging and boring; it also does not provide feedback which of their files is what is probably among their most useful (encouraging more of these). One can currently see which of the files one has uploaded are used by putting them all in one category and then using a tool like GLAMorgan but I don't think there's a way if one's files are not in a category and that sends a notification when (best shortly after) a file gets used. Prototyperspective (talk) 22:49, 4 September 2024 (UTC) --El Grafo (talk) 08:50, 17 October 2024 (UTC)[reply]

Support Although weakly. It's an interesting idea but I'm not to sure how useful it would actually be in motivating people to contribute to the project more. There's also already enough issues with ownership on here that I feel like this exacerbate. There's no practical reason why someone needs to be notified if one of their images is used or not somewhere. They don't really "own" or have any control over the images after uploading them anyway. Or at least they shouldn't. --Adamant1 (talk) 00:06, 5 September 2024 (UTC)[reply]
Yes, they don't need to be notified but it's encouraging further contributions and making contributing more engaging. I don't think this would exacerbate problems but there could be some issues when people feel like the media they uploaded (or created and then uploaded) is used in a 'wrong' way. However I don't think it would be a significant/big problem (very rare and then solved on the article talk page / by other editors changing it) and the advantage that they could also spot mistakes in the file caption for example could easily offset that potential problem. People can already see when their files are used and I haven't heard this caused many problems, this would just make file-uses more widely and quicker known. Prototyperspective (talk) 00:18, 5 September 2024 (UTC)[reply]
I think Jmabel asked on the Village Pump awhile ago if there was a way to search for files that are in use by a particular uploader. I feel like that would probably be a better way to do this. As I think there's a general interest in knowing who's files are being used where. All a notification does is let the person who uploaded the files know though. I don't think your whole that it would help for files that are being used "in a 'wrong' way" is really that valid either since uploaders have a tendency to be control freaks who think their contributions are being used wrongly regardless if they are or not. I could really care less if an uploader on Commons thinks a particular usage is "wrong." What matters if the person on Wikipedia's end who added it to the article and has prior experience in the area thinks it's correct. --Adamant1 (talk) 00:28, 5 September 2024 (UTC)[reply]
When it comes to complex scientific illustrations and so on people can easily get things slightly wrong. It may be rare that some correction/adjustment is due and that the uploader checks the caption and implements such but I think minor talk page drama will be even rarer as I don't think uploaders have a tendency to be control freaks and haven't seen much or even anything supporting that (and that despite that people can already bulk check which of their files are in use). I think it would probably be best if there were two checkboxes in the Preferences – one about all notifications when a file is used and one for the first use of a file – with only the latter being the default. Probably half of the time if not more often, the uploader doesn't even see the notification because they stopped using the site and uploaded the files 5+ years ago. Prototyperspective (talk) 23:14, 5 September 2024 (UTC)[reply]
I don't necessarily have an issue with it in that case and a few others, which I do ultimately support the proposal. But I still think the potential for something like this leading to more drama due to some uploaders having control issues is a problem even if that hasn't been your experience. I've certainly seem myself. Although admittedly not that frequently but it still happens. --Adamant1 (talk) 23:19, 5 September 2024 (UTC)[reply]

Two remarks:

See Glamtool GLAMorous for the use of your (or anyone else's) uploads: fill in the user name, click on Show details and Do it! So you do not need to put them all in one category for this reason.
It think this is a wish that you best can post on meta:Community Wishlist.

JopkeB (talk) 04:26, 5 September 2024 (UTC)[reply]

I think this should not be done through notifications but through the Growth dashboard that on Wikipedia already shows how often the edited articles are viewed. GPSLeo (talk) 05:53, 5 September 2024 (UTC)[reply]

@JopkeB Great, thanks – seems like I used to miss clicking on Show details with that tool. Don't know if it's a good idea to have that not be the default without any info about it on that page because "Show details" is not self-explanatory. Maybe I'll propose it in the Wishlist.

@GPSLeo I don't see a growth dashboard on Wikipedia so I don't know if that is still upcoming or only for some subset of new users. It seems to be on Wikipedia only but this is about and specific to WMC (and I would support having a similar dashboard here). Having both would be best imo where the user could choose which one to enable/use. Prototyperspective (talk) 23:26, 5 September 2024 (UTC)[reply]

Wikipedia can notify a user when an article they created is linked from somewhere.

supposedly settings can be tweaked by wmf to let the same kind of notification happen for files on commons? RZuo (talk) 14:24, 6 September 2024 (UTC)[reply]

Support I would like to know if my uploads are being independently used without periodically checking individual files or relying on external gadgets. Dronebogus (talk) 15:02, 9 September 2024 (UTC)[reply]

Support Sounds fair (had something similar in mind). Can be turned off if not needed. --PantheraLeo1359531 😺 (talk) 16:29, 10 September 2024 (UTC)[reply]

Support -- Ooligan (talk) 16:04, 30 September 2024 (UTC)[reply]

Oppose I would like to get notified about disuse as well. Otherwise this proposal sounds like unnecessary “gamification”. Good files get used. And, more importantly, remain in use. ‑‑ Kays (T | C) 07:35, 8 October 2024 (UTC)[reply]

I wouldn't be concerned about the potential issue of uploaders trying to keep their files in use or trying to control how they're being contextualized / captioned but I would be to some extent if they get notified about disuses of their files – this just invites them to change it back. On Wikipedia one also only gets notified once an article one has created is wikilinked from another one, not once the use is removed. Use-notifications could already be nearly too many for many users without adding depressing disuse-notifications on top. Prototyperspective (talk) 11:52, 26 October 2024 (UTC)[reply]

Comment this has been on the community wishlist for about 10 years now. See also Community Wishlist Survey 2016 and phab:T77154.

Limit page moves in "File talk"-namespace to users who can move files

This proposes to limit page moves in "File talk"-namespace to users who can move files (file movers and admins). For other users, there isn't really a reason to move pages in file talk namespace. Usually file movers move them when renaming files.

If accepted, a good way to implement this needs to be found (abuse filter or through user rights in Mediawiki).

This would have avoided confusing moves of file talk pages we had recently.
∞∞ Enhancing999 (talk) 21:35, 16 October 2024 (UTC)[reply]

Support. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:21, 17 October 2024 (UTC)[reply]

Support. Easy solution to the problem.--Giftzwerg 88 (talk) 06:37, 17 October 2024 (UTC)[reply]

Support - Jmabel ! talk 19:45, 17 October 2024 (UTC)[reply]

Support - that makes sense --Msb (talk) 21:53, 26 October 2024 (UTC)[reply]

Global Folk Music Collection (with Wikidata)

Dear all,

This is a very initial idea of a project to Wikimedia Commons. Let's call in "Global Folk Music Collection" (GFMC). A lot of folk music is copyright free, often marked as "trad." Among the folk musicians it is common to consider that also "new" folk music, based on traditional music, should be free and libre — by people for people.

To document and maintain this kind of intangible cultural heritage is hardly done by anyone. UNESCO is interested in this, but I do not see that they will get anything done in this field at any time soon.

Could Wikimedia Commons have a GFMC, with semantic web features, so that one could browse and search it with various properties? In the Wikidata there is the WikiProject Music and Track properties. To serve the CFMC, there should be more properties, such as location, cultural environment, instruments etc.

How would this then work from the editor user's point of view:

I walk in Dublin and hear some very cool pipe playing by a street musician.
I ask the musician, may I record it and share it online.
The musician say yes, but asks me to share it with his name name.
I got to Wikimedia Commons and share the recording to the GFMC.
Later my friends, a musicologist, will describe it with the properties.

How would this then work from the reader user's point of view:

I got to Wikimedia Commons and search for "Irish Folk pipe music".
I'll find the pipe recording made in Dublin.
I check the metadata and the GFMC-portal and find more folk music.

From here you may replace "Dublin" with "Lagos" or whatever.

Some national libraries also have collections of folk songs and sounds samples of traditional instruments. I assume they could be interested in to share their content to the GFMC, too.

One technical thing that might be missing at the moment is universal identifier of music samples / songs. Spotify etc have their own but not free /libre identifier. Maybe this is more WikiData -thing, but could be something the Wikimedia Commons community could work together with the WikiData, wizards.

Peace,

- Teemu (talk) 11:57, 17 October 2024 (UTC)[reply]

@Teemu: What does the first "C" stand for in CFMC? Obviously not "Global". - Jmabel ! talk 19:47, 17 October 2024 (UTC)[reply]
Typo. I'll edit. Teemu (talk) 15:45, 19 October 2024 (UTC)[reply]
The process you describe "from the editor user's point of view" does not even approach Commons standards for a release by the piper. The piper owns copyright on his or her performance; oral communication to one person is not by any means sufficient documentation of a free license. Compare COM:VRT. - Jmabel ! talk 19:57, 17 October 2024 (UTC)[reply]
Fair enough. How about having in your phone (the recording device) a form/contract where the piper signs with her finger to gives it for commons under free licence?

With a team, we are considering to build an app for the purpose and considering where the audios should be stored. Do you think Commons would not be a good place for this? Teemu (talk) 15:52, 19 October 2024 (UTC)[reply]
In my experience, most "folk" performers have little idea of the copyright status of works they perform. To take two famous examples:
1. The Carter Family recorded "Wildwood Flower" thinking it was a traditional Appalachian song. It was not: it was a parlor song from about 50 years earlier, still in copyright at the time (though not now). BTW, somewhere along the way someone had misunderstood a lyric, and "the pale oleander" had become "the pale and the leader".
2. The Weavers recorded "Wimoweh", thinking it was a South African folk song. It was not: it was a South African pop song, barely a decade old at the time. It took a long time for the songwriter to get any of their rights restored.

This is potentially a problem for anyone doing field recordings of material where they do not themselves know the background in any detail. - Jmabel ! talk 20:04, 17 October 2024 (UTC)[reply]

True. What would be a solution to solve the challenge? Teemu (talk) 15:53, 19 October 2024 (UTC)[reply]

I guess what I'm saying is that Commons may not be the most suitable venue to gather primary source materials with potentially complex copyright issues.

In your example above about "a form/contract where the piper signs with her finger", do you really think that is informed consent, suitable for a contractual waiver of rights? I sure don't. Oral culture materials gathered casually on the street are always going to be tricky in terms of rights. I think you'd do really well to look closely into academic protocols around consent for such materials before trying to propose something here. - Jmabel ! talk 13:01, 20 October 2024 (UTC)[reply]

Dear @Jmabel I am very aware of informed consent practices in social science and humanities and research ethics in academic context in general. I am truly sorry if my proposal hurt your feelings. Thank you for your feedback. We will promote the idea with other communities. Peace! Teemu (talk) 10:47, 10 November 2024 (UTC)[reply]

@Teemu: what on earth made you think my issue here is hurt feelings? I will reiterate and say what I said, less politely and more clearly: Commons is not a suitable venue to gather primary source materials with potentially complex copyright issues. - Jmabel ! talk 18:39, 10 November 2024 (UTC)[reply]

Thank you @Jmabel. I guess I miss interpreted this: “. . . before trying to propose something here”. It sounded very emotionally loaded for me.

What I do not agree with, is your statement:

“Commons is not a suitable venue to gather primary source materials with potentially complex copyright issues.

Commons, as a media file repository for educational media content is exactly a “venue to gather primary source materials” It is also true that related to most of these materials there are “complex copyright issues”.

I am, however, thankful that you expressed your concerns and we will pay attention to them when we progress the project with other communities. 2001:14BA:6EC3:9100:B06C:5520:FBA4:C190 03:31, 11 November 2024 (UTC)[reply]

Reminder to login when editing. All the Best -- Chuck ^Talk 04:33, 11 November 2024 (UTC)[reply]

Proposal for Image guidelines: Focus and DoF

(This was originally posted to Commons talk:Image guidelines and has been slightly reworded for clarity).

On the page Commons:Image guidelines, at the section "Focus and depth of field" I would like to propose a third bullet point be added below the two that are already there. So the section would read as follows:

Every important object on the picture should be sharp, considering the idea of the image.
The overall image should have clearly defined focus, for example, the main subject is in focus and the foreground and background are out of focus, or else, the whole scene is in focus.
Some allowances should be made for macro photography, which often involves a very shallow depth of field. While focus stacking can be used to overcome this for static subjects, it may not be practical for dynamic subjects like insects.

The example photograph in this section File:Butterfly Luc Viatour.JPG is described as having correct focus and depth of field. However, by today's standards, it would not meet QI criteria, as the left edge of the butterfly's wing is out of focus. This seems to go against the intent of the first bullet point, so it would be beneficial to make the guidelines more explicit. ReneeWrites (talk) 20:20, 17 October 2024 (UTC)[reply]

Agree. At a minumum. And "important" in the first bullet point strikes me as odd. Obviously, if I photograph a person in a group at F/1.8, they will be in hard focus and probably no one else will be. It doesn't mean they are less important, just that they are not particularly the subject of my photo. - Jmabel ! talk 17:05, 18 October 2024 (UTC)[reply]

In your example, the other people would not be "important" for that photo. For my understanding, this doesn't mean that they are unimportant people. Maybe re-word "Every important object" to "Every object important for the composition". Plozessor (talk) 18:16, 22 October 2024 (UTC)[reply]

File:Owl WTP.jpg

The image file, File:Owl WTP.jpg, must be uploaded onto either Wikimedia or Wikipedia, preferably Wikimedia, by someone who has an account. Oh, and in case you're wondering, it must be a picture of Owl from the Disney Winnie the Pooh franchise. There aren't any images of Owl from the Disney Winnie the Pooh franchise on Wikipedia, nor Wikimedia, for that matter. I need it for my draft article I'm working on Owl from "Winnie-the-Pooh". I need an image of Owl from the Disney Version of Winnie the Pooh. 2601:401:4300:3720:4012:96F7:7F93:BA7A 16:37, 22 October 2024 (UTC)[reply]

Oh dear. This could be problematic. This is Wikimedia Commons which only hosts freely licensed files. I am presuming that as Disney holds the copyright to the Owl character we can't host the photo here.

Category:The Many Adventures of Winnie the Pooh (film) is what we have so far and Commons:File requests is really the most appropriate place for your request if you are looking for a free file.

Some Wikipedia projects like English Wikipedia do host Non-free content, eg at the top of w:Gopher (Winnie the Pooh). But an article needs to exist, not just as a draft, before a fair use file can be uploaded there (as far as I know). I recommend you wait until your draft is made an article then request for the upload on English Wikipedia. Commander Keane (talk) 17:30, 22 October 2024 (UTC)[reply]

Style guide for templates

I want to propose that we create a style guide for templates. All regular templates must follow this guideline. User templates (when used in non user namespace) should follow this guideline.

Here is the draft for the rule set:

Templates must only use the predefined colors for the style codex with a fallback for legacy skins. Exceptions are possible if there are good reasons for.
Red and yellow background and border should only be used for templates they are usually only temporary on a page except for talk pages.
Text color should not be changed. Supplementary information can be in a more subtile gray.
Templates must not alter the default font-family. Font size should only be altered if the template contains a heading for the heading. Text decorations should only be used if really necessary.
Margins between box content and box border should never be more than 1.5 text height on top and bottom.

Are there any suggestions for changes of these rules or additional rules? GPSLeo (talk) 07:01, 26 October 2024 (UTC)[reply]

What does the following mean "Font size should only be altered if the template contains a heading for the heading." and how would it impact {{Wikidata Infobox}} that does alter the text size?
∞∞ Enhancing999 (talk) 09:37, 26 October 2024 (UTC)[reply]

The Wikidata Infobox is a very special case where I would make an exception. GPSLeo (talk) 10:43, 26 October 2024 (UTC)[reply]

Can you still explain how it would impact that infobox? There isn't really a point in drafting a "style guide" if no category follows it.
∞∞ Enhancing999 (talk) 10:48, 26 October 2024 (UTC)[reply]

It is only a guideline and not a strict binding policy. If we think one template that is not conform with the guideline is fine we do not have to change it. Except from the use of the predefined colors most templates already follow this guideline and the most widespread templates are also already adapted to use the predefined colors. This is just to make the de facto guideline and official written guideline. GPSLeo (talk) 11:15, 26 October 2024 (UTC)[reply]

I asked you about the font-size, not colors or the binding nature (which you forgot to include in the draft). If you can't explain how the "heading" thing is meant to work, I think we should remove it from the proposal. It will only create problems if we have to sort it out later and someone insists on some "must"-guideline that wasn't even understood when proposed.
∞∞ Enhancing999 (talk) 12:36, 26 October 2024 (UTC)[reply]

@GPSLeo: "must" is a bit strong (and a bit passive). What are the consequences for failing to do this? - Jmabel ! talk 11:00, 26 October 2024 (UTC)[reply]

I just wrote "must" as I think "should" would be a bit weak, but maybe adding a sentence that exceptions are possible would solve this. I would say the users have to accept that their templates are changed by others if the template does not follow the guideline. We should not sanction anyone for accidental or minor violation of the guideline. The only reason to punish a user for not following this would be if they do not accept the changes done to the template and start and edit war. GPSLeo (talk) 11:09, 26 October 2024 (UTC)[reply]

I want to go back to the idea that everybody can contribute with your own creativity without unnecessary restrictions. There is no real need to regulate the creativity of our contributors just to satisfy the special taste of one or some users that prefer a certain look or way of doing business. I think it is not helpful to have some kind of rule book hanging over your head when you want to find a way to improve or simplify the process of presentation of information. So we need to allow new creative styles and different ways of doing things. Then we as a community have a look at it and can see how it works, if it works and what the advantages and disadvantages are. Then we come up with possible incremental improvements or we can reject it as a result of the discussion. We should rely on our strength as a collective intelligence and let play out the group dynamics as far as possible. So, when you come up with rules there must be a necessity to do so. We do not want to end like some home owners associations where everything needs to be regulated, with rules how high the fence must be and what colour the mailbox and what you can plant in your garden and which kinds of signs are allowed. So we need to let users try out their ideas and aesthetics, their fonds and styles or whatever and let the community decide if we need to put limits or boundaries if it gets somehow disruptive or if we need some cut back or containement. We need to have different options and make our choices. Wikipedia and commons alike only exist, because we believe in incremental improvement instead of a preexisting solution to everything. So rules should be discussed and implemented based on the solution of a problem. So this answer is "bigger potatoes", but what was the question?--Giftzwerg 88 (talk) 11:42, 26 October 2024 (UTC)[reply]

The main reason why we should have some guidelines is the dark mode that is already available. When we offer a dark mode templates with a fixed white background should not exist as on them the text will not be readable anymore. And even if the text color defined in a way visible the large white box on the page will look disturbing. The other parts of the proposal are to write some unwritten rules down. We never had problems with users putting a large red box on ever of their uploads. But if this would happen we would not have a good basis to stop the user from doing this. The other argument is that end-users expect a consistent design over a hole website and will have problems to find what they are looking for when every page looks totally different. GPSLeo (talk) 16:27, 26 October 2024 (UTC)[reply]

Deleting empty categories

I recently asked whether there is a page about empty categories and since apparently there is no I created Commons:Empty categories. Please comment or edit if there's anything to add.

I'd like to propose that all empty categories older than several months (3, 6, or 12) are deleted. This would need some bot or script doing this large-scale as there are many thousands of them. Could this please be done?

Excluded would be:

Redirects
Disambiguation pages
Maintenance pages
Pages soon to be populated such as cats that are part of a natural series with a cat for every year or for campaigns set up before the campaign because the category would still be empty after 3-12 months

All of these pages could be excluded in the query. Moreover, even if a small number of empty categories are being deleted in accordance with SC2 despite being not unlikely to be populated soon then it's simple to just recreate them while these empty categories are a problem and the benefits of deleting them clearly outweigh that a handful of recreatable categories have been deleted which could have been tagged for speedy deletion anyway.

A main issue with empty categories is that they don't have a NOINDEX magic word and so could be indexed – and maybe frequently would be if WMC cat pages were indexed better in general like they should be. This is one of the main problems with empty categories. Other issues include that they make pages harder to oversee / clutter pages and that when linked to Wikidata items give the impression that there's media here about the subject but lead to just an empty page. They can also cause category cycles. I don't see any good reason to keep them which is probably also why it's a speedy deletion criteria.

Proposed steps:

Identify any potential complications with implementing this other than the ones already in "Special types of empty categories" in the page linked (maybe some maintenance categories do not have {{Maintenance category}} and/or {{EmptyCatGood}} set which should soon put them into Category:Maintenance categories) and fixing these issues
Adjust the Quarry query for empty categories below so it returns all empty categories that should be deleted
Use the query output to then delete them in some way, maybe with a bot adding the speedy delete notes a week before deletion and then deleting all the still empty ones or deleting them directly with some mass-delete tool/script

How could each of these steps be done? Especially the third one seems to need some work (technical development).

Here's the Quarry query for all empty categories (without redirects and disambigs): Quarry:query/7200. It shows there are really many empty categories.
Prototyperspective (talk) 16:11, 26 October 2024 (UTC)[reply]

I would say that every category that has a Wikidata item linked should not be deleted if empty. This does only not apply when it is not simple to make photos to populate the category. This is the case for:

Past events
Events further in the future than 1 year
Dead people
Artworks still in copyright
Not photographable with regular equipment (e.g. most asteroids, planets)

All empty categories they are not linked to Wikidata for more than one week should be deleted. We have a huge problem with new users failing to add proper categories. Having empty categories linked to Wikidata could make this much more easy for new users. A category linked form Wikidata should not give we impression that there might be files about the item when the item has no photo linked. If there are photos in the category but no photo on the item that is a different problem that is easy to solve with tools already existing. GPSLeo (talk) 16:45, 26 October 2024 (UTC)[reply]

Aren't empty categories linked to Wikidata items even more problematic: they give users the impression that there's media on Commons when that isn't the case. If they come here and don't know the site well they'd be confused and see an empty page wondering why that Wikipedia linked to it. I think empty categories linked to Wikidata items are more problematic than empty categories not linked to from anywhere other than their parent categories. Btw, there are many cases where there's files in the WMC categories but none of them is suitable for being linked in the Image property of the Wikidata item which should contain only somewhat representative/useful files. Whether it should is not relevant to whether or not it does. Prototyperspective (talk) 16:51, 26 October 2024 (UTC)[reply]

Not really, there are lists at Wikipedia that help users upload photos directly to the correct category.
∞∞ Enhancing999 (talk) 16:54, 26 October 2024 (UTC)[reply]

These cases are excluded by all empty categories older than several months (3, 6, or 12) are deleted. Moreover, these tools (link?) could also set a redcategory and/or create the category automatically/request its creation after there is a file. I don't think empty categories are used for that anyway. Prototyperspective (talk) 16:56, 26 October 2024 (UTC)[reply]

I don't see how the creation date has anything to do with that. Not sure how doing maintenance on red categories instead is an advantage.
∞∞ Enhancing999 (talk) 17:16, 26 October 2024 (UTC)[reply]

If you argue (still without any substantiation) that these help users upload photos directly to the correct category then there would be files in them after 3, 6, or 12 months. Well then create the category at upload but I don't think this is an actual scenario, not even a niche rare one. Prototyperspective (talk) 17:36, 26 October 2024 (UTC)[reply]

But then we need a way to store the intended category name and the parent categories for this category on Wikidata. And we need an automated process that creates it and links it when added in the UploadWizard. GPSLeo (talk) 17:51, 26 October 2024 (UTC)[reply]

It seems to be already stored if an existing category is selected so it wouldn't really make a difference. In any case this varies or depends on the actual thing discussed so a link would be needed. I still think nothing of this sort actually exists. Prototyperspective (talk) 20:39, 26 October 2024 (UTC)[reply]

I think the main problem are malformed empty categories (we deleted hundreds of them). Once categories are linked to Wikidata, this is considerably less problematic. I think the current speedy deletion policy captures the situation fairly well.
∞∞ Enhancing999 (talk) 16:51, 26 October 2024 (UTC)[reply]

Why would it be less problematic? See my comment above: it leads users to a useless empty page by being linked from Wikipedia and possibly search engines. There is no use in having a Commons category that is empty linked to a Wikidata item. Prototyperspective (talk) 16:52, 26 October 2024 (UTC)[reply]

You could easily navigate to parent categories and find files there.
∞∞ Enhancing999 (talk) 17:17, 26 October 2024 (UTC)[reply]

Often times the files are for things that the person isn't looking for to begin with though. So how exactly is that helpful? --Adamant1 (talk) 17:36, 26 October 2024 (UTC)[reply]

Good point. Users on mobile still do not even see these however. Also I think for these cases something other could and should be done. For example, in Wikipedia pages there may be several images and one can open them and then navigate to their categories. Prototyperspective (talk) 17:37, 26 October 2024 (UTC)[reply]

We know we need to fix categories for mobile users, but that isn't really a reason to delete all categories before.
∞∞ Enhancing999 (talk) 17:39, 26 October 2024 (UTC)[reply]

In such cases it would be better to link to the parent category on WMC directly in the Commons category template. Prototyperspective (talk) 20:37, 26 October 2024 (UTC)[reply]

Support I don't really get the argument for keeping empty categories just because there's a Wikidata item associated with them either. For one it makes it seem like we have media for subjects that we don't and secondly it puts the onus for it's do things in Commons or not on Wikidata users. Which wouldn't be that much of an issue, but there's absolutely zero standards what-so-ever on Wikidata's for what deserves to have an item or not. So essentially anything could have a category on Commons regardless if there is or ever will be media related to it on our end simply a random user of Wikidata decided to create an item for it. No one on here is served by hundreds of thousands of empty categories that will never be used to organize media and/or can't be deleted. If anything there should be more rules on when and under what circumstances it's OK to create categories, not less. --Adamant1 (talk) 17:36, 26 October 2024 (UTC)[reply]
But where do you propose to store the information about the relevant parent categories if the category itself should not exist until it is used? GPSLeo (talk) 17:59, 26 October 2024 (UTC)[reply]
Parent categories are not hard to find and it's not important to store parent cat info of cats that are empty anyway and would be deleted on sight by a user who thinks of speedy-delete-tagging it. There can be innovation around media requests (as in please create a category about x; suggested parent cats: yz) and this would be enabled or boosted by deleting empty cats. Prototyperspective (talk) 20:36, 26 October 2024 (UTC)[reply]
I am admin on Commons and for me it is often complicated to find the correct parent category. In most cases I use Wikidata to enter the category tree near the place I am looking for. From my patrolling work and when talking to new users I know that they do not know how to handle the category system. If we have a Wikidata item about something we should use this data. This could of course all be done by some fancy software. But we do not have this at the moment and the WMF will definitely not help us getting such a tool. Or we just use empty categories to solve this problem. The long term goal is to replace categories by structured data anyway. GPSLeo (talk) 20:47, 26 October 2024 (UTC)[reply]
If we have a Wikidata item about something we should use this data Sure, agree. After creating a category, contributors can check the wikidata item if it has relevant data. This could of course all be done by some fancy software. It's already done by the Wikidata Infobox and I supported a current proposal to make it auto-add more categories and there could be more cats that it auto-adds. we just use empty categories to solve this problem Empty categories don't solve any problem whatsoever. Their categories are often flawed anyway and they may never be populated ever or are empty because they are flawed to begin with and shouldn't be populated. Structured data is not used and not nearly as useful as categories. Where structured data exists, it's usually because categories were copied to structured data or because the uploader entered the same data twice once for categories and once for SD. Less often but still very often they contain flawed or overly broad data such as depicts "building" or depicts "human". And in nearly all cases it contains not even 3/4 of the metadata specified in categories. Prototyperspective (talk) 21:15, 26 October 2024 (UTC)[reply]

@GPSLeo: Maybe I'm just being dumb here but I can't image an instance where that would be a problem. Like if someone is looking for a category related to brown cars and it doesn't exist the obvious thing is to look for a category based on cars by color or just cars. Although I will caveat that by saying there some instances where categories take abrupt right turns sometimes but that's an issue with how people create categories more generally and doesn't really have anything to do with this IMO. So can you give an example of what your talking about? --Adamant1 (talk) 00:22, 27 October 2024 (UTC)[reply]

Question what problem are you trying to solve? Category cycles aren't possible with empty categories.
∞∞ Enhancing999 (talk) 17:56, 26 October 2024 (UTC)[reply]

The main thing was that these pages are not no-indexed and the spiders may not distinguish between categories that are empty and those that aren't which could cause issues for the presence of WMC in search results overall. There are further things like empty categories filling backlog reports and HotCat autocompletes. Some of them may also fill category pages making things hard to see and such cases would be solved by this even when there's usually only a small number of empty cats in a cat if any.

I'd say it's not important to me at all and it may not be worth doing or not now despite that there's no good reason not to...but then please make empty categories noindexed. It's not a priority issue but reducing the noise and reducing the really large number of categories by a significant number seems like a good thing to do.

Good point about the category cycles, e.g. categories containing just an otherwise empty subcategory containing itself wouldn't be considered empty. Prototyperspective (talk) 20:30, 26 October 2024 (UTC)[reply]

You want to hide the missing content. But the information what is missing is the most important as we want to fill these gaps. GPSLeo (talk) 20:53, 26 October 2024 (UTC)[reply]

Exactly. And this is why we need a proper media request system. No, I don't want to hide that and empty categories are not the right way for that (including being entirely ineffective in regards to that). Prototyperspective (talk) 21:05, 26 October 2024 (UTC)[reply]

Question how do you intend to make the thing about 3-12 months work? Consider the following scenario: Category:Night markets in Singapore was created in2009 and has 17 photos. Let's say a vandal removes the category from all of those photos. How does the bot know this is a recently emptied category rather than a 15-year-old category that has never been used? - Jmabel ! talk 18:40, 26 October 2024 (UTC)[reply]

Good point. It's because vandals don't know that and when such a trimming would occur and the very few cases where something like this happens the category can simply be recreated (in this case: 1. revert that user's diffs 2. notice the redcat 3. recreate it using the similar Category:Night markets in Cambodia). Prototyperspective (talk) 20:33, 26 October 2024 (UTC)[reply]

On rare occasions I created a category that I intended to fill but forgot to use when later uploading the photos. Sometimes empty categories are duplicates to other categories, then they should be turned into a redirect. I have never experienced a problem with an empty category whatsoever. On the other hand you can give pictures a category that does not exist and when you click the link you still see all the pictures in that category. I wonder how many of these exist and they are hard to detect, because you can not find them with the search tools or in the category tree. I consider that a problem--Giftzwerg 88 (talk) 20:44, 26 October 2024 (UTC)[reply]

Deleting empty categories would help there in making people add the actual category instead of the empty duplicate one. Empty categories are not a big problem. Many thousands of them exist. Nonexistent categories is a different separate subject. One can also create a query to see these but those containing more than x (14 I think it was last time I checked) number of files are in Special:WantedCategories. Prototyperspective (talk) 20:51, 26 October 2024 (UTC)[reply]

The duplicate category problem is solved by the requirement of linking them to Wikidata. Then there are only duplicates if there is a duplicate on Wikidata. GPSLeo (talk) 20:55, 26 October 2024 (UTC)[reply]

An estimated 90% of categories are not linked to wikidata. If the remainder, that is tens of thousands of categories, were linked to a Wikidata item, then the problem would simply exist on both sites rather than just on one which is not an improvement. Secondly this is unrelated or at most tangential to the subject/thread. Prototyperspective (talk) 21:08, 26 October 2024 (UTC)[reply]

What is the current policy about Wikdata items? Is it desirable to have an item for each commonscat? I am a fan of infobox wikidata and use them often but not for all categories. For example I would not use it for something like Category:Rivers of Landkreis Böblingen or Category:Automobiles at Motorworld Region Stuttgart but definitely would use it for each individual river or water body. A lot of these categories are just to divide the material by administrative boundaries or by years or other artificial criteria.--Giftzwerg 88 (talk) 00:06, 27 October 2024 (UTC)[reply]

Totally personal preferences here, but IMO there should be a Wikidata item for "main subjects" (however you want to define that). It would be super pointless and obtuse to have a Wikidata item for every single minor category and/or subject on here though. Especially when if your talking about intersectional categories involving multiple characteristics. Generally though, I'd say the more obscure and less likely to be stable a category is then there's less point in having a Wikidata item for it. There's zero point in having Wikidata items for categories that have a large chance of just being deleted. --Adamant1 (talk) 00:35, 27 October 2024 (UTC)[reply]

@GPSLeo: I run into instances all the time where a category is empty due to the media that was previously deleted as either COPYVIO or OOS. Plenty of them had Wikidata infobox to. Regardless, what would be your solution in an instance like that? In both cases there's essentially zero chance of there ever being media to put in the categories. So should we just keep inherently empty categories for subjects that are clearly COPYIO and/or out of scope simply because they are notable enough for a Wikidata item? --Adamant1 (talk) 00:29, 27 October 2024 (UTC)[reply]
The first case was already in my list of exceptions where a category should be deleted. In the second case the Wikidata item is out of scope and therefore there will be no Infobox after the item is deleted. And I also would nominate the item for deletion and delete the category with its content in parallel. GPSLeo (talk) 05:41, 27 October 2024 (UTC)[reply]

Hm. Useful empty categories were removed as a speedy deletion reason a while ago; discussion at Commons talk:Criteria for speedy deletion/Archive_2#Speedy_deletion_of_**empty**_categories. There can be categories with substantial content in them (categorized in other places, or some researched text) that seems callous to just delete, if there is a reasonable chance that the categories will be re-populated again (maybe once the files once inside have their copyright expire, or other ones found -- undeletions happen too). There are likely many ship categories in that state, and I'm sure many other examples. I'm sure there are many examples of empty categories which should be deleted, but also many examples of ones which should be kept, and not sure automated deletion is a good idea. Maybe if there is minimal content in empty categories -- but then again, that older discussion lists several reasons to keep certain empty categories and not sure there is a way to really automate those distinctions. For duplicate categories, definitely prefer redirects to deletion, unless there was an outright mistake in the category name. For the most part, I have not seen big issues with empty categories. They are mildly annoying but deleting other people's work for the sake of a little cleanliness does not seem like the right approach. The argument that they are easy to recreate falls flat to me -- some of them have quite a bit of categorization or text on them. A report showing old, empty categories for more careful human review may make some sense. If the wiki software could be made to no-index them when there are no files and no visible text, I could see that. Carl Lindberg (talk) 01:20, 27 October 2024 (UTC)[reply]

Create a noratelimit user group

This group would have the noratelimit user right per COM:BN#Rollback rate limit increase for Alachuckthebuck. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:00, 30 October 2024 (UTC)[reply]

I have some concerns:

who will be granted this right and when?
who will be able to grant this right?
if this is for a one-time case or a rare-issue, don't you think it is odd to have this group created when "bot" can be utilised?

As such I don't think this would be a good-to-go idea. _Regards,Aafi ^(talk) 14:14, 30 October 2024 (UTC)[reply]

@Aafi: The group membership would be granted to applicants by Bureaucrats, or possibly by Admins if the community deems that advisable. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:26, 30 October 2024 (UTC)[reply]

and "when" - I mean what are the factors that would determine the need of such a user right? To override rate-limit means only to do things at a bulk rate which is otherwise impossible for a human editor. There is a visible collision between a bot's job & the noratelimit edit's being done by a human! _Regards,Aafi ^(talk) 15:35, 30 October 2024 (UTC)[reply]

What are the cases for having no rate limit they do not require bot approval? In the given case I also think that massively correcting bad bot edits should also be marked as a bot edit. GPSLeo (talk) 14:14, 30 October 2024 (UTC)[reply]

+1 Krd 14:20, 30 October 2024 (UTC)[reply]

@Krd: Does your "+1" apply to my proposal or to GPSLeo's reply? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:28, 30 October 2024 (UTC)[reply]

@GPSLeo: Would the bot need approval for the use case presented by Chuck? If so, he should file a bot request. If not, I can use my bot for this use case. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:23, 30 October 2024 (UTC)[reply]

Yes as doing many thousand automated edits is the definition of a bot. If it is about fixing around 3000 files waiting for 30 minutes would also be fine. GPSLeo (talk) 14:29, 30 October 2024 (UTC)[reply]

I would argue that the best way to handle this would be having something similar to the Flooder right, but for non-admins.

The userright (Flooder) has only one permission: the addition and removal of the (Flooder Flag) userright. The permissions of the Flag are edits marked as bot, and the removal of rate limits. The flag is removed automatically after 24 hrs. Usage of the right is only allowed after a bot request (or similar) with approval for the exact task the flag is used for. Running a bot along the lines of what took me 5 hrs (without ratelimits) would be impractical, and also take even longer than cleanup already took. All the Best -- Chuck ^Talk 15:54, 30 October 2024 (UTC)[reply]

Flooder seems doable. _Regards,Aafi ^(talk) 16:16, 30 October 2024 (UTC)[reply]

If we have a bot request, we can assign the bot flag. This discussion is about a non-problem. Krd 16:18, 30 October 2024 (UTC)[reply]

@Krd, doing 35k rollbacks took me about 5 hrs. programming a bot, getting approval, debugging, then doing the run, and likely handling cleanup, is a 3-5 week project, assuming no problems with programing or regex. And once the run starts, it would still take 5 days at 6 epm. Or we create the Flooder right and do it in 5 hours. All the Best -- Chuck ^Talk 16:24, 30 October 2024 (UTC)[reply]

Which we did, didn‘t we? So what exactly is needed in addition? Krd 16:42, 30 October 2024 (UTC)[reply]

You wanted mass fixes like this to be bot edits, so I proposed a way to have the benefits of it being done by a user (being done in 5 hrs), and the beniefits of the bot flag (easy filtering, not breaking RTRC). My proposal would allow me to have the flag for the reverts, and remove it when done. Everything's under one account, and done in a fraction of the time a bot would take. All the Best -- Chuck ^Talk 16:58, 30 October 2024 (UTC)[reply]

I would have liked to avoid bringing up the point, but a question IMHO way more relevant than the details how it actually was rectified, is why a bot operator can do 35k wrong edits and is not able to fix them by his own bot, and if is this is a good situation. Will this happen again? If not, why can't we just stop and go back to business? Krd 17:26, 30 October 2024 (UTC)[reply]

This whole saga is over using the word "the" in the category titles of a Danish GLAM. The were uploaded without "the", then WLKBot added "the" to all categories, and created needed categories, I rolled back to no per the AN thread, and when I finished, a not was posted to my talk, informing me that consensus has changed, and I was requested to undo my edits. I declined, as cat-a-lot will work for this purpose, and if not, AWB can handle it. @Kim Bach, You have some explaining to do. All the Best -- Chuck ^Talk 21:07, 30 October 2024 (UTC)[reply]

Indeed, a user had opposed the naming convention, "in the" instead of "in" that is commonplace for a number of other GLAMS. I decided, completely wrong, to run a mass edit to fix this problem, when I discovered that this was in error, I requested the rollback, which I think was the right think to do.

I realise that this has wasted a lot of time, this is indeed a fiasco, and 100% my mistake. Kim Bach (talk) 11:22, 1 November 2024 (UTC)[reply]

If we talk about such a group, I think flooder is a doable job. On Wikidata, Flooders have the "bot" permission alongside the ability to remove themselves from the group. _Regards,Aafi ^(talk) 16:24, 30 October 2024 (UTC)[reply]

Automated tools would need to follow mw:API:Etiquette. For example mass editing bots will need to follow if there is load on the server and slow down if there is. For example when en:User:Writ Keeper/Scripts/massRollback was used to revert the 35k edits in yesterday was doing it in unlimited rate, which was 50-100 edits per second, without slowing down when server could not keep up. This is way too high and could cause similar problems than what for example Cat-a-lot did before it was changed. --Zache (talk) 18:56, 30 October 2024 (UTC)[reply]

The script was meant to Mass rollback edits made by vandalism only accounts (50ish edits) and be used once a day. I used it to roll back 35k edits in batches of 1500(give or take 300 edits due to page creations) . I ran a batch every 60-90 seconds. I will modify my local copy of the script to slow down to a more reasonable speed. I also don't see this method of rollback being used at this scale ever again, as a bot to do this kind of cleanup is needed. That doesn't change the need for this right, and the legitmiate points raised by @Krd and @Aafi. All the Best -- Chuck ^Talk 20:45, 30 October 2024 (UTC)[reply]

Most of usecases are such as it feels to me that it would be used workaround ratelimits in a way that it should not be done. Most clearest examples are tasks would be using Help:VisualFileChange.js to editing large amounts of categories in highspeed. Another note is that admins and bots have noratelimit already and it is actually little bit hard to see what would be the use cases where it would be used (and if the idea is to allow rollbacks to be done in higher speed why not just bump up the rollback limits) --Zache (talk) 05:59, 31 October 2024 (UTC)[reply]

If rollbacks are being done in any quantity near the rollback limit (100 per minute), there should already be consensus for the action. If you need a higher rollback limit, then there should be another request and comment period, that's how we avoid another situation like this. I'm working on a solution to the problem, should be ready to go in the next few days, and is adaptable to do future fixes, and slowly. Sorry for wasting everyone's time with this mess. All the Best -- Chuck ^Talk 16:33, 31 October 2024 (UTC)[reply]

Oppose Per Zache, Aafi, and others. This mostly just seems like a workaround to rate limits and from what I can tell most or all the people who benefit from it already have other avenues to get around the limit if they really want to anyway. --Adamant1 (talk) 20:04, 31 October 2024 (UTC)[reply]

Oppose per above arguments Bastique ^{☎ let's talk!} 20:22, 31 October 2024 (UTC)[reply]

Comment: I bit the bullet, and with some help from @Schlurcher, Have a bot request at com:bot requests#chuckbot. All the Best -- Chuck ^Talk 06:16, 1 November 2024 (UTC)[reply]

Oppose a separate group, but Support deprecating account creator in favor of this.

ACC is already a back door version of this – only two ACCs mentioned account creation when asking for/being granted it (emphases mine).

Alachuckthebuck – I'm working on cleaning up User:WLKBot's contribs using massrollback, but am running into the (normally gracious) 100 rollbacks per minute limit. Is there a way to remove this limit on my account for the next 3 days or so?
Alexis Jazz – I need the account creator (noratelimit) right. I simply can't do my work anymore due to Phabricator: Ratelimit on Commons is way too aggressive/broken.
D. Benjamin Miller – Dear bureaucrats: I am a filemover and would like to be given the status of account creator; I find that when working through rename queues I often run into the ratelimit and would like to get around this restriction, please.
Effeietsanders (granted by a steward) – for bypassing email rate limits and account creation related to WLM
QueerEcoFeminist – I frequently move pages and I have got stumbled upon ratelimit several times. (Sorry I don't know if there is any log to check it!) And I am also involved in real life wiki activities like trainings around wikimedia projects including commons. So account creator right would be great help to me.
Sandro Halank – noratelimit per request (don't know where said request was, don't see anything in BN archives)
Xaronim – That can be done as well but might need a flag that has a higher rate limit, tried 120 edits and was stuck for a good 15 minutes. (alternative account of Minorax, initially planned to be a bot but became a semi automatic account)

Queen of Hearts (talk) 08:36, 1 November 2024 (UTC)[reply]

Oppose per above. Bedivere (talk) 02:39, 2 November 2024 (UTC)[reply]

Advanced rights and moderation task demand announcements

In all discussions about requests for rights for Bureaucrats, Oversighters and Checkusers there is the question if there is a demand for more people with these rights. Therefore I propose to set up a page where the users who currently have this right announce their demand for help going form "we are to many for the work" to "more people critical needed". They should update the demand at least every six month (if there is no change confirming that there is no change). This page could also include the demand on the different admin and some non admin rights requiring maintenance task like: Deletion requests, speedy deletion request, user disputes, vandalism and page protection, patrolling, image reviewing, answering new users questions. This would help for users who are willing to help with maintenance tasks to see where there is a demand for help. GPSLeo (talk) 06:53, 8 November 2024 (UTC)[reply]

Support Why not? Although it does seem like we could use another Oversighter and another Checkuser since there are only 3. Abzeronow (talk) 20:53, 10 November 2024 (UTC)[reply]

Support per Abzeronow. Can we make it a template/userbox similar to wp:Pending Changes backlog-defcon? All the Best -- Chuck ^Talk 01:32, 11 November 2024 (UTC)[reply]

Support This looks reasonable. --Yann (talk) 19:05, 12 November 2024 (UTC)[reply]

Why a new page? just shoot the msg at vp. and Category:Commons backlog and Category:Commons admin backlog are here. RoyZuo (talk) 18:18, 14 November 2024 (UTC)[reply]

Prioritize support for the upload of DNG (RAW) image files

So, this proposal is not new by a long shot. Such proposal was roughly approved in 2009 with a ticket created shortly after and it remains open. There are no significant technical hurdles to implementing this, since DNGs usually include embedded RGB thumbnails that would allow for easy visualization in browsers.

DNGs should be used in Commons and I'm not going to go into too much technical details on why, except to say: RAW images are by far the most efficient and compact way to preserve as much detail as possible of a photograph. Nearly all digital cameras capture just one color (red, green or blue, alternately) for each pixel, usually in 12 or 14 bits, and then creates an RGB image by combining that pixel's information with that of its neighbors in a process called demosaicing. Most images (JPGs, for instance) and most color monitors store and display only as much as 8 bits per channel (R, G or B), generating 24 bits-per-pixel images. Those images are then often compressed in a "lossy" way, that is, information that doesn't impact how an image looks to the human eye gets thrown away for the sake of file size economy - and that's why 24 bits-per-pixel JPGs are usually smaller than 12 or 14 bits-per-pixel that you find in RAW files. Those two steps (demosaicing and compressing) involve several different creative choices and each of these choices almost always "throws away" part of the information that was initially captured by the camera. One can always create 16-bit TIFF files, which are accepted in Commons, but they still carry choices from the demosaicing process and are, usually, much larger than RAW files (since they store 16 bits of information per channel, 48 in total, for each pixel that originally contained 14 bits of information). So 16-bit TIFFs are usually larger AND carry less information than RAW files. So there's absolutely no practical reason why we shouldn't be accepting RAW files in Commons. DNG is the most used format for RAW files.

As far as I can see, the one thing that's held back the implementation of DNG uploads here is a misconception about DNG's legal status. This Community Wishlist thread from 2016 rejected its adoption based on two incorrect premises: that it is a proprietary format and that there are free alternatives. Those premises are incorrect because:

while the format was developed and patented by Adobe, that very patent grants "all individuals and organizations the worldwide, royalty-free, nontransferable, nonexclusive right under all Essential Claims to make, have made, use, sell, import, and distribute Compliant Implementations". So while it isn't (wasn't, see below) formally in the Public Domain or licensed under CC, it's free. Some people have claimed that these rights are "revokable", the very patent determines that the one situation where it can be revoked is "in the event that such licensee or its affiliates brings any patent action against Adobe or its affiliates related to the reading or writing of files that comply with the DNG Specification". So, in practice, it's not actually revokable (unless WMF decides to sue Adobe for whatever reason specifically related to the reading or writing of DNG files).
there are actually no free, widespread alternatives to storing RAW image files. OpenRAW, while having a significant impact in the field, never actually documented an open raw format. OpenEXR isn't the same thing.
DNG is the only RAW format recommended to be used by institutions such as the Library of Congress (see the "sustainability factors" section).
although I haven't found confirmation of this (which makes sense since the patent's status is virtually irrelevant for the facts stated above), the Adobe patent was first filed in September 2004, which means over 20 years have since passed and the patents is now in the public domain.

For all I exposed above, we're throwing away relevant information from image files that could be invaluable in the future or uploading huge 48 bits-per-pixel files that can easily go into the hundreds of megabytes per file; or, most often, both. Therefore, I believe adopting DNG as an accepted file format here in the Commons is important and should be made a priority.

Rkieferbaum (talk) 20:57, 11 November 2024 (UTC)[reply]

Support Sounds good --PantheraLeo1359531 😺 (talk) 15:14, 12 November 2024 (UTC)[reply]

If the legal problems are solved it is only a technical problem to add proper support in MediaWiki. The most important thing for RAW files is that we need a content model that links processed versions to the RAW file. This problem need a solution first. We should not start doing this with Wikitext "see also" oder "other versions" templates. GPSLeo (talk) 15:38, 12 November 2024 (UTC)[reply]

@GPSLeo: Why should we not use "other versions" for this? It seems to me to be exactly what it is for. - Jmabel ! talk 18:30, 12 November 2024 (UTC)[reply]

@GPSLeo: there isn't and actually never was any sort of claim regarding the legality of the matter. Some people dislike the fact that DNG is patented and the right to use it is “revokable”, but, as I explained, those are non-issues. As for processed versions, once again that's a non-issue IMHO, since DNGs inherently carry image settings that allow any software to extract a “standard” JPG from it without the need for always having a separate JPG uploaded in parallel. Those instructions are enough to generate all the previews of an image while the DNG remains available for download. I do believe it would be interesting to have a process for creating “virtual copies” of a DNG - that is, basic instructions for different crops and color treatments of an image without the need of creating and uploading a derivative file. But that's just speculation on my part and in no way a restriction to the adoption of DNG uploads. Rkieferbaum (talk) 18:32, 12 November 2024 (UTC)[reply]

The problem with having the link in Wikitext is that it is not machine readable. I want an API where I can request the RAW file for my JPG or a specific processed version for a RAW file. The embedded thumbnail in the RAW file is to small even for the use in Wikipedia articles. I think the WMF legal team saw some problems and if they have problems with a feature it is also a problem for us. The first step needs to be to get their okay. GPSLeo (talk) 19:10, 12 November 2024 (UTC)[reply]

@GPSLeo: there’s the embedded, low-res preview, but there’s also information (WB, tone, etc.) that allows for any of a handful of free software to generate a full-resolution RGB. That’s what I was referring to. As to legal challenges raised by WMF, I searched the topic as well as I could before posting this, and I never found anything related to legal issues. Would you mind pointing to anything related to that matter? Rkieferbaum (talk) 22:27, 12 November 2024 (UTC)[reply]

@GPSLeo:

"not in the API" is not the same as "not-machine readable"
I would presume humans are still our primary users. I have no objection to this being in the SDC, but I think it is ridiculous to say it should not also be in the wikitext. SDC is roughly as inconvenient for most humans as text is for bots.

Jmabel ! talk 21:11, 14 November 2024 (UTC)[reply]

You would find it "interesting" is at least something. What would be a reasonable assumption for the change in filesize between jpg to DNG? Maybe 10 times larger? Alexpl (talk) 07:43, 19 November 2024 (UTC)[reply]

@Alexpl: of course it depends on a number of factors, but in any case it's unlikely you'll reach that much of a difference when comparing to high-quality JPGs. You're probably looking at around 3 to 4 times on average. Rkieferbaum (talk) 20:41, 19 November 2024 (UTC)[reply]

username verification at Commons

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

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

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

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

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

to:

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

Please comment. Thank you. --Krd 03:25, 19 November 2024 (UTC)[reply]

--Achim55 (talk) 08:06, 19 November 2024 (UTC)[reply]

This is asking for someone to take advantage of it. All the Best -- Chuck ^Talk 16:34, 19 November 2024 (UTC)[reply]

I would not change the username policy. But I think it would be good to optimize the VRT process. Verification on an other Wiki should be recognized on Commons and account verification and copyright permissions should always come together. GPSLeo (talk) 16:46, 19 November 2024 (UTC)[reply]

I think that we should make the policy that files donated by companies should have to go through VRT from a corporate email. All the Best -- Chuck ^Talk 17:04, 19 November 2024 (UTC)[reply]

This is already how permission for such files is handled. The only problem is that files are often not recognized as requiring license confirmation. But this is a problem where there are currently experiments how the UploadWizard process could help in such cases. GPSLeo (talk) 17:50, 19 November 2024 (UTC)[reply]

Category Name Change Re:Trump 2nd Term

Should we change Category:Photographs from the White House during the Trump administration to say "during the First Trump administration"? With it we might also change other categories too like Category:Cabinet members of the Donald Trump administration to First as well. This would then bleed over into Category:Cabinet members of the Grover Cleveland administration as well. Thoughts? SDudley (talk) 19:04, 19 November 2024 (UTC)[reply]

Makes sense, maybe add a parent cat "Cabinet members of the Donald Trump administrations", and the same for Grover Cleveland. All the Best -- Chuck ^Talk 23:43, 19 November 2024 (UTC)[reply]

Commons:Village pump/Proposals

Contents

CAPTCHA for many IP edits

One week test

Simple edit confirmation

First results

Notifications when one's uploaded files get used

Limit page moves in "File talk"-namespace to users who can move files

Global Folk Music Collection (with Wikidata)

Proposal for Image guidelines: Focus and DoF

File:Owl WTP.jpg

Style guide for templates

Deleting empty categories

Create a noratelimit user group

Advanced rights and moderation task demand announcements

Prioritize support for the upload of DNG (RAW) image files

username verification at Commons

Category Name Change Re:Trump 2nd Term

Navigation menu

Commons:Village pump/Proposals

CAPTCHA for many IP edits

One week test

Simple edit confirmation

First results

Notifications when one's uploaded files get used

Limit page moves in "File talk"-namespace to users who can move files

Global Folk Music Collection (with Wikidata)

Proposal for Image guidelines: Focus and DoF

File:Owl WTP.jpg

Style guide for templates

Deleting empty categories

Create a noratelimit user group

Advanced rights and moderation task demand announcements

Prioritize support for the upload of DNG (RAW) image files

username verification at Commons

Category Name Change Re:Trump 2nd Term

Navigation menu

Search