Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

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

COMMONS DISCUSSION PAGES
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

[edit]

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

[edit]

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

[edit]

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

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

[edit]

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]

Notifications when one's uploaded files get used

[edit]
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:
  1. 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.
  2. 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.

Redirect undermaintained Species Galleries to Category pages

[edit]

Hey all, I have been thinking about this for a while so wanted to put it out there.

I have been watching a lot of the Taxon galleries and have been noticing a pattern:

  • the vast majority of them have less than 10-15 pageviews a month, some as few as 0 or 1, and have barely any information -- nearly 90% of the time, it has less Taxonomic information than Wikidata, which in turns means that the gallery page is far less informative or easy to translate than the Category Wikidata Infoboxes, which include all of the identifiers currently used in special templates on the gallery pages.
  • Moreover, almost all of the gallery pages haven't had any images updated since ~2013-14. This means that most of the time, images are low quality or don't represent the biodiversity very accurately. Especially on taxons, there has been a lot of subsequent work to partner with Natural History organizations, Flickr or INaturalist to add additional photography and media, and the editors working on taxon categories have been far more active.
  • Additionally, by both having a Commons Category and a Gallery page, it targets navigation from Wikipedias and other sources using interwiki links towards the less useful set of media files.

I propose that we redirect the Gallery pages to their corresponding taxonomic category, if:

  • The page contains less than 500 bytes
  • Hasn't been edited since 2016 (or hasn't had more than 2 edits since 2016)
  • and has less than 15 pageviews a month

I have a sample query with Petscan of the kinds of taxons pages this would include. And based on massviews for the first 20000 or so of these gallery pages, I estimate that we would probably be redirecting ~ 80% of the pages if we only used the pageview criteria, the other two will reduce it substantially but make it easier to evaluate the quality of the remaining ones.

Once this step is done, we could look at the remaining taxon Gallery pages to evaluate if they are providing sufficient value to users or are worth trying to maintain. I get the impression that there would be a second tranche of redirects if we are thinking about reader value and maintainability, Sadads (talk) 13:55, 19 September 2024 (UTC)[reply]

Pinging a few users that have been editing the pages, or responding to my first few dabblings in doing this manually : @Prototyperspective @Mateus2019 @JopkeB @‎Llez, @MPF, @AnRo0002 Sadads (talk) 14:01, 19 September 2024 (UTC)[reply]
 Support Agree 100%; the gallery pages no longer have any useful value, and most of them should be redirected to the relevant category, or deleted. I'd also widen the criteria for inclusion somewhat, to say 'Hasn't been edited more than 2 times in the last 8 years', so subsequent small maintenance edits (e.g. for replacement or removal of deleted or misidentified files) doesn't prevent redirection. - MPF (talk) 14:15, 19 September 2024 (UTC)[reply]
I would endorse that switching from "Hasn't been edited since 2016" to "'Hasn't been edited more than 2 times in the last 8 years'" -- that would definitely be a better scope for getting rid of unmaintained stuff, Sadads (talk) 14:33, 19 September 2024 (UTC)[reply]
 Support the proposal as specified for the reasons given. Prototyperspective (talk) 14:57, 19 September 2024 (UTC)[reply]
Another major issue here not mentioned so far is that in the MediaSearch under "Categories and Pages" by default galleries are also shown. Depending on the search phrase, there's often many of them. Especially in such cases but also in general, this means category and help pages are buried underneath so people, especially people not yet very familiar with WMC, won't find them. Gallery pages seem to show up there near the top and most of them are not useful and even when they are I think it's rather unlikely people using that search searched for galleries there. When I search for categories (less often also help pages or prior discussions) I usually go there and then click Namespaces and then select Custom and unselect Gallery. New users and unregistered people casually browsing the site shouldn't be expected to find that. As a solution I'd propose moving galleries a bit down in these search results and what's proposed here would probably also substantially contribute to making that search much more useful. Prototyperspective (talk) 23:03, 24 September 2024 (UTC)[reply]
That's certainly a problem. Right now if you look for "roses" it's impossible to ever to any categories in the search results because there's 2,000 galleries for every minor sub-species. I'm not sure if making galleries show up lower in the results would work though. Since there's probably always going to be more categories having to do with a particular subject then galleries. Meaning galleries will just end up being hidden at the bottom. The better solution is having standards about it and not letting people create galleries in mass for every minor subject. Admittedly I haven't looked into these galleries that much, but at least the ones for roses seem to have been created in a semi-automated way as part of paid editing campaign or something. So I doubt there's much chance of it being duplicated. Probably the same applies here. There's almost zero chance of someone creating 40,000 or however many it is unless their using a bot or something. So there just needs to be better standards and regular review of new galleries once the current crop is cleaned up. --Adamant1 (talk) 00:38, 25 September 2024 (UTC)[reply]
That's a good example. It doesn't even show the category of the exact same name, Category:Roses, near the top but only underneath a pile of likely irrelevant galleries. To clarify: I didn't mean that all categories come first and then all galleries below them – just that their relative relevance is decreased and I don't know if the Wikimedia search algorithm is transparent/open. So galleries would still show high up if they are very relevant such as having a name that matches the search term 1:1, just not so many at the top and maybe only below a few most-relevant cats. One could also consider things like reserving the top 3 search results for category and help pages and several other things like that. Standards and what has been proposed here would help a lot and may be more helpful in that regard compared to improving the search engine algorithm but both things can be done and if the latter is implemented that may take quite a while until it's applied. Prototyperspective (talk) 10:34, 25 September 2024 (UTC)[reply]
@Prototyperspective: Maybe it would be worth just disabling galleries in the search results by default like they do with talk pages and the like. I doubt anyone uses the search to specifically look for a gallery right off the bat and they show up in the drop menu anyway. So it doesn't seem like it's necessary to even show them in list of results to begin with. At least not by default. --Adamant1 (talk) 17:56, 25 September 2024 (UTC)[reply]
I would support that. Prototyperspective (talk) 17:57, 25 September 2024 (UTC)[reply]
I think it would be useful to have some data how much of the traffic for Galleries is from Search vs Interwiki Links vs Google + referrals -- my bet is the later two are a much higher driver of traffic than the search, but it would be good to know if a decision like that would reinforce evidence of galleries in Decline-- this should be part of a followup set of discussions related to galleries, Sadads (talk) 18:35, 25 September 2024 (UTC)[reply]
 Disagree
So problems are that a lot of Taxon galleries are less useful because they have old images, are small, have not enough information and have less than 15 pageviews a month. Is that the case? Why is it a problem that:
  • old images are used? Do organisms change overtime? Do the images not show good enough what an organism looks like? I always thought that organisms do not change a lot within a century.
  • they are small? The number of 500kb also means that even a gallery page with eight images, like Penstemon gracilis, would be emptied. Up to now we have used a limit of one image (a gallery page with one image may be deleted, one with two or more should be kept).
  • offer not enough information? Add a Wikidata infobox and you have access to all the information that you may wish for within the Wikimedia family. For me a gallery page is also useful for a quick view: a visual answer to the question what is the subject about (and not having to click on many subcategories within a category), and then maybe click through for more information.
  • they have less than 15 pageviews a month? Commons is not a commercial organization where only images or gallery pages may stay that have a minimum use or pageviews. Gallery pages in the end of the long tail can also be useful and valuable.
And I totally disagree with MPF that gallery pages have no longer any useful value and most of them should be deleted. I use them often and in general I find them useful. JopkeB (talk) 16:25, 19 September 2024 (UTC)[reply]
When it comes to your example, the gallery is not more useful than the category page. It's less useful and has several other issues such as newly uploaded images added to the category not showing up in it. Prototyperspective (talk) 16:32, 19 September 2024 (UTC)[reply]
It is not about this example, it is about gallery pages with eight images that might be deleted when these criteria are used. JopkeB (talk) 16:41, 19 September 2024 (UTC)[reply]
Good point, thanks for clarifying. Maybe the minimum should be lowered but I support a 500 bytes minimum and find it quite a good choice. Prototyperspective (talk) 16:45, 19 September 2024 (UTC)[reply]
@JopkeB The example you share of Penstemon_gracilis is a perfect example of where the gallery has less information that the Category (exact same pictures, less information). And a good example of where we have already 8 different other pages where you could get the same data (5 Wikipedia articles, A Commons category, a WikiSpecies page, and a Wikidata item). The page has been used 185 times since 2016, whereas the category has been used 103 times. We have basically split the audience, but created twice the work for the volunteer editors maintaining the page. Moreover, the Gallery would require an editor to actively maintain the page to include new novel information, such as images in Category:Penstemon_gracilis_-_botanical_illustrations, Sadads (talk) 18:06, 19 September 2024 (UTC)[reply]
Ditto to @Sadads, the Penstemon_gracilis page @JopkeB cites is a perfect example of why the galleries are useless; that gallery includes no information at all that is not in the category, and omits several things that are in the category, like filenames and file sizes.

Also well worth mentioning (which it hasn't been yet), is the complexity of renaming when a taxon is renamed (e.g. a change in the genus a species is in, or a former subspecies changed to a species): the presence of a gallery double the amount of work to do. This is a major problem with the massive backlog of taxonomic updates needed on Commons. - MPF (talk) 19:28, 19 September 2024 (UTC)[reply]
 Weak oppose
Yesterday and today, I checked roughly 430 of those pages. Most of them are not real gems of our project. That brings me to my main point: Commons is a project just like the Wikipedias. Some day, a colleage fills out one page and another time, someone else populates another one. Readers can jump to the main category anytime. A solution would be a contest "who illustrates / populates" poor taxon gallery pages - or a focus on taxon pages for a month (the 3 best users get a virtual ribbon). At the German Wikipedia, we have writing contests (e.g. Asia) but at Commons, there are only a very few (image contributions of a certain topic, or QI, etc.). I wonder what happened to the peoplz who created this mass of pages ... -- Did they all drop out? --Mateus2019 (talk) 16:58, 19 September 2024 (UTC) ← has no biology background beyond school education back in the 1970s to 1990s.[reply]
They may no know of categories and it takes an extra click that many won't do if the first page doesn't show already useful media. It could be that many of these have been created by bots but I haven't checked. In any case they hide the media in the categories. Prototyperspective (talk) 17:07, 19 September 2024 (UTC)[reply]
Yeah the problem is that the Categories and Infoboxes on the categories are much easier to maintain, higher value information resources -- and there is not a lot of editors working on the Galleries for the taxons (40k of them) and there is not a really compelling case to be made to work on them, when the categories and infoboxes do most of the work. Sadads (talk) 17:56, 19 September 2024 (UTC)[reply]
In my opinion the function of a gallery page is NOT to be complete nor to show all the available information about a subject, but to show a fine selection of all the media in relevant categories. Many categories show media of low quality, or media that look a lot alike, or have many subcategories where gems are hidden. In a good gallery a selection of the best media is shown, including the hidden gems of the subcategories, all to see at a glance. And they may have other funcions, see my list at Commons talk:Galleries#Add "criteria for creation of galleries" section to guideline. Categories and galleries are complementary to each other. In the case of toxan galleries they might give a quick glance of different aspects of a species.
What kind of maintenance is needed for gallery pages? JopkeB (talk) 04:01, 20 September 2024 (UTC)[reply]
To start with almost all of the ones I am encountering, have super low quality images, that could be better represented by new media that are higher resolution or a featured image. However, I also keep finding galleries with 1-3 images, that exactly replicate the category -- sometimes featuring quality images -- also not helpful if they don't help the reader get oriented to the topic. This is part of the reason I am suggesting a criteria of 500 bytes: larger than that, and there is usually some kind of meaningful description or "orientation to the topic" that would be lost -- usually its superficial, but at least there are captions, sections and some kind of filtering going on. Wheras the smaller ones (especially those without edits or pageviews), basically don't show the best of commons -- leading to the kinds of confusion of unfamiliar readers/editors/community members suggested above, and also to the neglect of maintenance of things like translation. 10:00, 20 September 2024 (UTC) Sadads (talk) 10:00, 20 September 2024 (UTC)[reply]
  •  Support I've been going through and adding categories to species galleries the last couple of days. Most of them totally pointless and have no way of being expanded because there isn't enough files on here having to do with the species to begin with. One thing that I think should be done with a lot of these small, unmaintained galleries is that they get up-merged to ones for the broader topic. A good example of that is the galleries in Category:Gallery pages of roses, most (or all) of which only contain a couple of images and have zero way of being improved. There's just always a tendency to take everything down to the lowest possible point on here for some reason though.
Regardless, there's no reason most (or all) of those galleries couldn't just be gotten rid or up-merged into one for roses in general, instead of us having to deal with, improve on, and maintain 2309 galleries for every single minor sub-species. Realistically we just don't have enough people who are interested in the area to improve the galleries. Let alone enough images to make it worth putting the work into to begin with. So I'd totally support just redirecting or deletion them in absence of a better alternative. I don't think they be kept as is indefinitely just because though. At the end of the day there should either be a clear, reasonable way to improve them or they should be gotten rid of however it's done. --Adamant1 (talk) 07:25, 20 September 2024 (UTC)[reply]
I agree completely. Small, specialized categories rarely deserve a gallery page of their own. Upmerge galleries to form a decent gallery corresponding to a parent category. I think Romanian Orthodox churches in Bucharest is a good example of doing this at the right level. Yes, many of these churches have categories of their own, but few deserve galleries of their own. - Jmabel ! talk 15:10, 20 September 2024 (UTC)[reply]
@Jmabel could you clarify if your specific comment is on the Roses or more generally in support of the taxons proposal? Sadads (talk) 16:31, 20 September 2024 (UTC)[reply]
Anywhere there is an analogous situation. One of the best features of galleries is that they allow us to juxtapose images from subcategories and help people identify what they are looking at without having to dig into a bunch of separate categories. Tiny, sparse gallery pages don't help with that. - Jmabel ! talk 20:02, 20 September 2024 (UTC)[reply]
 Support. Galleries make sense where there are enough images related to a broad topic that it becomes helpful to call out a few really good examples, or where there's some structure to a set of images which is difficult to show in a category. A great example of both is gallery pages for cities, where the page will often be organized around points of interest in the city, and will pick high-quality images from subcategories to illustrate each one. Creating galleries for species categories which only have a few images to begin with is a waste of time; there's no additional curation or organization that can be offered. Omphalographer (talk) 16:38, 20 September 2024 (UTC)[reply]
 Comment @Sadads commissioned me to write a Quarry query for this project ^^ https://quarry.wmcloud.org/query/86509 should implement the first two conditions, i.e. list small pages (for taxon galleries) with few edits since 2016. (I slightly tweaked the second condition to avoid including pages that were created post-2016 but had ≤2 edits.) The third condition, pageviews, isn’t available in Quarry, so someone™ will have to do that externally. But I hope this helps :) Lucas Werkmeister (talk) 17:27, 24 September 2024 (UTC)[reply]
All the galleries I've checked barely had any views. So I doubt it matters. The most important things are the size of the galleries and number of edits. --Adamant1 (talk) 17:32, 24 September 2024 (UTC)[reply]
@Adamant1 I ran it through massviews, and its less than 100 of the galleries have more than 15 pageviews in the last 30 days, Sadads (talk) 17:50, 24 September 2024 (UTC)[reply]
And, on average, the galleries have less than 3 pageviews a month, Sadads (talk) 18:11, 24 September 2024 (UTC)[reply]
That seems like a compelling argument for removing most of the small, unmaintained galleries. Omphalographer (talk) 00:41, 25 September 2024 (UTC)[reply]
The main issue is figuring out what makes a gallery qualify as "small" or not. It seems there's some resistance when it comes to galleries containing more then one image being deleted, but that seems like an extremely myopic and arbitrary place to draw the line. I've certainly seen plenty of galleries that weren't any more valuable just because there was one or two extra images. --Adamant1 (talk) 00:48, 25 September 2024 (UTC)[reply]
@Adamant1 @Omphalographer I think the byte count is really telling, the more I look into this (I ran @Lucas Werkmeister Quarry, without the limit to the Taxon Galleries: https://quarry.wmcloud.org/query/86513 -- and sampling from other generes/themes, low byte count = no captions, sections or sufficient contextual data to be useful in a way that is more helpful than a category page, right around 600 bytes you start getting sufficient description or complexity (i.e. multiple images in multiple sections). Sadads (talk) 00:52, 25 September 2024 (UTC)[reply]
That being said, I think the consensus in this discussion is on the taxon content, if we want to do the other topics I think we should start another discussion (once the taxons are gone, it will be easier to see what is being neglected here, Sadads (talk) 00:56, 25 September 2024 (UTC)[reply]
That sounds reasonable. I think around 600 bytes is a good place to deal with it at and then we can review and clarify where the final line should be from there as needed and/or with other topics. --Adamant1 (talk) 00:58, 25 September 2024 (UTC)[reply]
To Summarize:
  • Sort criteria for the purge are:
    • that the gallery is less than 550 bytes. I'm splitting the difference here between the 2 most popular proposals.
    • Less than 2 2 or less (see Adamant1's comment below) edits in the last 8 years.
  • Wikidata infoboxes for all the subspeices should be on the catagory pages.
  • The gallery policy should be updated and possibly changed to increase the quality expected of gallerys, and to require RFC (or equivalent, i.e. Village pump/propsals) before any form of mass gallery creation starts.
  • Organise and editathon (or similar) to perform all the taxanomic updates needed.
    • Make a method for editors/permission holders to help conribute.
Please let me know if I missed anything.
All the Best -- Chuck Talk 01:45, 25 September 2024 (UTC)[reply]
That sounds fine except I'd change the edit count to "two or less" since from what I've seen a lot of galleries get superficially edited by a bot at some point and I don't see why it should matter. --Adamant1 (talk) 01:59, 25 September 2024 (UTC)[reply]
@Alachuckthebuck I think the Wikidata Infobox is not a firm requirement before the redirects -- there are already several hundred that need to be fixed in Category:Redirects_connected_to_a_Wikidata_item -- I think the requirement is something we can fix afterwards, because we are going to need to fix the interwiki link mapping, and subsequently the addition of Infoboxes to some of those pages (it also simplifies the bot or AWB run to do it). I think the more important requirement is that the gallery is in a category that has the same name, Sadads (talk) 02:02, 25 September 2024 (UTC)[reply]
Makes sense, that was more summarizing the discussion, less about updating policy.
@Adamant1 Consider it implemented. All the Best -- Chuck Talk 02:48, 25 September 2024 (UTC)[reply]
Thanks. So what's the next step here assuming it has the support to be implemented? --Adamant1 (talk) 19:57, 25 September 2024 (UTC)[reply]
someone (probably me in a few hours) adds a new section summarizing the discussion into a set of suggestions under a new heading, then let that run its course. Then an uninvolved admin closes, and we start implementing the changes technically, probably will need someone on the WMF side to help with this, @Sannita (WMF), Who would be the right person to talk to for somthing of this scale server side? All the Best -- Chuck Talk 20:55, 25 September 2024 (UTC)[reply]
@Alachuckthebuck A summary of the discussion would be most welcomed, so that I can try to help you with the request. Please ping me when you are (or who will do the summary is) done with the summary. Sannita (WMF) (talk) 11:14, 26 September 2024 (UTC)[reply]
Never mind, I saw you already did it. Thanks! Sannita (WMF) (talk) 11:15, 26 September 2024 (UTC)[reply]
I am not sure that we need WMF support @Alachuckthebuck if we do a Bot, that does it incrementally over time at Commons:Bots/Work_requests, Sadads (talk) 13:56, 26 September 2024 (UTC)[reply]
If its done by a bot incrementally, CVN tracking becomes infinitely more difficult. All the Best -- Chuck Talk 16:28, 26 September 2024 (UTC)[reply]
CVN? Sadads (talk) 14:48, 29 September 2024 (UTC)[reply]
@Sadads: CVN is the Counter Vandalism Network of the Commons:Counter Vandalism Unit.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:29, 29 September 2024 (UTC)[reply]
Interesting @Alachuckthebuck & @Jeff G., why would redirects by a bot effect CVN? My understanding from bots on other wikis is that you can have their actions either autopatrolled, or clearly labeled with the bot label.
I have made a request, and maybe someone can do it easily (i.e. @Mike Peel?) Commons:Bots/Work_requests#Redirect_Galleries_per_Concensus, Sadads (talk) 12:26, 30 September 2024 (UTC)[reply]
@Sadads: AWB actions by my bot account are certainly flagged that way, but there are certain actions (generally with VFC, Cat-a-lot, or manually) that I do for Commons:Bots/Work requests with my main account, which is not flagged that way.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:38, 30 September 2024 (UTC)[reply]
All deletions go into the CVN-bot logs. those logs were the only indication that something was off when we had the whole Vietnamese artist mass no permission tag fiasco. All the Best -- Chuck Talk 14:41, 30 September 2024 (UTC)[reply]
We could also ignore bot edits, minor edits, and edits that only change categories. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 25 September 2024 (UTC)[reply]
I support that, assuming cat edits only include Hotcat and Cat-A-lot/other cat tools with edit tags (for technical reasons, makes sorting automatically possible without regex) To paraphrase into policy/technical speak:
  • Edits made by flagged bots, those marked as minor, and edits tagged with Hotcat,Cat-A-Lot or another catagory tool do not count toward the 2 edits or less threshold for inclusion.
Let me know if I missed anything. All the Best -- Chuck Talk 20:33, 25 September 2024 (UTC)[reply]
+2. That sounds reasonable. --Adamant1 (talk) 22:04, 25 September 2024 (UTC)[reply]

Summary Proposal by Alachuckthebuck

[edit]
  • (After purge and renames are complete) Add Wikidata infoboxes for all the subspecies should be on the category pages.
  • The gallery policy will be updated and changed to increase the quality expected of galleries, and to require an RFC (or equivalent) before any form of mass gallery creation. This needs proposal on the gallery talk page.
  • Organize a Backlog Drive after purge to perform all the taxonomic updates needed.
    • Make a method for editors/permission holders to help contribute to the drive who are not familiar with this topic area.
  • The first paragraph of the gallery policy has the sentance: Galleries must have a valid reason for creation, and not just be simple copies of categories, A selection of media from a large category, or a collection of categories, is acceptable. added to the end.
  • The first paragraph of the section When to create a gallery in the the commons' gallery policy has the sentence" The Bar for the creation of galleries is higher than categories, and a valid reason for creation is required for mainspace galleries. to the end of the paragraph.
  • Purge the Taxon Galleries with the following criteria:
    • The gallery is less than 550 bytes
    • 2 or less edits in the last 8 years (must be created before 2020 to apply). Edits by Flagged bots, Marked as minor, Cat-A-Lot, or HotCat do not count towards this limit.

All the Best -- Chuck Talk 02:56, 26 September 2024 (UTC)[reply]

Your final bullet point should exclude minor edits also. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 26 September 2024 (UTC)[reply]
@Pigsonthewing Done. All the Best -- Chuck Talk 16:28, 26 September 2024 (UTC)[reply]
Can someone close this? There appears to be a consensus to implement at least some of the proposals. All the Best -- Chuck Talk 17:17, 8 October 2024 (UTC)[reply]
@Krd, can this proposal be closed? All the Best -- Chuck Talk 19:56, 20 October 2024 (UTC)[reply]

Idea: Create eliminators file right

[edit]

The proposed policy page is here.

Currently we are only slightly backlogged, with 1087 DRs that are >1 month old as of speaking and who-knows-how-many CFDs. We also don't have that many active administrators (10-20). Here's why I think having eliminators would be useful.

Most of the backlogged DRs and CFDs (especially CFDs) are uncontroversial. These can be closed by most semi-experienced users. By having an eliminator role, we can reduce these backlogs without the extensive trust required for users to become admins. I have drafted a policy page, and have made the requirement per Commons:Eliminators#Rules for usage that eliminator actions must be accompanied by a speedy deletion tag set by another user or an uncontroversial/supported by consensus deletion request by another user to avoid the chances of false deletions.

I just want to gather initial thoughts on this idea so we can proceed further if it is viable. —Matrix(!) {user - talk? - uselesscontributions} 20:21, 26 September 2024 (UTC)[reply]

 Oppose despite the work overload for administrators, I think that anything that increases the risk of deletion of legitimate content should be avoided. I remember that the first (and to date, the last) time that I tagged files (uploaded by me) for deletion, due to a change of format, I thought: "Why is this so complex? I uploaded them myself only a few weeks ago, why can't I just delete them?". But I quickly realized that, however unfriendly it was for novices, it was necessary for it to be so. Once a file is uploaded, it can be used by anyone, it doesn't belong to you as uploader. I uploaded those images, among other things, to contribute in preserving them, so it makes full sense that it isn't so easy to delete them. MGeog2022 (talk) 21:08, 26 September 2024 (UTC)[reply]
 Support Anything to lighten the load on admins is a good thing, but there should be a limit to how long discussions can run before closing, in addition to a minimum length(2 days at least) to avoid someone slipping under the radar. If this gets approved, I volunteer to be the test user for the whole process. All the Best -- Chuck Talk 16:53, 27 September 2024 (UTC)[reply]
@MGeog2022, Undeletes are cheap, and if we have a seprate log for eleminiators, its easy to patrol edits. I only ever see there being 5-10 eliminators at any given time, as most people who would be eliminators are already admins. We @Matrix, what are your thoughts on requiring LR before getting eliminator, and allowing these users to grant autopatrol? All the Best -- Chuck Talk 16:56, 27 September 2024 (UTC)[reply]
I think it's best not to tie this right to license reviewers. There are Commons users that are familiar with copyright, but have no interest in reviewing files from Flickr. Furthermore, the implied journey of normal user -> autopatroller -> patroller -> LR -> eliminator is simply too long. A user's ability to interpret deletion policy and requests can be judged by previous DR history and questions from other users during the process. As for allowing these users to grant (but not remove) autopatrol, I think this is an all right idea in theory, considering license reviewers can grant (but not remove) license review status for other users, but in practice we don't really have that big of a backlog at COM:RFR so it would be quite redundant.
Also your statement that "there should be a limit to how long discussions can run before closing" is already happening: per COM:DR DRs must be open for 7 days before closure. —Matrix(!) {user - talk? - uselesscontributions} 17:43, 27 September 2024 (UTC)[reply]
I was referring to requests for the right, not for DRs. The autopatrol granting is because some editors (who are fantasic!) don't have autopatrol, but their (perfectly fine and above board) edits clog up RTRC, and dealing with that problem is where I see the utility (or just allow LRs to grant autopatrol.) Please let me know if I missed somthing. All the Best -- Chuck Talk 17:52, 27 September 2024 (UTC)[reply]
@Alachuckthebuck, OK, if eliminators are few and very trustable,  Support. I do know that deletions can be undone, but the problem with deletions, unless other editions, is that deleted files can't be viewed any more (except for very few privileged users), so a wrongly deleted file would not be so easy to detect (also, even if undeleted, most of its previous wiki uses wouldn't be restored, so some damage would already be done). MGeog2022 (talk) 19:22, 27 September 2024 (UTC)[reply]
@MGeog2022, If an image is in use on a wiki, than the deletion threshold is a lot higher, and In-Use images can only be deleted as copyvios, vandalism, or advertisements. That's it. As to undoing deletions, "deleting" a file on commons just hides it from the majority of users, and undeletion just unhides the file. Currently, I can think of about 4 users who would be given this right by the community, and never expect it to go above 20 unless commons becomes bigger than en-wiki. All the Best -- Chuck Talk 21:09, 27 September 2024 (UTC)[reply]
But 10 is the max I ever expect to see (including bots) hold the right. All the Best -- Chuck Talk 21:12, 27 September 2024 (UTC)[reply]
@Alachuckthebuck, false positives in copyvio could take place if people without enough knowledge could delete files. But, from what you say, it's about having less than 10 (very trusted) people as eliminators, to reduce workload to administrators. So, certainly, I  Support, then. MGeog2022 (talk) 12:45, 28 September 2024 (UTC)[reply]
Getting images that have been deleted for invalid reasons undeleted is already hard enough as it is Trade (talk) 00:35, 16 October 2024 (UTC)[reply]
 Oppose Proposed and declined dozens of times. Krd 20:20, 27 September 2024 (UTC)[reply]
And why do you oppose, other than proposals have failed before? All the Best -- Chuck Talk 21:10, 27 September 2024 (UTC)[reply]
For the same several good reason shown in previous discussions. Krd 04:13, 28 September 2024 (UTC)[reply]
No least: If the potential eliminators would just use the same time for commenting on deletion request, the problem was also resolved. More rights don't help to solve resources issues, but more active users do. Krd 06:35, 28 September 2024 (UTC)[reply]
@Krd, How do comments help make closing DRs easier? If its an open and shut case, an eliminator can close the DR, rather than commenting "Delete as (Generic reason here), Could have been CSD", and wait for an admin to come along and close. If its more complex, then they can comment as community members. But the majority of DRs don't need 5 community members, they need someone who has the technical ablity to delete the file to close the DR, and delete the file. If community members can close DRs as speedy keeps (and only a few even do this due to the effort involved in manually closing a DR as keep), why can't they close 7 day old DRs that should have been CSD tagged? That's the role of Eliminators: allowing admins to focus on the DRs that tend to stay open for weeks, rather than the 50 Open and Shut cases. All the Best -- Chuck Talk 23:57, 28 September 2024 (UTC)[reply]
Because the open snd shut cases are not a problem at all, but the difficult ones are. Krd 04:25, 29 September 2024 (UTC)[reply]
Thats why eliminators should exist, allow the admins to not worry about the simple stuff and just focus on the Difficult DRs. And also allow a path to increasing the size of the admin corps. Its a win-win All the Best -- Chuck Talk 05:58, 29 September 2024 (UTC)[reply]
Chuck, we admins can always close more open and shut cases, those are not the biggest issue in our backlog, the difficult ones are often open the longest because we need specialized information or it's not clear-cut on whether or not it fits a copyright exemption. We definitely want more non-admins to be active in DRs. Some of our most trusted users are not admins. Abzeronow (talk) 18:38, 29 September 2024 (UTC)[reply]
@Abzeronow: Are there categories for the difficult ones?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:45, 30 September 2024 (UTC)[reply]
 Oppose Anyone I would trust with this right, I would trust as an admin. The Squirrel Conspiracy (talk) 04:09, 28 September 2024 (UTC)[reply]
 Oppose : Exactly as The Squirrel Conspiracy says. - Jmabel ! talk 15:29, 7 October 2024 (UTC)[reply]
 Neutral :- @Matrix, In my opinion, unbundling the toolkit is not a solution. I would suggest that the community should take initiative and pitch potential candidates for RFA. That way it will ease the task for the community to decrease the backlog. Thanks --C1K98V (💬 ✒️ 📂) 04:32, 28 September 2024 (UTC)[reply]
I was talking to someone about doing that a few months ago but it seems like there just isn't any users on here would qualify, maybe some users from Wikipedia but I don't think anyone would vote for someone who isn't active on here even if they would be fine otherwise. --Adamant1 (talk) 11:45, 28 September 2024 (UTC)[reply]
some users from Wikipedia: I think this is a very good idea. If there are copyvio images in Commons and they are used in Wikipedia, this is is also a problem for Wikipedia, so it's of interest even for Wikipedia-only community members. MGeog2022 (talk) 12:50, 28 September 2024 (UTC)[reply]
Then I assume you're looking for potential candidates at the wrong place. Without RFA you're reaching to conclusions is not fair (community views might differ). Thanks C1K98V (💬 ✒️ 📂) 13:04, 28 September 2024 (UTC)[reply]
@C1K98V: I'm more then happy to look over a list and give my opinion on the candidates if you want to email me one. I spent a good amount of time a few months ago researching users on here to see if any of them wanted to apply for adminship though and couldn't find anyone who would qualify. That's not to say their isn't anyone, there were two users I thought might be able to pass an RFA at the time, but the pool of potential candidates is clearly extremely low. I don't even think there's that many active users on here to begin with. Let alone anyone who's untarnished enough to be an admin. --Adamant1 (talk) 17:27, 28 September 2024 (UTC)[reply]
 Oppose. I do not like such unbundling / fine divisions of labor. In addition, an eliminator could not undo her own mistakes. Glrx (talk) 13:12, 28 September 2024 (UTC)[reply]
 Oppose Deleting as important to the administrator's toolkit as blocking and protecting. I can only think of two people whom I wouldn't trust with the block button but with the rest of the tools. Basically, if they're trusted enough to delete and undelete, they are trusted enough to be administrators. Also, I'll note there really is not a RFR backlog, at least one request is being kept open so the requestor can get more edits. I'm also aware of a future RfA from a trusted user whom I would support. Abzeronow (talk) 21:03, 28 September 2024 (UTC)[reply]
Even if we only get two more people helping with the backlogs, thats two more people helping close DRs. Adminship is supposed to be Not a Big deal. This "admins are gods" mindset is everywhere on commons, and anything we can do to reduce that mindset is a plus. All the Best -- Chuck Talk 23:45, 28 September 2024 (UTC)[reply]
I would definitely encourage more people to become admins. I don't agree with "admins are gods" mindset, and as stated, backlogs exist for reasons other than number of admins. I've got at least three DRs that I can't close yet because I need information on the ToO of Serbia. Abzeronow (talk) 18:38, 29 September 2024 (UTC)[reply]
Here's a paradox: many users are too humble to consider applying to be sysop, whereas those who do often have big ego and cannot restrain themselves. (same is true for politics and management in real life, but there are more checks and balances. here users are often anonymous; positions are for life; participation is voluntary = bad money drives out good.)
so i have 2 suggestions:
  1. for the 1st part of the paradox: let's hold a "nomination call" once a year. users list names that they trust to be sysops.

    hope is that a listed user seeing the support they have will have confidence to apply.

  2. ease Commons:Administrators/De-adminship#Activity to "who has made 0 admin action on Commons in the past 12 months".
RoyZuo (talk) 15:24, 2 October 2024 (UTC)[reply]
The whole bad admin part doesn't exist right now, but the first part made sense. Would you be willing to be bold and be the first person to make such a list in userspace? All the Best -- Chuck Talk 15:33, 2 October 2024 (UTC)[reply]
Totally a side thing, but realistically how many new admins do either one of you think there needs to be for the backlogs to get dealt with? --Adamant1 (talk) 23:40, 4 October 2024 (UTC)[reply]
I think at least 20 more. I'd take part in a "nomination call" as I can think of a few users that I'd like to see as sysops. Abzeronow (talk) 17:34, 5 October 2024 (UTC)[reply]
That sounds about right. I have a list of 5 or 6 people I've been sitting on for a while now. Maybe we could create a special page or something for finding people and nominating them for adminship where we can list everyone. Although I'm hesitant to name people publicly or nominate them for the role if they don't want to be admins in the first place. But there's certainly people out there who would clearly qualify. There just needs to be a more organized, intentional effort to find them and make them administrators. --Adamant1 (talk) 17:46, 5 October 2024 (UTC)[reply]
@Adamant1, 20-50 depending on what backlogs you are talking about. And about 100 LRs working full time on the Flickr backlog All the Best -- Chuck Talk 23:25, 5 October 2024 (UTC)[reply]
Yall can do it now Commons:Administrators/Nominations. RoyZuo (talk) 14:05, 6 October 2024 (UTC)[reply]
 Comment it's essentially the main task of administrators. Why not just apply for that.
 ∞∞ Enhancing999 (talk) 22:10, 6 October 2024 (UTC)[reply]
Maybe they dont want to deal with blocking users? Trade (talk) 00:37, 16 October 2024 (UTC)[reply]
  •  Comment Why cant we just try to recruit admins from other Wiki projects? I'm sure ENWP will survive a few less of them--Trade (talk) 00:32, 16 October 2024 (UTC)[reply]
    Because they don't have the trust of the commons comunity, and don't know our policys and/or tools. Commons has a lot of tools that aren't needed elsewhere, and most en-wiki tools don't work here. Can someone please fix auditor, it's kinda half broken, as is the commons fork of twinkle. I know you come from enwiki, and its a interesting place with a lot of history and traditions (trout in particular). It's a completely diffrent set of skills, and com:MELLOW sums it up pretty well. I'm thinking about writing a supplementary essay about how com:an is not en-wiki's ANI (and we like it that way), or any of the "drama boards" that are so often timesinks of enwiki. Commons doesn't have 55 active notice boards. We have 8 main, with about 15 supporting and occasional activity. And commons admins do a lot more deletion than en-wiki admins. All the Best -- Chuck Talk 03:42, 16 October 2024 (UTC)[reply]
    I agree. Enwiki admins have the mindset and authority of the Judges of Mega City One, Commons Admins are more like groundskeepers who occasionally have to tell poachers to geeroff their land. Dronebogus (talk) 20:29, 16 October 2024 (UTC)[reply]
    @Trade, We don't have admins who just do admin things (I.E, UAA) we have admins who work on copyright, image upload, VRT, RTRC, or doing other tasks. En-wiki's admins aren't known for being mellow. All the Best -- Chuck Talk 20:59, 16 October 2024 (UTC)[reply]

distributed_by

[edit]

Can we add "distributed_by" to structured_data? It currently gives the message: "The property distributed by should not be used on this type of entity, the only valid entity type is Wikibase item." We have over 1,000 news articles that were published_by newspapers, but they were distributed by the Associated Press or United Press International. We have even more images from both entities. RAN (talk) 18:21, 8 October 2024 (UTC)[reply]

I removed the constraint Trade (talk) 00:39, 16 October 2024 (UTC)[reply]

Please upload PD images from picturethepast.org.uk

[edit]

File:Glossophall.jpg is from picturethepast.org.uk. Others such as Glossop Hall, Glossop, c 1910s are also useful. ..... 69.181.17.113 09:19, 14 October 2024 (UTC)[reply]

Not with the watermarks they have on images now. Better scans probably can be found elsewhere. Carl Lindberg (talk) 13:03, 14 October 2024 (UTC)[reply]
Better than not having them at all Trade (talk) 00:58, 16 October 2024 (UTC)[reply]
Better copy at [3], for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:00, 17 October 2024 (UTC)[reply]

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

[edit]

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)

[edit]

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:

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

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

  1. I got to Wikimedia Commons and search for "Irish Folk pipe music".
  2. I'll find the pipe recording made in Dublin.
  3. 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

[edit]

(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]

Template:Private land

[edit]

Because of these discussions: here and here, I created this template. My recollection is that we've never removed photographs simply because they were obtained by trespassing (we didn't in the 2000s and it appears like we don't now). But I do see no harm in providing a notice on those images, partially in courtesy to those on whom were trespassed and partially so that future viewers know to avoid "updating" those photos without contacting the property owners. I did have to copy another template, so there might be goobers and mistakes, and I have yet to provide documentation for the template. Any help or suggestions are very much welcome. Bastique ☎ let's talk! 18:47, 19 October 2024 (UTC)[reply]

I don't really see the need for this, but if we keep it, can we please tune it down a notch? 1) This does not need to go above all other content on top of the page. 2) Color scheme should follow that of other non-copyright restrictions like Template:Personality rights (which seems to be based on Template:Non-copyright restriction). Let's keep the high alert type colors for the really important things, otherwise they wear out even more. El Grafo (talk) 08:02, 20 October 2024 (UTC)[reply]
Many photos here are from events where accessing a place is only possible if you are a guest of the event. We should not put a warning on all these photos. An exception where something similar could be useful would be an information at photos of for example protected areas where accessing the are is only allowed with permission from an authority. For WLE we have this often and currently it is written into the description but it could be nice to have it in a template. GPSLeo (talk) 08:28, 20 October 2024 (UTC)[reply]
Landowners are the ones to put up "no trespassing" signs. It is not the duty of everybody else, including law enforcement. The landowner can give permission or not based on his own decision. I recommend something else when you are allowed on private property to take photos with the consent of the landowner. I give a notice on my photo: "The photographer thanks the landowner for the kind permission to access the property and take pictures." This is how you do it. Otherwise, when you are there by accident, came through an open gate, hiking through the woods or whatever, you just shut up and feign ignorance. You explain what you are doing and leave the property if you are told to.--Giftzwerg 88 (talk) 09:05, 20 October 2024 (UTC)[reply]
I don't see any need for this at all. For example, we host tons of official photos of the president of the U.S. photographed in areas of the White House that are not open to the public. I see no need to tag them to that effect. Similarly, I've done plenty of photo shoots in buildings where I had to seek permission to go onto the property and/or into the building; most of the photos in Category:Lochkelden are examples of this. I see no reason these should be tagged. - Jmabel ! talk 13:08, 20 October 2024 (UTC)[reply]

Is this the right place to ask this?

[edit]

If this is the right place to ask this, then please close my deletion nomination in File:Hakurei Shrine Reitaisai in Taiwan 3 (1).jpg. I withdrew it nearly 20 days ago. AuroraANovaUma ^-^ (talk) 20:42, 21 October 2024 (UTC)[reply]

Administrators regularly review deletion requests (DR's), so all you would probably have to do is wait. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:46, 21 October 2024 (UTC)[reply]
By the way, if you don't know something about anything I'd advise you to go to "Commons:Help desk" for general questions, "Commons:Village pump/Copyright" for copyright-related questions, and "Commons:Village pump/Technical" for technical-related questions. This village pump is usually for policy and / or guideline proposals. -- Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:49, 21 October 2024 (UTC)[reply]
Ok, well hopefully my nomination gets closed soon. AuroraANovaUma ^-^ (talk) 21:30, 21 October 2024 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:39, 13 November 2024 (UTC)

File:Owl WTP.jpg

[edit]

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

[edit]

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

[edit]

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:

  1. 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
  2. Adjust the Quarry query for empty categories below so it returns all empty categories that should be deleted
  3. 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

[edit]

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:
  1. who will be granted this right and when?
  2. who will be able to grant this right?
  3. 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]

Advanced rights and moderation task demand announcements

[edit]

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]

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

[edit]

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]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=956638303"