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/2023/10.
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.
With this there is also the question if we want to revert all edits made through the tool. This would affect one and a half million edits made through the tool. We could except edits made by users with autopatrol rights from the revert to reduce the amount of potential good edits getting lost in the revert. GPSLeo (talk) 12:49, 16 September 2023 (UTC)Reply[reply]
I come across these mistakes very frequently. And the bot tags are completely inaccurate. When I look at the file's history, no one but the bot has edited it. What the solution is, I do not know, but I belief is that the Commons has been massively harmed by bot tagging. Krok6kola (talk) 15:25, 16 September 2023 (UTC)Reply[reply]
The WMF classed 73.4% of such values as "bad". Absent an alternative proposal, I think this is inevitable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 16 September 2023 (UTC)Reply[reply]
If we mass revert, then the bot should leave an edit summary that encourages anyone watching the file to check to see if what it has reverted should be restored. After all, 26.6% of 1.5 million is not small. If they are right in their count, we would be having a bot revert about 400,000 good edits to get rid of 1.1 million bad ones. (BTW, I think the numbers are a bit misleading, because thousands of these edits were things like two people edit warring over the depicts on a file.) - Jmabel ! talk 17:14, 16 September 2023 (UTC)Reply[reply]
Do you refer to the ISA tool disaster? These edits are not marked as done with Computer-aided tagging. We should only include edits with the "computer-aided-tagging" tag, the ones with "computer-aided-tagging-manual" tag should also not be included. GPSLeo (talk) 17:22, 16 September 2023 (UTC)Reply[reply]
I doubt that any such edit wars were tagged as being by the Computer-aided tagging tool, so they won't be included in the figure given. Do you have any examples to the contrary? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:53, 23 September 2023 (UTC)Reply[reply]
Support bulk revert. Up to a simple bulk deletion of everything, if we have no better way to separate out the trash. Yes, it's that bad. Andy Dingley (talk) 15:01, 23 September 2023 (UTC)Reply[reply]
Support I don't see any other way. Of course, the bot reverting the tags should leave a proper entry in the history. --Robert Flogaus-Faust (talk) 15:08, 23 September 2023 (UTC)Reply[reply]
Comment - It would be worth of save the added values to file or something before bulk reverting them so if somebody would like try to filter out useful ones (using machine vision for example) I think something like open_clip could work for finding useful tags and I could could do a practical test if the idea works at october. --Zache (talk) 18:28, 23 September 2023 (UTC)Reply[reply]
…from orbit — it's the only way to be sure -- Tuválkin✉✇ 10:54, 24 September 2023 (UTC)Reply[reply]
Comment has anyone asked the tech team to share the list of what they determined to be "good" edits so we can assay whether it looks like there would be a fair amount worth keeping? But I wouldn't object to just deleting it all. One ham-handed mass edit deserves another.
Edit summary should make clear that this is "without prejudice" and if you think the item was correct you should feel free to re-add. - Jmabel ! talk 15:58, 24 September 2023 (UTC)Reply[reply]
if possible, only revert edits made by users who are merely autoconfirmed or not even autoconfirmed. any user with autopatrol or more advanced user right can be assumed to have used the tool properly. RZuo (talk) 08:33, 13 November 2023 (UTC)Reply[reply]
Increase of file size limit on Commons for future-proof purposes[edit]
Hey folks!
The current file size limit is 4 GiB (approx. 4.3 Gigabytes), see COM:MAXSIZE. I want to propose a increased file size limit. The limit was increased in April 2016 from 2 to 4 GiB.
Since then, the sizes of files increased over time due to larger video resolutions.
I want to give some examples when files exceed the 4 GiB threshold:
4K YouTube videos after 25-35 minutes
FHD DSLR/DSLM videos 8-15 minutes
4K DSLR/DSLM videos after 2.5-8 minutes
8K DSLR/DSLM videos after 1.25-4 minutes
Videos for example exceed the size limit of 4 GiB quite fast, but also high-resolution scans of 3D objects from organizations like the Smithsonian Institution may offer files that are larger than the limit (and where file splitting is very problematic). I have a large aerial image of Munich that is also too large right now, but offers many details. Over time, more and more files will come into conflict with this limit, as cameras etc. will become more capable. I would like to propose an increase to 32 or 64 GiB if possible. When colored meshes on Commons will be available, a higher file size limit would also be very appreciated.
Thank you for mentioning, I hope this issue will be served soon :) --PantheraLeo1359531 😺 (talk) 20:21, 9 October 2023 (UTC)Reply[reply]
Comment It was recently made possible to upload files up to 5 GB. I don't know when this will be live. See phab:T191805. Yann (talk) 17:29, 2 November 2023 (UTC)Reply[reply]
While the filesize is likely to increase a bit in the short term (year?) to 5GB (as mentioned by yann), a further rise is very unlikely to happen any time soon. Reasons:
1. It costs a TON of money. Big file handling is expensive. Much more expensive than text. Not just in storage (originals, backups), but also in network cost (all files have to be moved over the internal network), hardware costs (plain server capacity). There is currently 440TB of originals, 22TB of original video. And then a not exactly known amount of derivatives of those originals (thumbnails and smaller versions of the big videos). In many ways, video is already creating a 'disproportionate' impact, compared to how much it is used by the users.
2. Anything over 5MB basically cannot be send to a browser. Therefore you need to thumbnail, postprocess etc. So CPU, and yet more datastorage to store the results of that. Specifically in the above example you are speaking about things like 8K, that not even Youtube is doing (publicly). And that is for a good reason. Handling such big files essentially requires purpose designed hardware to do the decoding and encoding (GPU, or like Youtube, who design and manufacture their own hardware for this). It cannot really be done with the generic compute power that we have available within Wikimedia. I advise watching this video by LTT, where they comment on last year's Youtube experiment of charging for 4K. LTT runs their own video website called https://www.floatplane.com so they have some experience with the cost of high res video.
3. Media handling is unresourced by WMF. As in, there are 0 engineers dedicated to improving and modernizing the multimedia stack. The only effort spend is on keeping the current multimedia stack alive.
4. It is pretty hard to be AND wordpress AND the internet archive AND youtube AND thingiverse AND Wolfram Alpha on a shoestring budget. Wikimedia always has been 10+ years behind these websites and is likely to remain so. We can't scale like them, because we don't have a narrow focus, and because expertise at the bleeding edge is very expensive. Just waiting 10 years is the affordable way to get there.
5. The entire infrastructure for filestorage currently has a 5GB limit. Files above that size cannot be addressed, without major re-architecting of the storage layer used by Wikimedia. This rearchitecturing is unlikely to happen due to the earlier mentioned points.
The best solution for this is still to host these on a separate archive site, and upload a smaller more websuitable version to Commons. —TheDJ (talk • contribs) 19:54, 2 November 2023 (UTC)Reply[reply]
Thank you very much for giving insights into this issue! The 5 GiB limit is a good thing to hear! Maybe we get a solution some time that is a compromise between resources and upload limits :) --PantheraLeo1359531 😺 (talk) 18:27, 4 November 2023 (UTC)Reply[reply]
Otherwise we have to ask Google for server (technology) support ;D --PantheraLeo1359531 😺 (talk) 18:31, 4 November 2023 (UTC)Reply[reply]
TheDJ, thanks from me, too, for your insightful statement. It continues to frustrate me that the WMF, with its heaps of donator money to spend, is allocating so few resources and investment to Commons. In my view, "In many ways, video is already creating a 'disproportionate' impact, compared to how much it is used by the users" is just one side of the coin: The very poor support of video on Commons isn't encouraging use - but it could be very valuable and an alternative to increasingly heavily commercialized platforms such as YouTube (which is now starting banning adblockers). Commons is the only truly free media platform where users don't pay with their personal data or with money for use, and I think it needs strengthening. The WMF has the money, more than enough, it's only a matter of willingness. A "shoestring budget" is not an inevitability - it's well known that the WMF's assets have risen each year by many millions. I certainly would not ask Google for any technology support, though, as I think this is one of the corporations we should distance us from. Gestumblindi (talk) 10:26, 9 November 2023 (UTC)Reply[reply]
Millions is still a shoestring when it comes to video. This is another example of people having no idea how much organisations like Google spend on stuff like this. Start thinking in billions. —TheDJ (talk • contribs) 11:49, 9 November 2023 (UTC)Reply[reply]
Compare with w:Vimeo. Half a billion revenue and still 80 million of losses in a year. So we'd need almost 600 million of donations a year to do what they do. And it's the only thing they do, they don't have to worry about anything but video. —TheDJ (talk • contribs) 11:56, 9 November 2023 (UTC)Reply[reply]
Well, I would be happy with a far more limited offering than YouTube or Vimeo have, I don't think we need 4K or even 8K; all I ask for is a reasonably smooth upload and use of medium-sized, medium-quality video (I think Full HD - 1080p - shouldn't be too much to ask?), and we don't have even that, it's all very rickety. Gestumblindi (talk) 19:24, 9 November 2023 (UTC)Reply[reply]
Personally, I think 5 GiB is enough for Commons. Our purpose is education, not entertainment. We don't need 8K videos to explain how mitochondria work. 480p works fine. 1080p is probably overkill. And 4320p (8K) is just totally unnecessary. What we need is better quality video content, not better video resolution. Nosferattus (talk) 16:46, 9 November 2023 (UTC)Reply[reply]
I think it depends on the video content how important resolution is. For simple animations, FHD is certainly enough. For historical (modern) events for example, 4K or even 8K is probably really appreciated, for documentation purposes. --PantheraLeo1359531 😺 (talk) 19:31, 12 November 2023 (UTC)Reply[reply]
Addition: Is 8K unnecessary? Not always. 8K first of all allows cropping to distinct areas in the video. And let's take a video of a collapsing building, recorded in 8K, we can extract single images with a resolution of many full-frame cameras. If we take pictures from YouTube in Full HD, we usually have a quite low level of detail. --PantheraLeo1359531 😺 (talk) 19:38, 12 November 2023 (UTC)Reply[reply]
Once we are here, is the total size (of uploads smaller that 5Gb) a problem? Are we safe for the time being, or is there a chance that WMF soon will not be able to host the entire volume of the files (say photos, not videos) which significantly grows every day?--Ymblanter (talk) 21:12, 9 November 2023 (UTC)Reply[reply]
In my opinion, I see no problem regarding hosting. Right now we have at least ca. 480 TB. It is common that modern datacenters have 1.5 petabyte or more. With a yearly growth of ca. 80 TB in 2022, it will take time until Commons hits this threshold. I could also imagine WMF has some reserves, even if the data amount grows even faster. 1 Petabyte could be reached with 50x 20 TB hard disk drives. Probably, the used disks are smaller in capacity. If Commons will acquire several terabytes at once, this could be challenging, but I assume that we're save. --PantheraLeo1359531 😺 (talk) 19:35, 12 November 2023 (UTC)Reply[reply]
Flickr has database which vastly greater than Commons and I see no problem with it. Юрий Д.К 06:35, 15 November 2023 (UTC)Reply[reply]
But Flickr, after it was bought by SmugMug, decided that it can not keep expanding, that the database was already too big, and users must pay if they want to be above the (pretty moderate) limit. Ymblanter (talk) 18:29, 15 November 2023 (UTC)Reply[reply]
According to this website, flickr has 10 billion images. We are far away from that :) --PantheraLeo1359531 😺 (talk) 19:19, 20 November 2023 (UTC)Reply[reply]
Even more than that — according to the Flickr Foundation presentation at GLAMWiki last week, it's more like 50 billion! SamWilson 00:14, 21 November 2023 (UTC)Reply[reply]
If I'm interpreting [1] right, i think we are currently at 821TiB (presumably one of those lines is Eqiad data center and the other is codfw, but I'm just guessing). Presumably there might be multiple copies of media stored to guard against hardware failure. Generally I would suggest not worrying about server capacity as long as you are doing something useful to the mission unless someone from the WMF SRE team specifically says to worry. After all, the reason we have servers is so they are used. Bawolff (talk) 04:02, 24 November 2023 (UTC)Reply[reply]
I'm not so worried about storage space myself, but the upload wizard doesn't seem to be very reliable and I don't think people should be able to upload extremely large files until there's at least a way to resume uploads. Otherwise there's really no point. If I can't even upload a 200mb image as someone with fast cable internet because it just times out then there's really no point though. --Adamant1 (talk) 04:10, 24 November 2023 (UTC)Reply[reply]
Hello, I quite often use the Gallica Template to source my uploads. Is there anything like that for the Léonore Database? If not, could this be done? Thanks in advance. William C. Minor (talk) 05:14, 15 October 2023 (UTC)Reply[reply]
We have templates for all types of sources (e.g. France-related ones), but I couldn't find one for Léonore. If this is a source we regularly use, it certainly makes sense to create a template. --rimshottalk 07:18, 3 November 2023 (UTC)Reply[reply]
Hi. I propose to change the technical name of the license reviewer user group from image-reviewer to license-reviewer. This will make it in consistent with the group's real name, and also in general everyone uses the term "license reviewer" and not "image reviewer", and it is correct too, as the group members review all type of files and not just images. I see no reason why this shouldn't be done. We'll have to do following things for this:
Request on Phabricator for technical stuff (config, WikimediaMessages, migration...)
I do not think this is a problem. The technical term for Admins is sysop and for Oversighters it is suppress. But if we do a change here we should also consider the proposal I made some month ago (Should we simplify user rights?) to remove the dedicated rollback right and give this right to all patrollers and license reviewers. GPSLeo (talk) 15:27, 2 November 2023 (UTC)Reply[reply]
I personally dislike sysop for admins as it is no longer relevant and can be confused with system administrators but it is a MediaWiki core setting so a big mess and not in our hands, while the license reviewer is a local Commons group, so it makes sense to keep it consistent and updated, and it is in our hands so easy to manipulate. For the proposal you linked, I personally agree with Mdaniels5757 there. For now, I'd say let's please keep that seperate as then this proposal will be wider in scope then it's original non-controversial (?) subject. -- CptViraj (talk) 17:26, 2 November 2023 (UTC)Reply[reply]
Not to say I'm against the idea, but don't you think "license-reviewer" is to close in wording (if not purpose) to the Volunteer Response Team or that there is a chance people will mix them up? --Adamant1 (talk) 20:10, 2 November 2023 (UTC)Reply[reply]
Well, non/new users have always confused them and will continue to do so. But I have never seem them calling it image reviewer, as our help and project pages use the term license reviewer and established users also use the latter term in general except while talking in technical way, so I believe it won't make a much difference for them. Even if they are using/reading/understanding the former term then it could be misleading for them as it suggests that the group members review only images but that's not the case, they can also get confused believing license-reviewer and image-reviewer are two different user groups, so I think it makes sense to change it and make it consistent. And for us, established contributors, who understand workings, It was license reviewer with VRT access or without VRT access, and will remain the same. -- CptViraj (talk) 09:13, 3 November 2023 (UTC)Reply[reply]
@CptViraj: Wouldn't that be solved by calling it "file reviewer" then? I don't think just because "image" doesn't work that it necessarily means "license" does. --Adamant1 (talk) 20:33, 4 November 2023 (UTC)Reply[reply]
@Adamant1: The sole role of the user group is to review licenses, and that's what it makes different from patrollers, otherwise files can be reviewed by patrollers, too. So I believe 'file reviewer' could cause confusion. Also 'license reviewer' has become a common name now, changing it completely won't be a good idea IMHO. -- CptViraj (talk) 21:12, 4 November 2023 (UTC)Reply[reply]
That makes sense. Thanks for clarifying it. --Adamant1 (talk) 16:08, 6 November 2023 (UTC)Reply[reply]
Weak oppose I do not see the need for the change of this internal parameter. A change could break a lot of (unmaintained) tools. --GPSLeo (talk) 16:10, 6 November 2023 (UTC)Reply[reply]
Support it is never too late to implement the changes required. Thanks --C1K98V(💬✒️📂) 06:35, 7 November 2023 (UTC)Reply[reply]
Oppose per GPSLeo. It's a purely cosmetic change that has the potential to break things. Commons is already struggling under backlogs basically everywhere; if we lose a tool or two it'll only get worse. The Squirrel Conspiracy (talk) 10:42, 7 November 2023 (UTC)Reply[reply]
Weak oppose I would support a change, provided the concerns by GPSLeo and The Squirrel Conspiracy are addressed. We are risking here that tools are not updated accordingly and would need to know beforehand what could possibly break and who is ready to fix it. Filter 70 would have to be updated as well. --AFBorchert (talk) 15:57, 7 November 2023 (UTC)Reply[reply]
In the proposal itself, I have already listed the on-wiki things (including the AF above) that will need updating. If anyone know any other gadgets/tools/scripts/etc.. please help list them, leftovers can be fixed. I'll be happy to update the things that I could, will surely appreciate more hands. A cosmetic change but IMO we shouldn't be afraid to do them when it is possible without causing heavy disruption, this isn't going to shut the site, the group has been renamed before. This isn't gonna get implemented overnight, discussion is likely going to be open for several months, all the replacement points can be found out, and if passed, we can do it with proper planning, thus minimising the chances of breaking things but I cannot guarantee 100% smooth transition, after all these things is a process of continual refinement. -- CptViraj (talk) 19:19, 8 November 2023 (UTC)Reply[reply]
Weak oppose I don't see a large benefit and it could potentially break unmaintained tools. The previous renaming to fix the capitalization seems like it was a lot of work to coordinate. Apparently fawiki also uses this user group, so it would need to be coordinated with that wiki as well. Frankly, it doesn't seem like it's worth all the effort. Nosferattus (talk) 16:16, 9 November 2023 (UTC)Reply[reply]
Hi. The work you see on phab is on system administrator/patch uploader's side (could be volunteer or staff), I'm sure they won't refuse to help and implement if there is consensus, some of it was done with maintenance scripts (semi-automatic), some of it won't be required as they were one-time fixes, if you see the dates, you can see that most of it was done on the same day. The previous rename was an uncontroversial maintenance change done by the sysadmins themselves to make the user groups in line with others, it included both fawiki's group as it required fix too but that's not a case here. The fawiki user group has nothing to do with ours, both are independent from each other. -- CptViraj (talk) 19:36, 9 November 2023 (UTC)Reply[reply]
Hi, I'm a fish out of water here, having temporarily escaped from the English Wikipedia. Today our featured image is the particularly beautiful picture of an Inuit harpoon, here[2]. I was wondering if there is any way to encourage creators of such beautiful images to consider also doing an option that includes a scale-bar? It's often quite obvious to the photographer how big the item is, but without anything for reference, much harder for an encyclopaedia-user. The inclusion of a ruler, or some object of known size, really helps. Maybe it could be included in a guideline somewhere, I don't know? This is absolutely not a criticism of those photographers kind enough to provide the really valuable resource that is Commons. This harpoon really is a gorgeous photo of a very significant item. Elemimele (talk) 21:14, 7 November 2023 (UTC)Reply[reply]
@Elemimele: it's certainly encouraged, but for an image which a private individual takes in a museum it's probably not an option. - Jmabel ! talk 22:00, 7 November 2023 (UTC)Reply[reply]
@Elemimele: Please have a look at the description where the size of the object is given as 172 x 9 x 6 cm. --AFBorchert (talk) 07:40, 8 November 2023 (UTC)Reply[reply]
@AFBorchert: , yes, the description is really useful. Since images can often be used without the description being immediately visible to the reader, would it be acceptable for Wikipedia editors etc. to use description dimensions to add an artificial scale-bar and re-upload it as a variant image where a visual indication of scale would be helpful in the target? Elemimele (talk) 18:01, 9 November 2023 (UTC)Reply[reply]
You can always create derivative works, and any given Wikipedia can always choose to prefer them (or not). - Jmabel ! talk 02:52, 10 November 2023 (UTC)Reply[reply]
Mass block that prevents all users from editing images should be reverted[edit]
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The new policy that has been enforced quietly and without much discussion over at Commons:Overwriting existing files has put a site-wide block on the ability of all editors (except those with relatively rare privledges) to edit images. This is in violation of both the spirit and normal practice of Wikipedia which encourages editing and fixing of errors and the improving of articles. It prevents users from fixing poorly uploaded images (very common) where they've been uploaded in low resolution from some government site. It prevents users from updating maps as they go out of date. It relies on users to add an unknown template in order to allow corrections to their images. This policy should be reverted. It's created a "lords and commoners" division with regards to image editing, something that is completely unknown across Wikipedia. Ergzay (talk) 19:42, 9 November 2023 (UTC)Reply[reply]
What alternative do you suggest to handle the huge amount of policy violating and harmful overwrites? GPSLeo (talk) 20:18, 9 November 2023 (UTC)Reply[reply]
Uploading under a different name is still allowed. Ymblanter (talk) 20:57, 9 November 2023 (UTC)Reply[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Asking for help for commons (beginners) 4.0...[edit]
I believe the issue has been discussed several times since at least 2016, but until recently (in 2022) there are edits by also experienced wikipedia editors searching for help at the talk page of Help:Contents and there are likely no answers to come. I suggest to remove the link to Help:Contents at the left sidebar of the dropdown menu (in version Vector 2022), and replace it with a link to Commons:Help desk below the one to the Village Pump instead. For Welcome (also a part of the Village Pump) a similar solution already exists. Paradise Chronicle (talk) 20:17, 11 November 2023 (UTC)Reply[reply]
I'm sorry, it's late and I'm tired, so maybe this is all on me, but I don't follow this proposal, or maybe it's that I don't use Vector 2022 so I don't know what dropdown menu you are talking about, but how would Commons:Help desk (a place to ask a question) replace Help:Contents (the top-level page of the "help" content. They seem to serve very different purposes. Are you saying we don't need to show people where to find help on their own, and should aim them all to asking questions to be answered by actual volunteers? That doesn't seem even vaguely scalable, so I'm guessing I've misunderstood. - Jmabel ! talk 02:35, 12 November 2023 (UTC)Reply[reply]
Hey dear Jmabel, sorry to keep you awake ː). No rush, don't worry, it's been like this for several years so if it stays like this a bit longer it'll be ok. And maybe it is also meant to be like this. In Vector 2022 there are three horizontal bars to the upper left, and if one hits them, a drop down menu shows up. And at the Help talk:Contents there are six discussions since 2014 out of which three are concerning on where help is to be found. Likely only six because most editors on commons already know there is hardly any help to receive there. But some still believed there will be help and I am pretty sure they'd have found some help much faster if they were directed to the Commons:Help desk. Paradise Chronicle (talk) 03:23, 12 November 2023 (UTC)Reply[reply]
Hehehe, yeah maybe it is meant to be like this, but it is a bit confusing, at least to me. I removed the protected redirect to the Help desk for now. Because when I hit that one, I was told only administrators could edit the page. Now the redirect works and one gets to ask a question straight. Paradise Chronicle (talk) 03:44, 12 November 2023 (UTC)Reply[reply]
i suggest restricting upload of webp files to autopatrol users (like mp3), because very often webp uploads are copyvio taken from the internet or previews of svg logos. RZuo (talk) 14:07, 22 November 2023 (UTC)Reply[reply]
Support Currently I would say 90% of WEBP files are copyright violations. Yann (talk) 15:19, 22 November 2023 (UTC)Reply[reply]
Support The vast majority of webp files uploaded here are copyvios. Exceptions for individual users are easy to add to an edit filter. Pi.1415926535 (talk) 20:05, 22 November 2023 (UTC)Reply[reply]
Support Seem ok to me. If we ever run until real problems with such a policy we can modify it. --Rosenzweigτ 08:53, 23 November 2023 (UTC)Reply[reply]
Support I wonder why we still have no such restriction. Юрий Д.К 11:56, 23 November 2023 (UTC)Reply[reply]
Support A lot of WEBP files I see when I check files are copyvios. Abzeronow (talk) 16:09, 23 November 2023 (UTC)Reply[reply]
Support I don't see how this could go wrong; this would definitely reduce copyright violations. 20upper 08:07, 25 November 2023 (UTC)Reply[reply]
Support per Yann's claim. I want to encourage good uploads, but Commons must also guard against copyvios. Recent proposals have an appropriate aim of reducing copyvios and patrolers' workload. The balance here favors restriction. Glrx (talk) 18:56, 25 November 2023 (UTC)Reply[reply]
There have been discussions about this every now and then on the template talk page, but they haven't generated any sort of clear consensus due to lack of consensus, so I'll ask the community here.
This template is overly broad. There are more specific templates avaliable (Category:PD US license tags), and it is always better to use a more specific PD template over this. Furthermore, having a very broad template would encourage copyright mistakes ("this would probably be PD"). Therefore, it should be deprecated and put on some kind of backlog. —MATRIX! {user - talk? - useless contributions} 21:26, 22 November 2023 (UTC)Reply[reply]
EDIT: It seems I have been a bit unclear on what deprecate means. I mean that we should add a custom non-transcluded edit notice to the top discouraging use (something like {{Deprecated}}).
Oppose This is still useful, when we know there is either no notice or no renewal. BTW this is used on 4,209,007 files. What do you propose to do with these? Yann (talk) 21:53, 22 November 2023 (UTC)Reply[reply]
@Yann: I say that we should not outright remove it for obvious reasons, but deprecate it and discourage its use. —MATRIX! {user - talk? - useless contributions} 18:20, 23 November 2023 (UTC)Reply[reply]
Oppose This is valid for pre-1923/24/25, etc. works. Just because something else exists doesn't mean this is inadequate. If anything, I'd propose getting rid of all the federal government tags we have, as it's irrelevant which agency or office published it. —Justin (koavf)❤T☮C☺M☯ 01:49, 23 November 2023 (UTC)Reply[reply]
Something could be in the public domain for all three of those reasons. You have a sensible "deprecate and discourage" proposal above which I could get behind, but is it really the best use of our time to go thru these millions of files? —Justin (koavf)❤T☮C☺M☯ 20:39, 23 November 2023 (UTC)Reply[reply]
@Koavf: I have struck out the "and put on some kind of backlog" part after seeing the number of files this template is transcluded to. I don't think anyone is going to manually sort millions of files. —MATRIX! {user - talk? - useless contributions} 21:39, 23 November 2023 (UTC)Reply[reply]
Oppose There are situations where we know a work is PD, but not the precise sub-reason. Or can be used by bulk uploaders on a batch of known-PD files where it would be onerous to figure out the reason file by file. Of course one of the others should be used if known, but it doesn't make this one invalid. The precise reason is not always relevant in other countries anyways (the lifetime of the author often is, even though irrelevant in the US), so the extra precision isn't always too helpful. And many countries have catch-all tags rather than split-out ones. If we want to add a note that a more specific tag is preferred, that'd be fine. Carl Lindberg (talk) 13:48, 23 November 2023 (UTC)Reply[reply]
"There are situations where we know a work is PD, but not the precise sub-reason" what do you mean? If it's before 1928 it's probably {{PD-US-expired}}. If it's 1928-1963 it's probably {{PD-US-not renewed}} etc etc. If anything, not providing a specific tag encourages copyright mistakes. —MATRIX! {user - talk? - useless contributions} 18:26, 23 November 2023 (UTC)Reply[reply]
Yes. You don't always know a date. Maybe you just know it's before some particular date, and therefore know it wasn't renewed, but it could be expired, no-notice or not-renewed. Or you don't know exactly when it was published. If you have full information, sure use a more specific tag, but you don't always have that full information. Carl Lindberg (talk) 19:04, 24 November 2023 (UTC)Reply[reply]
Support deprecation as better explained, this won't impede mass imports. I struck out my previous opinion. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 20:14, 23 November 2023 (UTC)Reply[reply]
CommentUser:DPLA bot tags hundreds of thousands of uploads with {{PD-US}}, presumably because Dominic is going on the DPLA's assurance that the materials are in the public domain, and the DPLA in turn is relying on libraries' assurance, and no one "upstream" of us is making any distinction as to why these materials are in the public domain. - Jmabel ! talk 22:40, 23 November 2023 (UTC)Reply[reply]
Comment It might be worthwhile to put a notice at the bottom that says "This license should not be used if a more specific license is valid." The Squirrel Conspiracy (talk) 02:01, 24 November 2023 (UTC)Reply[reply]
Definitely support adding something to that effect. Carl Lindberg (talk) 19:06, 24 November 2023 (UTC)Reply[reply]
I also support such a mention. Yann (talk) 09:39, 26 November 2023 (UTC)Reply[reply]
Support Although it's kind of pointless if the template is being automatically added to files by the DPLA bot. But conversely, there should really be more of an effort on the DPLAs end to use more specific licenses when they can anyway per The Squirrel Conspiracy. Or at least on the bots/Dominics end if the DPLA doesn't want to do it themselves for whatever reason. --Adamant1 (talk) 08:56, 26 November 2023 (UTC)Reply[reply]
Support Deprecate for future uses. It should always be possible to be more specific. {{PD-old}}, a similarly broad and unspecific tag, is already marked as deprecated ("PD-old is a deprecated generic template which should not be used for new uploads"). Gestumblindi (talk) 12:47, 26 November 2023 (UTC)Reply[reply]
It is not always possible to be more specific. PD-old had a single direct replacement (and there is nothing preventing its use actually; the "deprecation" is only in its documentation). I would certainly support discouraging use of PD-US when one or more of the other specific tags can be used, which should be most cases, but I can't support altogether banning its future use. We certainly aren't going to fix the millions of existing uses. PD-US is still very useful for bulk uploaders, and in certain situations where we don't have full date knowledge, but enough to know it's PD beyond a significant doubt. I haven't needed to use it often, but I'm pretty sure I have a handful of times. The documentation does say If at all possible, please use a more specific tag so that aspect is covered in the documentation, though adding a similar note to the actual template may be a good idea. I think the tag has been removed from the upload tools as an easy option, which is also good. "Deprecating" in the style of PD-old, which is mainly just wording in the documentation, may be fine (though there are still valid uses, so it would only be deprecated when a more specific template can be used). Not sure that adding any non-transcluded element to the top is much different than the wording in the documentation really, though it could be made a little bit stronger. Carl Lindberg (talk) 15:57, 26 November 2023 (UTC)Reply[reply]
While there now exists Template:Editnotices/Group/Commons talk:Deletion requests that notifies users to make comments on the deletion request pages themselves, it is evidently ignored, as seen in 54conphotos' comments on the talk page of Commons:Deletion requests/File:KORWARM2.jpg (which I transferred to the main page and in Amustard's comment on a Turkmen deletion request which I subsequently transferred to the mainspace. As it is very evident that the edit notice is being ignored, I am proposing that the "Talk" namespace be disabled in all pages with prefix "Commons:Deletion requests/". This should be a permanent solution to the incidents that should have been better avoided. For existing talk pages of deletion requests with comments, the comments (including mine if ever I had responded to uploaders in the talk page namespaces) should be transferred to the deletion requests mainspaces, with consideration to the dates of the comments or inputs. JWilz12345(Talk|Contrib's.) 09:10, 26 November 2023 (UTC)Reply[reply]
Support At least, the use of DR talk pages should restricted to power users (admins, license reviewers?). Yann (talk) 09:37, 26 November 2023 (UTC)Reply[reply]
@Yann that may be OK. Restricted to admins and license reviewers. Or the talk pages are still existing visually but those who don't have user rights, even autopatrolled ones, will be barred from editing talk pages and be presented with a boilerplate notice that they don't have the right to edit talk pages and should instead comment on the main discussion page, with a link to the DR itself in the notice (do not expect several new users to comprehend what they are reading in the notices). JWilz12345(Talk|Contrib's.) 10:09, 26 November 2023 (UTC)Reply[reply]
Support --Krd 11:23, 26 November 2023 (UTC)Reply[reply]
Thank you for pointing out this Template:Editnotices/Group/Commons talk:Deletion requests location in Wikimedia. This was not ignored as you said in your comment, it simply was no where to be found at the time I commented. It's a shame it's too late to place a comment there as I would have done so. Even your notes to me are very confusing as the names of Comments pages do not match up so I can find them as are all the previous notes received by others. Being new to this platform, I have found it very confusing to find things that are suggested when seeing comments by others.
Hopefully I will have the hours to research and better understanding of the workings of Wikimedia Commons in the future. Thanks again! 54conphotos (talk) 13:32, 26 November 2023 (UTC)Reply[reply]
Support or, if it's easier, systematically turn them into redirects to the relevant project page. - Jmabel ! talk 21:56, 26 November 2023 (UTC)Reply[reply]
Support. Some good ideas above from Yann and Jmabel. We could also explore autotranscluding them to the bottoms of the DR subpages themselves. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:49, 27 November 2023 (UTC)Reply[reply]
Support. Yes, good idea, esp. with Jmabel’s and Yann’s additions. -- Tuválkin✉✇ 11:34, 27 November 2023 (UTC)Reply[reply]
Support I don't see any other way. Of course, the bot reverting the tags should leave a proper entry in the history. --Robert Flogaus-Faust (talk) 15:08, 23 September 2023 (UTC).svg/15px-Pictogram_voting_comment_(orange).svg.png)
Comment - It would be worth of save the added values to file or something before bulk reverting them so if somebody would like try to filter out useful ones (using machine vision for example) I think something like open_clip could work for finding useful tags and I could could do a practical test if the idea works at october. --Zache (talk) 18:28, 23 September 2023 (UTC)
Weak oppose I do not see the need for the change of this internal parameter. A change could break a lot of (unmaintained) tools. --GPSLeo (talk) 16:10, 6 November 2023 (UTC)
Oppose per GPSLeo. It's a purely cosmetic change that has the potential to break things. Commons is already struggling under backlogs basically everywhere; if we lose a tool or two it'll only get worse. The Squirrel Conspiracy (talk) 10:42, 7 November 2023 (UTC)![[2]](https://commons.wikimedia.org/wiki/File:Harpon_Unaaq_MHNT_ETH_AC_198.jpg){kind=link}
Strong support second in motion to @Yann, Abzeronow, and Glrx: et.al.. Examples of my autogenerated messages of WEBP copyvios: this, this, and this. And I can still remember the very first WEBP file I encountered here, which is a copyvio itself! Commons:Deletion requests/File:Beijing Skyline.webp. JWilz12345 (Talk|Contrib's.) 08:17, 26 November 2023 (UTC)
