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]

@GPSLeo from when to when was the filter live? RoyZuo (talk) 18:09, 14 November 2024 (UTC)[reply]
The filter with current settings was activated on 16:55, 27 October 2024 and is still active. As there were no complaints I would just leave it on as it seems to have at least a small positive effect. GPSLeo (talk) 19:47, 14 November 2024 (UTC)[reply]
The graphs dont look much different before or after 27 October. ip users just happily keep on editing by tapping twice? if true that sounds like very stubborn ip users. RoyZuo (talk) 20:49, 24 November 2024 (UTC)[reply]
Oh, I don't know...Do any of your graphs show vandalism? If most of those edits after October 27 aren't vandalism, I wouldn't call them "very stubborn IP users". (Although I might call some of them helpful.) 2603:3021:3A96:0:2101:3992:8630:68C6 14:24, 16 December 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]
@Teemu, hi! It's been a few years. I'd love to work with you on something such as this, and help you navigate the ins and outs of Commons. Bastique ☎ let's talk! 22:50, 9 December 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]
Why a new page? just shoot the msg at vp. and Category:Commons backlog and Category:Commons admin backlog are here. RoyZuo (talk) 18:18, 14 November 2024 (UTC)[reply]
 Neutral I like the idea, but I don't see it happen. The problem arises when users get inactive, and inactive users don't update pages. Also, the highest demand isn't with the three mentioned groups, but with active admins in general. Users who are willing to help are always welcome to comment on deletion request, no special invitation is required. --Krd 07:04, 14 December 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]
@GPSLeo:
  1. "not in the API" is not the same as "not-machine readable"
  2. I would presume humans are still our primary users. I have no objection to this being in the SDC, but I think it is ridiculous to say it should not also be in the wikitext. SDC is roughly as inconvenient for most humans as text is for bots.
Jmabel ! talk 21:11, 14 November 2024 (UTC)[reply]
You would find it "interesting" is at least something. What would be a reasonable assumption for the change in filesize between jpg to DNG? Maybe 10 times larger? Alexpl (talk) 07:43, 19 November 2024 (UTC)[reply]
@Alexpl: of course it depends on a number of factors, but in any case it's unlikely you'll reach that much of a difference when comparing to high-quality JPGs. You're probably looking at around 3 to 4 times on average. Rkieferbaum (talk) 20:41, 19 November 2024 (UTC)[reply]
The DNG file stores much more information (including the unedited version if not postprocessed), but also higher color-depth than JPEG can offer. This is where the larger filesize comes from --PantheraLeo1359531 😺 (talk) 20:22, 12 December 2024 (UTC)[reply]

username verification at Commons

[edit]

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

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

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

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

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

to: 

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

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

See also: Commons:Village pump/Proposals/Archive/2019/06#Update the username policy.

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

This is asking for someone to take advantage of it. All the Best -- Chuck Talk 16:34, 19 November 2024 (UTC)[reply]
I would not change the username policy. But I think it would be good to optimize the VRT process. Verification on an other Wiki should be recognized on Commons and account verification and copyright permissions should always come together. GPSLeo (talk) 16:46, 19 November 2024 (UTC)[reply]
I think that we should make the policy that files donated by companies should have to go through VRT from a corporate email. All the Best -- Chuck Talk 17:04, 19 November 2024 (UTC)[reply]
This is already how permission for such files is handled. The only problem is that files are often not recognized as requiring license confirmation. But this is a problem where there are currently experiments how the UploadWizard process could help in such cases. GPSLeo (talk) 17:50, 19 November 2024 (UTC)[reply]
Yes, I also thought that this was policy, as literally anyone can make an account named "Microsoft-official" or "Google-official" and claim to representatives of the corporation. As far as I know, every file donated from corporations require VRTS permission. I specifically created "Template:Welcomeorganisation" many years ago to help people working for organisations to understand how things work around here; and everything in that template is based on official policies and guidelines. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:27, 27 November 2024 (UTC)[reply]
@GPSLeo: This is not a good idea because being verified to speak for a company, and the company really being copyright holder of the uploads, are two different things. Bypassing the permission process for verified accounts will create issues. Krd 12:20, 28 November 2024 (UTC)[reply]
My suggestion was not to skip the process but to put them together. Account verification without copyright verification should only be possible if no content uploads are planned. GPSLeo (talk) 13:44, 28 November 2024 (UTC)[reply]
A verified account can be the copyright holder of one file but perhaps isn‘t of the next. If each file of such account goes though the permission process, what exactly is the account verification good for? Krd 14:08, 28 November 2024 (UTC)[reply]
I would say the verification is valid for all works of one author or one attribution if the original authors give all rights to the organization. GPSLeo (talk) 15:06, 28 November 2024 (UTC)[reply]
"A verified account can be the copyright holder of one file but perhaps isn‘t of the next." How is this different from every normal Commons account? We normally assume good faith about claims of "own work" until we have specific reason to believe otherwise. Why should this be different for people authorized to upload on behalf of an organization? Why should an email to VRT carry any more weight than a post by an authorized, verified representative who operates an account? - Jmabel ! talk 18:37, 28 November 2024 (UTC)[reply]
It should not be different, this is why we shouldn't have verified accounts, because they will imply a difference doesn't exist. Krd 06:16, 8 December 2024 (UTC)[reply]
@Krd: that makes no sense to me.
When I upload a photo and say I own the copyright, after these many years when I have been here and have a good record, even if I already have posted the image elsewhere (credited to me), presumably no one will ask me to go through VRT to prove my account really is Joe Mabel.
But if we had an account, say, "Bill G. (Gates Foundation)" that was uploading on behalf of the Gates Foundation, are you saying that after they have a certain amount of trakc record we can let them skip VRT for new uploads? I don't think you are, but correct me if I'm wrong.
On the other hand, if we allowed that account to be verified, it seems we could then handle its Gates Foundation uploads pretty much the same way we handle my uploads of my work.
Why is that not desirable? - Jmabel ! talk 18:09, 8 December 2024 (UTC)[reply]
The occasion for my proposal is Commons:Volunteer Response Team/Noticeboard#transfer of verification. Do you see any reason to verify this account, which has no uploads, and with the verification assume that their uploads will be own works and have permission? If yes, do you think admins are oblieged to check the user page of the uploader for account verification and consider this for their decision? I think all file licensing information has to be on the file page, and account verification does not make any sense. Krd 06:34, 14 December 2024 (UTC)[reply]
Seems useful to me to have verification for that. If they are then challenged on any future uploads for content for that organization, they have something to link in response that should quickly resolve the matter. If that never comes up, no harm done. - Jmabel ! talk 16:51, 14 December 2024 (UTC)[reply]

Category Name Change Re:Trump 2nd Term

[edit]

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

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

Move most diagram categories to infographic categories

[edit]

This has been talked to death. See here:

Bottom line is that I and a couple admins agree. Along with a native German speaker who confirmed that some people are trying to use the broad German definition of "diagram" to mean an overall English term like "infographic". Categories:

There is a Wikipedia page now for infographic: infographic.

Generally speaking infographic is the broad term for all graphics other than photographs. --Timeshifter (talk) 09:24, 24 November 2024 (UTC)[reply]

"Generally speaking infographic is the broad term for all graphics other than photographs". No, it is not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:13, 24 November 2024 (UTC)[reply]
There are indeed many other types of images that are neither infographics nor photos such as illustrations. I think something needs to be done but I'm not sure what – I think it includes moving many files or categories, like Charts subcategory, into the datagraphics category which is more explicit or specific and better-understood or better-delineated with what's meant. Somebody need to clear up the confusion around the distinctions between charts, graphs, diagrams, etc. For example Charts says The term "chart" as a graphical representation of data has multiple meanings:
[1.] A data chart is a type of diagram or graph, that organizes and represents a set of numerical or qualitative data. [2. ...] while other websites distinguish charts as something separate from diagrams. The current situation makes things more difficult to find and is somewhat unclear. Prototyperspective (talk) 17:52, 24 November 2024 (UTC)[reply]
The infobox at the top of Category:Diagrams has the common English meaning: "plan, drawing, sketch or outline to show how something works or the relationships between the parts of a whole"
Non-photo illustrations are infographics. Any kind of info-based graphic is an infographic. Info includes data. A diagram without data is still sharing info. So it is an infographic. A diagram with data is also a datagraphic.
Datagraphics does not include infographics that are not data-based.
Charts includes graphs, but not diagrams. According to the common usage.
Data-based charts are a subcategory of datagraphics. Datagraphics includes a broad range of data-based graphics including data-based maps such as choropleths.
If we go by the common meanings of the terms, categorization is much simpler.
--Timeshifter (talk) 01:27, 25 November 2024 (UTC)[reply]
Yes. I guess it should be clearer which subcategories you're referring to. I named one that I think needs to be moved.
No, non-photo illustrations aren't infographics except if they're diagrams which can be considered infographics. So for example if it just illustrates how some animal looks like (rather than e.g. labels for different highlighted anatomical parts thereof) then it's not an infographic just like a photo of the animal that likewise shows how an animal looks like is not an infographic.
--Prototyperspective (talk) 11:06, 25 November 2024 (UTC)[reply]

I see what you mean. A line drawing of an animal without labels is not an infographic. I assumed incorrectly that you meant a labeled illustration.

I wonder if editorial cartoons, cartoon strips, or the labeled illustrations in graphic novels are infographics. Many cartoon strips are stories. Some cartoons can be educational. So the info can be a story, educational info, humor, protest, etc.. Are any of those considered infographics. I don't know.

I agree with you about datagraphics. I think much of the stuff in the diagram categories are datagraphics. Charts, graphs, etc.. A few files are diagrams. As you said, diagrams are infographics. A non-data-based diagram is not a datagraphic. An exploded illustrative diagram of parts, for example, often has no data.

So since all diagrams are infographics I think most of the categories in Category:Diagrams can be moved to Category:Information graphics. Basically, just substitute "infographics" for "diagrams" in the category names. So we would be substituting a more accurate category name for a less accurate category name.

Some of the diagram categories may actually contain nothing but genuine diagrams (from the common definition). In that case they can keep "diagram" in the category name. But most diagram categories I have checked have charts, graphs, maps, and other non-diagram files mixed in. --Timeshifter (talk) 09:11, 26 November 2024 (UTC)[reply]

Standardizing categories for films

[edit]

Hi, I propose that we standardize categories for films. Currently there are sorts of formats. I think that categories for films should have the format Film name (year). That should be quite easy, at least for films in English. For other languages, we usually use the translated name in English. There may be an issue when there is not a single English translation. This may require a lot of categories renaming, so it is better to have an agreement before doing anything. Yann (talk) 16:48, 25 November 2024 (UTC)[reply]

There is no reason to preemptively disambiguate titles. Why "Film name (year)" instead of "Film name (country of origin)" or "Film name (language)" or anything else? And why only films? —Justin (koavf)❤T☮C☺M☯ 16:51, 25 November 2024 (UTC)[reply]
"Film name (year)" is the better way to disambiguate because a lot of movies originate from Hollywood and sometimes they'll share the same name, for instance Dressed to Kill, Dressed to Kill, Dressed to Kill and Dressed to Kill, which are all English-language (except for the first, which was a silent film), American productions. I imagine Indian and Chinese cinema would run into the same issue if they're disambugated by language/country of origin rather than year of release, though I'm not as familiar with their output.
And films kind of stand apart from other media productions because films that reach the kind of notability that allows them to be on Wikipedia (and Commons by extension) are usually large productions, so it's unlikely you'll get two movies with the same title in the same year (although this has happened before, see Chaos (2005 action film) and Chaos (2005 horror film)). Video games are in a similar space, although on a fairly regular basis I see indie games reach a level of notability and success I almost never see for indie cinema. ReneeWrites (talk) 18:07, 25 November 2024 (UTC)[reply]
@Koavf: The idea is not primarily to disambiguate titles, but to have predictable names. The year is always the first way to designate a film name. Yann (talk) 18:59, 25 November 2024 (UTC)[reply]
I'm good with disambiguation when necessary, but these names will be far less predictable. I could guess Category:Citizen Kane but would this be Category:Citizen Kane (1939) or Category:Citizen Kane (1941) or whatever? I can't recall the release date of that film, but I can recall its name. —Justin (koavf)❤T☮C☺M☯ 19:11, 25 November 2024 (UTC)[reply]
If this is done, there needs to always be a disambiguation category without the year (or a cat redirect if there is only one such film). - Jmabel ! talk 19:30, 25 November 2024 (UTC)[reply]
I see your point, but currently, we have the following categories: Name, Name (film), Name (year film), and Name (year). So I think it would be good to rename at least the 2nd and 3rd categories. Yann (talk) 19:42, 25 November 2024 (UTC)[reply]
Tend to support this but I think that's already being done when there's multiple films of the same name. There is no need for it when there's only one film with that name so if you're suggesting to also add it for these I'm not sure if that would be good but it could also be useful (e.g. if at a later point there is a film of the same name). In some contexts (ie categories that are not specific to films), having (film) in the title would be helpful – if it's just the year it could as well be a novel for example depending on the context. Prototyperspective (talk) 22:24, 25 November 2024 (UTC)[reply]
It's hard to believe that Category:Gone with the Wind (film) would be easier to find by needing to know what year it was released. - Jmabel ! talk 00:17, 26 November 2024 (UTC)[reply]
Yeah, I imagine Category:The Wizard of Oz (1939) is not what most people would use to find the one that they remember. (and of course some wouldn't immediately try Gone with the Wind (1939) ). Abzeronow (talk) 17:52, 26 November 2024 (UTC)[reply]
Makes no sense. People don't find categories by typing out the category into the url bar. Prototyperspective (talk) 18:03, 26 November 2024 (UTC)[reply]
I do just that with great frequency. - Jmabel ! talk 22:59, 26 November 2024 (UTC)[reply]
With finding I was referring to finding categories one hasn't visited before where it would not show an autocomplete for the category. It makes sense to type a simple category name like category:LibreOffice or category:Blankets there as a Commons contributor. I don't think that's how users usually find categories especially when you have to capitalize words right as with film names, you need to know exactly where the page is you're looking for. In general one can enter it into the search bar which should suggest an autocomplete for the category…I just noticed however that it doesn't suggest Wizard of Oz categories when entering "The Wizard of Oz" there. It may be best to have a redirect so that for every film there is one page or redirect with the year and one without (being a disambig page if there's multiple categories for the film). (Don't think that would be important or currently much needed however.) Prototyperspective (talk) 23:37, 26 November 2024 (UTC)[reply]
"Filmname (yyyy)" is a pretty common notation seen in many film websites. do some users not use film websites at all? RoyZuo (talk) 11:22, 29 November 2024 (UTC)[reply]
and ofc, if nothing else has the same name, commons cat title doesnt need the yyyy suffix. RoyZuo (talk) 11:23, 29 November 2024 (UTC)[reply]

Priority-based patrolling

[edit]

I've just reverted this vandalism edit by an IP user (I saw it when having a look at the list of latest changes). The (let's call it so, better laughing than crying) funny thing about it is that when I tried to revert it as an IP user myself (without being logged in), I wasn't allowed to do that, being notified that I was trying to do a probably unconstructive edit or something like that.
In addition, I remember reading deletion proposals with comments in the like of: how could this obvious copyvio be here for 10 years, and nobody noticed it? And the answer was: Because we have not enough patrollers, and it went unpatrolled.(Unpatrolled status for any edit expires after 30 days)
I propose:

  • All IP edits should be patrolled/reviewed, or, if X days pass and it wasn't patrolled, the edit should be automatically undone.
  • The same for edits by non-autoconfirmed users to files or pages uploaded/created by other users.
  • For all other edits or file uploads: users should gradualy earn a reputation score. The first file upload or edit by any user should always be carefully patrolled for sure. The same for the next 4 or 5 uploads. From there on, most edits should be reviewed for a user that has an edit count of 20-30, but for one who has 80, reviewing half of the editions may be enough. When the user has 200, maybe just random patrolling some edits is just enough. Of course, if a user has bad behaviour or uploads copyvios, his/her score would be downgraded.
  • When users meet the requirements for having autopatroller status, it should be always granted automatically or semi-automatically, so the patrolling backlog doesn't grow unnecessarily. MGeog2022 (talk) 16:58, 6 December 2024 (UTC)[reply]
 Oppose I see your concerns, and the attempted IP revert is an abuse filter working. The reason we have decade old copyvios is because we don't have people looking through decade old uploads, we just focus on new ones. This doesn't solve the issue, only prevents new users from making any contributions. Commons has over 100 million files, there are going to be mistakes. If we undid every edit made by accounts with less than 10 edits, we lose the work of people who come over from other wiki's to help clean up in forgotten corners of commons. All the Best -- Chuck Talk 17:06, 6 December 2024 (UTC)[reply]
and the attempted IP revert is an abuse filter working: yes, I agree that it's a very good thing that IP users and prevented from undoing random edits or removing content (is something we would certainly miss if it did not exist). What I don't understand in this case is why there was no abuse filter to prevent an IP user editing a description and adding the "ass" word to it, or a bot to quickly revert it.
The reason we have decade old copyvios is because we don't have people looking through decade old uploads, we just focus on new ones: OK, I wasn't aware that those things were not so likely to happen with recently uploaded files.
If we undid every edit made by accounts with less than 10 edits: I wasn't proposing that. Only if for some reason those edits weren't reviewed (and only for edits to files uploaded by other users, not for their own files), they could be automatically reverted, while notifying the user about the reason, so they could try it again (by that point, they probably would already be autoconfirmed users). Another option would be unpatrolled status not expiring for such cases of new users. MGeog2022 (talk) 17:23, 6 December 2024 (UTC)[reply]
we lose the work of people who come over from other wiki: that's another good point. I think that the good or bad profile of a user should be cross-wiki. A user with a good background in Wikipedia, should come to Commons with this same background. For example I'm now autopatroller in Commons. Perhaps time is being lost patrolling my edits in other wikis, and maybe other edits that need reviewing go unnoticed because of that. If a user is trusted in Commons, I see no reason for him/her not being trusted in Wikipedia, Wikibooks, etc. MGeog2022 (talk) 17:39, 6 December 2024 (UTC)[reply]
There are a lot of reasons why Cross-wiki "reputation" is a bad idea. If that happens, anyone with a username against Any wiki's username policy would automatically be flagged or blocked. If you want to see why this is a bad idea, look at my Second LR request or this ANU report. Both of these aren't actually issues, just look at my En-wiki talk page. Cross Wiki reputation is a very bad idea. Also, I would guess 30% or more of edits go unpatrolled, but most vandalism is caught because we don't start an Unicode arms race for explicit words. Blatant vandalism is very obvious, and Is caught by filters for words like "ass" and sent to CVN patrollers on IRC, along with every blank category creation, account creation, blacklisted action, IP edit, and deletion performed on commons. All the Best -- Chuck Talk 17:53, 6 December 2024 (UTC)[reply]
I would guess 30% or more of edits go unpatrolled: that is what my proposal is about: trying to have from 0% unpatrolled for really risky users, to 50% for an user who is starting to show good signs, to 100% for any user who can qualify as autopatroller. I think that something such as "partially autopatrolled" users, with varying degrees, could be a good thing, to minimize the risks for that 30% that will be unpatrolled. In any case, maybe I overestimated the risks, and there are already enough mechanisms in place (the vandalism by an IP that I saw was only a few minutes old, it would probably have been reverted soon in any case).
Cross Wiki reputation is a very bad idea: maybe there are things that are very wiki-specific, but others don't. Someone who has vandalized Wikipedia is highly likely to vandalize any other wiki. Someone who has thousands of edits in Wikipedia, with no vandalism, copyvio or wrongdoing record, could be considered autopatrolled in Commons, if not since the first upload, from the 5th, without needing to have 500 edits (and then asking for autopatrol rights or an administrator granting them to him/her). If autopatrol rights for that hypothetical well-established Wikipedia user arrives when he/she has 1500 edits in Commons, the effort for that 1495 patrol actions could have been invested in new or problematic users, or random checking edits from users that still have a quite low edit count or have made some minor mistakes in the past.
For what I see in your enwiki talk page, you've had a blocking problem on enwiki (I'm not aware of the exact reasons behind). I understand that, from your personal experience, you can't support cross-wiki evaluation of users. It would also be my case if I had suffered a block, especially if it was an unfair one, but it's difficult to be impartial with something that has affected one personally. MGeog2022 (talk) 20:25, 6 December 2024 (UTC)[reply]
The funny thing about xwiki vandals is that the CVN does a pretty good job of blocking and glocking vandals as needed, and Doesn't need to be enforced with automatic reverts, as how can it (efficiently) tell if an unpatrolled edit is the current version, or if it is already reverted? Reverted/rollbacked edits are marked as patrolled, and if edits aren't immediatly rollbacked, reverted or patrolled are ok All the Best -- Chuck Talk 16:09, 9 December 2024 (UTC)[reply]
Certainly, vandalism cases are not the best example, since recurring vandals will always get blocked. People with little knowledge of copyright, or who tend to make controversial edits, would be better examples. A person who doesn't need supervision on Wikipedia, because of having a good background, isn't likely to need it in Commons, once he/she has made some edits and uploaded some files: I think that 500 edits in Commons wouldn't be needed to become autopatroller in those cases. For the remainder, OK, I'm probably overstating the problem, and all of this has already been raised and solved long time ago. MGeog2022 (talk) 13:45, 11 December 2024 (UTC)[reply]
How do unpatrolled uploads work? are they just automatically deleted after 30 days. All the Best -- Chuck Talk 16:34, 11 December 2024 (UTC)[reply]
IP users can't upload files. The only other case for which I proposed that automatic deletion if unpatrolled was:
The same for edits by non-autoconfirmed users to files or pages uploaded/created by other users.
So the automatic deletion would apply to no uploads at all. MGeog2022 (talk) 20:49, 11 December 2024 (UTC)[reply]
(But I understand that this part of my proposal may not be considered the most appropriate; maybe the general concept of priority-based patrolling and automatically or semi-automatically autopatrolled users, as exposed in my last 2 points, could be more interesting) MGeog2022 (talk) 20:52, 11 December 2024 (UTC)[reply]
Patrolling already has a massive backlog, and just granting autopatrolled more easily would help solve the problem (that and requiring auto patrolled to use cat-a-lot...) All the Best -- Chuck Talk 18:13, 12 December 2024 (UTC)[reply]
But this only decreases the numbers. The main problem are IP users. As I think all patrollers filter for user type and tag patterns when patrolling edits such a change would not decrease the real backlog of edits they need to be reviewed, GPSLeo (talk) 18:30, 12 December 2024 (UTC)[reply]
There also just aren't enough patrollers as it is. All the Best -- Chuck Talk 18:31, 12 December 2024 (UTC)[reply]
The problem with patrolling is that, unless I'm missing something, there simply is no easy way to patrol anything but the absolute most recent edits, there's no "sort by oldest" etc. Gnomingstuff (talk) 08:10, 16 December 2024 (UTC)[reply]
In RTRC, using "descending" as the sort option will have the desired effect. All the Best -- Chuck Talk 16:31, 16 December 2024 (UTC)[reply]
 Support, as proposer. MGeog2022 (talk) 17:28, 6 December 2024 (UTC)[reply]

Preventing uncategorized files

[edit]

Since uncategorized files are always a problem, I propose:

  • Upload Wizard should require to select at least 1 category for any uploaded file. If there is a particular reason for not doing so, it should, at least, make it clear that it is something that is not recommended at all. Maybe the wizard could suggest a category based on the file name, description, or its content, to help unexperienced users who know nothing about categories.
 Support, as proposer. MGeog2022 (talk) 17:28, 6 December 2024 (UTC)[reply]
 Oppose When you force people to pick a category, they often pick a badly chosen one, and instead of the problem being visible, it is hidden, plus some category gets an inappropriate file. - Jmabel ! talk 18:34, 6 December 2024 (UTC)[reply]
Maybe this is just the particular reason that I talked about on the first point, then :-)
The second point would still remain in place, unless there is already some filter working to prevent that from happening. MGeog2022 (talk) 20:31, 6 December 2024 (UTC)[reply]
Still disagree. If all the categories on a file are bad, we are better off with them simply being removed. E.g. someone uploads a picture of a politician and places it only in Category:Dogs. Removing that is beneficial, even if someone doesn't add a good category. - Jmabel ! talk 22:22, 6 December 2024 (UTC)[reply]
Good point, but it would be very easy to add Category:Politicians (or a more precise one) in its place. In any case, it seems that this proposal isn't gaining much support. For the case that a file is left with no categories due to pure vandalism, there are probably other ways of detecting and solving it, which I may be underestimating, as might have also happened in my proposal above. Other than that, perhaps this isn't so easy to happen. MGeog2022 (talk) 11:58, 7 December 2024 (UTC)[reply]
 Oppose per jmabel, couldn't have said it better myself. (I still think that all AI images should be subject to LR for this reason, but I digress) All the Best -- Chuck Talk 18:36, 6 December 2024 (UTC)[reply]
 Neutral for now. I support this part: it should, at least, make it clear that it is something that is not recommended at all. Maybe the wizard could suggest a category based on the file name, description, or its content, to help unexperienced users who know nothing about categories. Does the UW not show some message asking the user to add a category if none is added? If so that would be good to add. Suggesting likely fitting / relevant categories would be something for a later point and it may be difficult. Prototyperspective (talk) 18:48, 6 December 2024 (UTC)[reply]
The Android app that recommended "depicts" was an almost unmitigated disaster. I can't see why a tool would do a better job of recommending categories. - Jmabel ! talk 22:24, 6 December 2024 (UTC)[reply]
Good point and that's partly why I only support the part about prompting the user to add categories if a file does not have any and I said it may be difficult. Maybe it works well for some kinds of categories like suggesting the category for a location if the image has GPS exif data or "Audio files of music" if it's an audio files with the description containing word "music" etc. No categories is better than setting inappropriate categories and thereby polluting the categories. Prototyperspective (talk) 12:12, 7 December 2024 (UTC)[reply]
  •  Oppose This is a good idea in theory. The problem is that there are essentially no standards for categories and a lot of them are extremely ambiguous. To the point of the category being worse then none at all in a lot of cases. If it's between someone adding Category:History to an image simply because they are forced to and it depicts something that looks old versus the image not being categorized at all, then the better option is clearly it not having a category to begin with. I think it would be a good idea to require categories if or when ambiguous ones don't exist anymore. I doubt that will happen any time soon with how lax the whole thing is at this point though. --Adamant1 (talk) 04:32, 7 December 2024 (UTC)[reply]
  •  Oppose, as others have said, this is an ideal that will likely hide as many problems as it fixes. CMD (talk) 05:54, 7 December 2024 (UTC)[reply]
  •  Oppose per Jmabel et al. Andy Dingley (talk) 18:34, 8 December 2024 (UTC)[reply]
 Oppose I hate doing this because in principle, I think this is a good idea, but I do not think at all this would go well in practice. Bastique ☎ let's talk! 22:51, 9 December 2024 (UTC)[reply]

Treat COM:DR and COM:CFD as policies

[edit]

I propose treating subpolicy pages COM:DR and COM:CFD as policies subservient to COM:DP by using {{TNT|policy}}, or adding unescaped Category:Commons policies.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:41, 12 December 2024 (UTC)[reply]

@Jeff G.: could you make a clear statement here of what problem you are trying to solve? Right now, this is a proposed solution with no clear problem. - Jmabel ! talk 19:37, 13 December 2024 (UTC)[reply]

@Jmabel I want people who make incomplete deletion requests to be called out for violating policies; the best verbiage I have right now is "subpolicy procedures". I am willing to compromise on calling them guidelines. I do not anticipate calling out deleting Admins.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:19, 14 December 2024 (UTC)[reply]
@Jeff G.: I would think usually incomplete deletion requests are more a matter of ignorance or incompetence than ill intent. Making the process document into a policy document doesn't really increase the chance that they will find it. - Jmabel ! talk 01:13, 14 December 2024 (UTC)[reply]

Deletor user group proposal

[edit]

Hi there! I believe we need the "Deletor" user group. This hypothetical user group only focus on immediate deletions. Not copyvios nor other speedy deletions(such as F10, G10). I mean this is for the files about "blatant and direct violations of Terms&Use". These kind of images needs to deleted in minimum needed time. After immediate deletion, a script or user himself or a bot will notify administrators; maybe in separate dedicated page or in deletion requests page. This is for to prevent abuse of this system.

You would say "Admins already take care of these images". But my point here is minimize the duration of stay on backlog. We can and should lower that time.

So... what should we do? modern_primat ඞඞඞ ----TALK 18:54, 17 December 2024 (UTC)[reply]

This is simply a nonsense request. Contact an active admin and get it done. ─ Aafī on Mobile (talk) 18:56, 17 December 2024 (UTC)[reply]
@Modern primat Which sorts of files could the "Deletor" user group delete then? If it's solely for CSAM, then I disagree that this is needed: report to legal-reports, flag down an admin on IRC/Discord/Telegram/etc. (making sure not to do anything that could draw attention to the file), done. If not, what exactly would be allowed to be deleted by this group? —‍Mdaniels5757 (talk • contribs) 19:20, 17 December 2024 (UTC)[reply]
it is for CSAM. modern_primat ඞඞඞ ----TALK 19:30, 17 December 2024 (UTC)[reply]
Administrators are not generally the right people to deal with CSAM. Among other things, we can only do a soft deletion. Of course, if we see it, we delete it and then report it for hard-deletion through the same channels anyone else would use to report it, but this is a job for the people at legal-reports; it is certainly not a job for Commons users we would not even trust to be admins. - Jmabel ! talk 05:11, 18 December 2024 (UTC)[reply]
This was discussed multiple times in the last years with a clear consensus against such a user group. There are technical and legal problems with such a user group and there are no people trustworthy enough for such a right but not trustworthy for admin rights. The only feature that might be supported by most would be something like a G7 deletion functionality for trustworthy users like patrollers. GPSLeo (talk) 19:25, 17 December 2024 (UTC)[reply]

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

[edit]

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

Background

[edit]

The WMF has been (at least ostensibly) collaborating with us during its Upload Wizard improvements project. As part of this work, we have the opportunity to reexamine the step that occurs after a user uploads a work that they declare is someone else's work but not protected by copyright law. They are then presented will several default options corresponding to public domain license tags or a field to write in a custom tag:

It is unclear why these are the specific options presented; I do not know of the original discussion in which they were chosen. This RfC seeks to determine whether we should add or remove any of these options. I have added one proposal, but feel free to create subsections for others (using the format Add license name or Remove license name and specifying the proposed menu text). Sdkb talk 20:19, 19 December 2024 (UTC)[reply]

[edit]
Tracked in Phabricator
Task T376522

Should {{PD-textlogo}} be added, using the menu text Logo image consisting only of simple geometric shapes or text? Sdkb talk 20:19, 19 December 2024 (UTC)[reply]

  •  Support. Many organizations on Wikipedia that have simple logos do not have them uploaded to Commons and used in the article. Currently, the only way to upload such images is to choose the "enter a different license in wikitext format" option and enter "{{PD-textlogo}}" manually. Very few beginner (or even intermediate) editors will be able to navigate this process successfully, and even for experienced editors it is cumbersome. PD-textlogo is one of the most common license tags used on Commons uploads — there are more than 200,000 files that use it. As such, it ought to appear in the list. This would make it easier to upload simple logo images, benefiting Commons and the projects that use it. Sdkb talk 20:19, 19 December 2024 (UTC)[reply]
    Addressing two potential concerns. First, Sannita wrote, the team is worried about making available too many options and confusing uploaders. I agree with the overall principle that we should not add so many options that users are overwhelmed, but I don't think we're at that point yet. Also, if we're concerned about only presenting the minimum number of relevant options, we could use metadata to help customize which ones are presented to a user for a given file (e.g. a .svg file is much more likely to be a logo than a .jpg file with metadata indicating it is a recently taken photograph).
Second, there is always the risk that users upload more complex logos above the TOO. We can link to commons:TOO to provide help/explanation, and if we find that too many users are doing this for moderators to handle, we could introduce a confirmation dialogue or other further safeguards. But we should not use the difficulty of the process to try to curb undesirable uploads any more than we should block newcomers from editing just because of the risk they'll vandalize — our filters need to be targeted enough that they don't block legitimate uploads just as much as bad ones. Sdkb talk 20:19, 19 December 2024 (UTC)[reply]
 Oppose. Determining whether a logo is sufficiently simple for PD-textlogo is nontrivial, and the license is already frequently misapplied. Making it available as a first-class option would likely make that much worse. Omphalographer (talk) 02:57, 20 December 2024 (UTC)[reply]
 Comment only if this will result in it being uploaded but tagged for review. - Jmabel ! talk 07:14, 20 December 2024 (UTC)[reply]
That should definitely be possible to implement. Sdkb talk 15:13, 20 December 2024 (UTC)[reply]

General discussion

[edit]
This is for discussion about the menu options as a whole. Put discussion about specific add/remove proposals in their respective subsection.

Courtesy pinging @Sannita (WMF), the WMF community liaison for the Upload Wizard improvements project. Sdkb talk 20:19, 19 December 2024 (UTC)[reply]

Thanks for the ping. Quick note: I will be on vacation starting tomorrow until January 1, therefore I will probably not be able to answer until 2025 starts, if needed. I'll catch up when I'll have again a working connection, but be also aware that new changes to code will need to wait at least mid-January. Sannita (WMF) (talk) 22:02, 19 December 2024 (UTC)[reply]
Can we please add a warning message for PDF uploads in general? this is currently enforced by abuse filter, and is the second most common report at Commons talk:Abuse filter. And if they user pd-textlogo or PD-simple (or any AI tag) it should add a tracking category that is searched by User:GogologoBot. All the Best -- Chuck Talk 23:21, 19 December 2024 (UTC)[reply]
Yes, please. Even with the abuse filter in place, the vast majority of PDF uploads by new users are accidental, copyright violations, and/or out of scope. There are only a few appropriate use cases for the format, and they tend to be uploaded by a very small number of experienced users. Omphalographer (talk) 03:11, 20 December 2024 (UTC)[reply]

Media Blureing And Censoring

[edit]

On Wikimedia there has been some inappropriate content and NSFW content and we should censor it by using the MediaSpoiler extension, to protect everyone. Do you agree? Wikan Boy 123 (talk) 06:36, 21 December 2024 (UTC)[reply]

A simple word shall suffice as answer: No. I do not agree. Regards, Grand-Duc (talk) 07:57, 21 December 2024 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=973403578"