Commons:Village pump/Proposals/Archive/2020/08

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

Only add Wikidata Infobox when it is not an instance of Wikimedia category

Proposal withdrawn. -- CptViraj (talk) 05:12, 21 August 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Compare two categories which have {{Wikidata Infobox}} on them: Category:Economy of Bryansk Oblast and Category:Mammals. The first is stated as an instance of "Wikimedia category", while the latter is a subclass of animals. I propose to either:

  • Only add the template to the categories when they are not instances of Wikimedia category, since it adds no exta information for the user. Every category on Commons is an instance of Wikimedia category. The water is wet. True statements are true. Blue objects are blue. It's a tautology, and only creates extra fud in recent changes.
  • Automatically add the template to all categories, since they all are Wikimedia categories, and thus apparently deserve an instance on Wikidata.

This proposal should not touch those categories, which are useful on Wikidata. For example if "Economy of Bryanskaya oblast" were a subclass of "Social interaction in Bryanskaya oblast", it would be a good and useful thing to place it here. ℺ Gone Postal ( ) 03:40, 20 July 2020 (UTC)

An enormous number of categories with infoboxes are linked to category items on Wikidata. E.g., Category:London is linked to d:Q7149656. The infobox can still follow links and find some information to display. --ghouston (talk) 04:02, 20 July 2020 (UTC)
@Ghouston: I think that you didn't read my proposal carefully, Category:London is a great example of a good Wikidata Infobox entry, it is about the subject of the category. On the other hand most of infoboxes that I see being added today are for the Wikidata entries not about the subject of the category, but about the category itself. Think about it, when somebody enters a category Economy of Bryanskaya oblast, are they interested in the economy of a specific oblast in Russia, or are they interested in how Commons manages the specific category page. I am proposing to stop adding (or alternatively add everywhere automatically) those "Instance of Wikimedia category" Wikidata blocks, which add nothing. ℺ Gone Postal ( ) 05:41, 20 July 2020 (UTC)
@Gone Postal: Your first proposal says Only add the template to the categories when they are not instances of Wikimedia category. Category:London is linked to Category:London (Q7149656), one of whose properties is instance of (P31) Wikimedia category (Q4167836), so Category:London would not qualify for a template under your first proposal. The significant difference is that Category:London (Q7149656) has a category's main topic (P301) property where Category:Economy of Bryansk Oblast (Q28026211) does not, and has category combines topics (P971) instead. You might want to rephrase your first proposal to take account of that.
Regarding your second proposal, that goes against the explicit statement in d:Wikidata:Notability that Category items with a sitelink only to Wikimedia Commons are not permitted (with some exceptions). --bjh21 (talk) 10:46, 20 July 2020 (UTC)
This is a complex issue (and maybe it would have been better to raise it at Template talk:Wikidata Infobox - or at least ping me about it). On the two options:
  1. I think the infoboxes on 'category' items are useful to have for several reasons. First, they are multilingual - they show translated category names and descriptions of the categories (and embed hidden information in the category that makes those categories show up in search for multilingual phrases). Second, they have (or should have) category combines topics (P971) values, which summarise what the category is about - again multilingually. Third, the infobox now tries to use those values to show more context about the category, which is hopefully useful.
  2. I would like to see the infobox used on all categories. We're about half way there (~6-7 million categories, ~3 million infoboxes), and there is still a lot of work to create new items and sync up existing articles/items with categories. There have been various discussions on Wikidata about notability and commons, see d:Wikidata talk:Notability and its archives, and discussions like d:Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion). They haven't (yet?) had consensus to do this, though. In particular there is opposition to the combination categories that are quite Commons-specific. However, there are still a *lot* of categories that are about specific notable things that should be on Wikidata - so there's still plenty of work to do before that becomes a limiting factor.
Note that Pi bot is mostly just adding the infoboxes to categories with new sitelinks now, BTW. I'd rather that we didn't start removing existing uses, and instead focus on building more content. Thanks. Mike Peel (talk) 17:51, 20 July 2020 (UTC)

---

  • Pictogram voting delete.svg I withdraw my nomination I think everything has been explained quite well, and since wikidata entries that are "instance of" only will be expanded eventually and are not stuck as such, they should remain and continue being added. ℺ Gone Postal ( ) 12:30, 10 August 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. 1989 (talk) 20:53, 25 August 2020 (UTC)

Notice

Please see Commons talk:Administrators/Requests#RfC: How to handle RfAs between 70 to 75 percent. 1989talk 17:39, 7 August 2020 (UTC)

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. 1989 (talk) 20:54, 25 August 2020 (UTC)

Accept files published by the copyright holder with a Public Domain Mark

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --ghouston (talk) 22:59, 26 August 2020 (UTC)

RfC: Deprecate XCF file format

Wikimedia Commons currently has 1,426 files in the XCF file format. XCF is the native image format for GIMP, and is designed to store images so that they can be edited. However, due to technical limitations summed up in T260286, the thumbnailing system only supports XCF files saved in GIMP version 2.8, while GIMP 2.10 is current. Even partial GIMP 2.10 support is a long way off, and full support for GIMP 2.10+ files looks unlikely.

XCF support on Wikimedia was introduced in 2006 to ease collaboration and to allow for translatable text. Because modern versions of GIMP produce XCF files that aren't visible on Commons, it is more difficult to edit and overwrite XCF files. Translatable text is now well handled by SVG files. Almost all XCF files on Wikimedia Commons would be better as JPG, PNG, or SVG files. XCF files typically do not compress the image data well, leading to larger file size even compared to PNG. XCF files do not have conditional sharpening applied when they are resized, which can make them look blurry. Finally, the metadata in XCF files is not especially stable (versions of GIMP other than the one used to write it can have difficulty reading it) and is not read at all by MediaWiki. --AntiCompositeNumber (talk) 00:52, 13 August 2020 (UTC)


Should Commons deprecate the XCF format, prevent new XCF files from being uploaded, and encourage XCF files to be converted to a more suitable format?

Votes (XCF)

  • Symbol oppose vote.svg Oppose We should find a solution for this problem. XCF could always be linked to an other file in PNG or JPG format. But maybe restrict the upload, like for MP3 files, to the autopatrolled rights. --GPSLeo (talk) 17:46, 16 August 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose In fact this is once again an attempt to move in the wrong direction. I feel that we should always encourage a person to upload XCF file rather than exporting into PNG or JPEG. ℺ Gone Postal ( ) 13:54, 17 August 2020 (UTC)

Comments (XCF)

  • i think we should just have both a rendered and non-rendered version of the file. The point of commons shouldn't just be to collect free educational media, but also to support remixing the media to make new media. Having source material in easily editable format supports that goal. Bawolff (talk) 19:42, 15 August 2020 (UTC)
    My point is basically that XCF rendering on Commons is poor currently, and is unlikely to improve significantly anytime soon. Until ImageMagick 7 is backported or becomes available in whatever Debian repo Thumbor is using, XCFs from the current version of GIMP won't be thumbnailed. I feel that continuing to thumbnail XCFs creates unrealistic expectations, and allowing uploads for a file format that isn't thumbnailed creates moderation problems. --AntiCompositeNumber (talk) 20:11, 15 August 2020 (UTC)
    Additionally, people aren't using the features of XCF that would make them easily editable in my experience. I've only seen one XCF that was more than a single layer raster file. --AntiCompositeNumber (talk) 21:15, 15 August 2020 (UTC)
    I did find a few more images that do make use of layers and text. My point still stands that they'd be better as translatable SVG files though. --AntiCompositeNumber (talk) 21:26, 15 August 2020 (UTC)
    The thing is that I see a lot of opposition to people including raster images inside SVG. If that were to change, then we can talk about using SVG for that. Also tools to edit SVG with raster images in them is not as simple as editing XCF file. ℺ Gone Postal ( ) 13:52, 17 August 2020 (UTC)

Rollback RFC

Hi, There's currently an RFC on the ROLLBACK wording at Commons_talk:Rollback#"When_to_use_Rollback"_RFC if anyone's interested,
Thanks, –Davey2010Talk 18:31, 22 August 2020 (UTC)

Proposal: Allow bureaucrats to remove administrator permission

Clear consensus in favor of allowing local bureaucrats to remove sysop permissions. King of ♥ 05:47, 28 August 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Currently Commons bureaucrats can grant but cannot remove sysop permission. I believe Commons community is large enough and we have enough active bureaucrats to handle desysops locally. This will make desysop log store locally instead on Meta. Stewards can still act in case of emergencies if no local crat is online. Note that this proposal does not support crats removing sysop in cases other than uncontroversial procedure (inactivity removals, RfDA, in case of emergency). -- CptViraj (talk) 06:02, 30 May 2020 (UTC) Fixed per Pandakekok9. CptViraj (talk) 06:24, 30 May 2020 (UTC)

Discussion

  • Symbol support vote.svg Support as the proposer. -- CptViraj (talk) 06:02, 30 May 2020 (UTC)
  • Symbol support vote.svg Support Long overdue! 4nn1l2 (talk) 06:11, 30 May 2020 (UTC)
  • Symbol support vote.svg Support About time. And just for clarity, can a local crat still emergency desysop a rogue admin even without the inactivity or RfDA procedures? pandakekok9 06:14, 30 May 2020 (UTC)
    Yep, fixed. Thanks :) -- CptViraj (talk) 06:24, 30 May 2020 (UTC)
  • Symbol strong support vote.svg Strong support Revoking sysop permissions by bureaucrat here and not by a steward is faster (and I'm Symbol keep vote.svg agreed about it), but how about with revoking bureaucrat permissions by bureaucrat? Nieuwsgierige Gebruiker OverlegCA 06:46, 30 May 2020 (UTC)
    "Allowing bureaucrats to remove bureaucrat right" is prohibited by system administrators, see m:Limits to configuration changes. -- CptViraj (talk) 07:05, 30 May 2020 (UTC)
  • Symbol support vote.svg Support - Bureaucrats close such requests, and the removal of administrative rights by stewards usually needs a successful de-RfA closure by a bureaucrat. So, if they should first close the request (their closure is somehow "official"), why shouldn't they remove the right as well? Ahmadtalk 07:34, 30 May 2020 (UTC)
  • Symbol support vote.svg Support for 'procedural' rights removals. Emergency actions would need a more detailed proposal and agreed policy, especially if the removal decision is based on any non-public data of any kind. As a procedural corollary, though removing the 'crat group has a systems issue, by default if a 'crat removes another 'crats sysop rights, the desysoped 'crat is by existing policy automatically no longer a functioning 'crat, even if technically the flag is still there. -- (talk) 12:32, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose If bureaucrats can't be trusted to return sysop rights after 24 hours, they shouldn't be able to do this. Also, the bureaucrat team has 7 members, but one or two are active in that role. So no, you won't get a "faster" response. 1989 (talk) 14:35, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose With the level of infighting that Commons has had lately - this is a very bad idea to remove stewards from the picture. --Rschen7754 15:53, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. Lymantria (talk) 16:00, 30 May 2020 (UTC)
  • BA candidate.svg Weak oppose, per Limits to configuration changes, this will only be done if there is both multiple active bureaucrats, and a demonstrated need. Given the only real reason for bureaucrats being able to remove the bit is speed, and we only have 7 bureaucrats, I'm not sure we meet these criteria. ~~ Alex Noble/1-2/TRB 16:39, 30 May 2020 (UTC)
  • Symbol support vote.svg Support - Seems natural. I have high trust in our local bureaucrats and it strengthens the local community. --Schlurcher (talk) 07:54, 31 May 2020 (UTC)
Thanks. Please elaborate how this is relevant here? --Schlurcher (talk) 08:32, 31 May 2020 (UTC)
Though I wasn't here when Russavia was WMF banned in 2015, as far as I read the archives, he seem to had been a good bureaucrat. The only reason he resigned was because of the controversy of hiring Picasso to make a painting of Jimbo. He didn't abuse his tools nor made a bad judgement on a significant issue on Commons AFAIK. He did committed sockpuppetry though, but that's because he suddenly got banned by the WMF without warning. We still don't know what got him banned. I only had a few interactions with him via IRC, and that was only about helping with translating stuff to Tagalog. He seemed like a nice guy, too bad I wasn't able to know him much before he got banned.
But as Schlurcher said above, I don't see how Russavia is relevant in a proposal about granting crats the ability to remove admins. That was a 3 years or 2 years ago problem (the last I saw him sock was in 2017 or 2018 I think). If you think we shouldn't trust the bureaucrats just because of one former member who long resigned like 6 years ago, that ain't fair to other bureaucrats who had done their community role well for years. Russavia only served for like 2 years as a crat. The rest of the crat team served and still serves longer than that. pandakekok9 09:44, 31 May 2020 (UTC)
Bad cases make bad law. If any oppose votes here are because of what happened with one rogue account many years ago, where there never was any misuse of bureaucrat status or sysop tools, then that's very bizarre.
All current 'crats are demonstrably trustworthy, the only criticism is that there aren't many active 'crats. Hardly a reason to reject this proposal. -- (talk) 10:17, 31 May 2020 (UTC)
the only criticism is that there aren't many active 'crats. Hardly a reason to reject this proposal. Er, that's actually a reason why such change won't be implemented by the sysadmins, see m:Limits to configuration changes#Changes that are likely to be declined. We do want some more active crats, but I think we have enough to prevent any crat abuse. pandakekok9 10:23, 31 May 2020 (UTC)
  • Pictogram voting comment.svg Comment You'll sometimes say stewards are allowed to remove bureaucrat permission or maybe kick someone out... --Red-back spider (talk) 10:00, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Granting and removing rights should ever be possible by the same users. If there are doubts that this could take to long we should look for some of the very active admins becoming promoted. --GPSLeo (talk) 10:01, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Anyone who has the technical right to grant a sysop should have the same right to remove it following a clear consensus. Regards. T CellsTalk 19:02, 31 May 2020 (UTC)
  • Symbol support vote.svg Support, Wikimedia Commons is large enough to stand on its own feet. Bureaucrats are highly trusted users and while I don't always agree with some individual decisions of some permission holders, the removal of the sysop flag can only be done with the support of a sizable number of community members, so there is not much of a chance that this will be abused. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:59, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Bureaucrats on Commons are trustworthy and they have adequate knowledge on doing this. --A1Cafel (talk) 09:13, 3 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. Trijnsteltalk 20:15, 4 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. -- Geagea (talk) 05:47, 10 June 2020 (UTC)
  • Symbol support vote.svg Support Of course. Regards, ZI Jony (Talk) 08:24, 14 June 2020 (UTC)
  • Symbol support vote.svg Support This is a common feature of what it means to be a bureaucrat and it also means that this project can be self-policing. —Justin (koavf)TCM 01:43, 21 June 2020 (UTC)
  • Symbol support vote.svg Support "The man who passes the sentence should swing the sword"-(Ned Stark) Seriously, since the buraucrats have the community right to close the procedure they should also have the technical right to finalize it. -Geraki TLG 16:53, 16 July 2020 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. please ping or talk to me 21:04, 18 July 2020 (UTC)
  • Symbol support vote.svg Support I understand the words of opposers, but I feel Stewards have way too much responsibilities, just easing them from this particular task wouldn't hurt. Bureaucrats on Commons are highly trusted, they should not be assumed to abuse this right. Ainz Ooal Gown (talk) 16:50, 19 July 2020 (UTC)
    • 20 desysops a year really doesn't make a difference in their workload. --Rschen7754 18:05, 7 August 2020 (UTC)
  • Symbol support vote.svg Support. Commons 'crats (should) have more knowledge of Commons policies than Stewards. Having this handled locally could prevent unnecessary drama. —Mdaniels5757 (talk) 18:40, 15 August 2020 (UTC)
  • Symbol strong support vote.svg Strong support - We are a large project and can deal with our own dirty laundry. Regardless of whatever minor burden it may place on stewards, it is an unnecessary burden. There is no argument I can support for the perpetuation of an unnecessary burden merely because it is minor. If we find we have too few crats to handle the job, then we should elect more. In a perfect world, we would have little need for stewards at all, as every project would be capable of being, and become self-sustaining. There is no need for us to keep the umbilical cord attached when we've long ago been weened off the bottle. GMGtalk 13:06, 16 August 2020 (UTC)
  • Symbol support vote.svg Support.--Vulphere 07:59, 21 August 2020 (UTC)
  • Symbol support vote.svg Support. I think Commons is a big project enough to not require stewards do this always. – Ammarpad (talk) 06:26, 23 August 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
  • I think the consensus in this section was not strong enough for such a radical change, which dramatically alters the power structure of the wiki. Nemo 14:37, 30 August 2020 (UTC)
    • From the phab ticket, it seems the stewards agree with you. 1989 (talk) 00:56, 31 August 2020 (UTC)
      So let's reopen it, and advertise it on COM:BN, COM:AN, COM:VP, and perhaps a sitenotice.   — Jeff G. please ping or talk to me 01:29, 31 August 2020 (UTC)

Disallow copyvio speedy tagging for old images

Recently, I came across File:M Yacoub.JPG, which was tagged for speedy deletion because the image can also be found at [2]. However, the image was taken in 2008 and uploaded in 2012, and the uploader's other uploads (e.g. File:Magdi Yacoub.JPG, File:Khalid Abdalla.JPG) are consistent with the story that they went to a gala(?) in 2008 and brought along their Canon 400D, so I have removed the tag. More generally, the longer an image sits on Wikimedia Commons, the less likely it is to be a copyvio (since people would have noticed and gotten it deleted already), and the more likely it is for another website to copy it (legally or illegally). I propose that we disallow {{Copyvio}} tagging of images first uploaded to a Wikimedia project more than X years ago (X TBD), and require a COM:DR to give users time to evaluate whether the external website is indeed older and whether the uploader's claims of own work make sense. -- King of ♥ 04:15, 18 August 2020 (UTC)

  • Symbol support vote.svg Support I generally support that we do not mark older images with speedy deletions. Not just copyvio. But also "no source" and "no permission". Sometimes information is removed pr broken and can be found in file history. Sometimes archive.org can help. --MGA73 (talk) 05:21, 18 August 2020 (UTC)
  • Symbol support vote.svg Support in theory, Symbol oppose vote.svg Oppose making it an official policy or guideline. I'll generally DR things that fall into the "ye olde images" category over {{Copyvio}}, mostly for the paper trail. However, I've come across a few images that, for whatever reason, are old but blatant copyvios that have flown under the radar. If I can confirm them using archive.org, metadata is suspicious, uploader has no real history, etc. I'll generally still tag {{Copyvio}}. I don't see the point of adding yet another file to the weeks-to-months-long DR backlog in that case. --AntiCompositeNumber (talk) 16:04, 18 August 2020 (UTC)
    Maybe we can add a warning to the {{Copyvio}} template that automatically detects the upload date, and if it's old, reminds the patrolling admin to double-check before deleting. I've seen too many good images get deleted because the patrolling admin was careless. -- King of ♥ 16:14, 18 August 2020 (UTC)
    That's not currently possible just inside a template without changes to MediaWiki as far as I'm aware. --AntiCompositeNumber (talk) 16:55, 18 August 2020 (UTC)
  • Symbol support vote.svg Support We already grandfather files where the permission is sent to the uploader and not to OTRS for files uploaded before OTRS system was in place. And this did not break everything. DR system has its problems, but it is significantly better than the alternative (delete and then expect somebody to find that the deletion was in error). ℺ Gone Postal ( ) 16:21, 18 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose - A copyvio is a copyvio and does not become other by virtue of age. Speedy tagging is merely the expression of a concern; it is not an automatic deletion, and it is indeed the duty of the processing admin to evaluate the claim. If admins are speedy deleting images on bad evidence or otherwise for poor reason, the problem is with those admins, not the tagging. Prohibiting a reasonable practice because some admins are doing a poor job is absurd, and a failure to remedy the genuine underlying issue. Эlcobbola talk 16:36, 18 August 2020 (UTC)
    Speedy deletion is meant to: 1) reduce the amount of time an unacceptable file remains on Commons; and 2) reduce the burden of DR. For a file that's remained on Commons for several years, a few more weeks isn't the end of the world. And there are relatively few genuine copyvios from many years ago, so it won't cause a strain on DR either. The problem is not with individual admins, but with the system, as I see mistakes being made by many different admins. I like to think that I am more diligent than the average admin, but it comes at a cost of efficiency: I cannot hope to rival the Jcbs of this world in sheer volume. Someone has to do the dirty work of deleting hundreds of files a day, and anyone given that task will not be able to give each image their full attention; our procedures need to be tightened up at the tagging phase. So I'm suggesting that we carve out cases that are statistically likely to be incorrect taggings and require them to use a process where more people have a chance to examine the situation. -- King of ♥ 16:55, 18 August 2020 (UTC)
    No, speedy deletion is meant to "bypass deletion discussions and immediately delete files or pages" (COM:CSD) The purport of efficiency is nonsense. This merely shifts administrative burden from processing the speedy tag to processing a DR, the latter being more labor and resource intensive. Not only that, it adds an additional decision layer to the speedy tagger, who may be new or otherwise unexpecting of a rule as absurd as this (before x date doesn't quality?), thus adding an additional burden to the admin finding the speedy to judge the date, convert the speedy, and notify of tagger of the required. This is a nonsense proposal based on, apparently, a single example of a poor speedy nomination (which wasn't even deleted, proving, if anything, the current system works (!!!)). You've not bothered to offer even a second, let alone numerous sustained examples (or even examples of actual deletions due to this issue) to evidence an on-going issue. Эlcobbola talk 17:31, 18 August 2020 (UTC)
    We want it to be hard to speedy delete old files, because they are unusually likely to be incorrectly tagged. I would not have noticed it if the creator had made an appeal to COM:UNDEL. Generally, the only people who look at the speedy deletion categories are the admins who are overworked and likely to make mistakes. Meanwhile, DR daily logs are visited regularly by many people, giving them an opportunity to opine. Can you give examples of files which were correctly speedy-deleted more than five years after upload? -- King of ♥ 17:45, 18 August 2020 (UTC)
    Yes. And it is, of course, not my burden to disprove your theory, but rather it is for you to support. I notice you've, again, not bothered to provide any evidence of a problem. Эlcobbola talk 17:51, 18 August 2020 (UTC)
    Then, perhaps instead of completely disallowing copyvio tagging, we require the copyvio tag to be evidenced by an archive.org link or a credibly dated external page. As an additional example, see File:WM2006happybirthdayangela.jpg, which was deleted even after the uploader added source information. (This was a {{No source since}} tag, but it's a similar case and I agree with MGA73's comment.) A key question is where the burden of proof lies for a small image with no EXIF metadata. I would say that for a recent upload, the burden lies with the uploader to prove that it is own work, but for an old upload the burden lies with the tagger to prove that it is a copyvio (i.e. they must find the image being used at an external site which is older than the Commons upload). -- King of ♥ 18:03, 18 August 2020 (UTC)
    Yes, I would be supportive of that (dated link), especially as I don't consider that a change but rather an articulation of what we've been expecting all along. Эlcobbola talk 18:10, 18 August 2020 (UTC)
I agree that a copyvio is a copyvio. But most times when a file is marked as a copyvio there is not 100% proof that it is a copyvio. It is a tag saying that someone suspect that it is a copyvio. For example if I'm a photographer and take a photo that is used for the front page of a magazine and I upload the front page of the magazine then it is not a copyvio even if it looks like it is. If someone tag it with a "npd" I will have 7 days to send the permission but if someone tag it with a copyvio an admin can delete it 4 seconds later. If I send a permission and it is undeleted what are the chances that the admin that deleted the file will check the log of commonsdelinker and add the file to all the articles again? I bet that the chances are 0. It will never happen. If I uploaded the file a few days ago I can probably remember where I added the file. But if it was uploaded 8 years ago it can be used in many projects because other users added the file to articles. And they can have used the file to create other files. On Japanese Wikipedia they have a master map that is used to make hundreds or thousands of other files. If I think the original is a copyvio and I delete the original and hundreds or thousands of derivated files it will be very hard to clean up. If I start a DR instead then other users have a chance to say "NO WAIT!". --MGA73 (talk) 16:35, 19 August 2020 (UTC)
  • Symbol support vote.svg Support prohibiting copyvio speedy tagging for images older than 10 years. While I agree that admins should be more conscientious about acting on speedy tags, I don't expect that to significantly change in the near future. If an image has been hosted on Commons for more than 10 years, I think it deserves the benefit of the doubt and should get a full deletion discussion. Kaldari (talk) 17:41, 18 August 2020 (UTC)
  • Symbol strong support vote.svg Strong support. The mistake ratio concerning old files is relatively high. If a file was hare as a copyvio for years it could not hurt much it it is left here for few extra days. Especially as it would be marked as a suspected copyvio. Incorrect deletion, then undeletion and usage restoration is quite complex process and it requires much more effort than a DR vs. speedy. Ankry (talk) 18:11, 18 August 2020 (UTC)
    "The mistake ratio concerning old files is relatively high." Can you provide data to substantiate this? Or to substantiate the implication that DRs and speedies have different error ratios? Would you agree the majority of DRs are closed without having received comment beyond the nomination? If so, how, precisely would a DR be better vetted than the speedy, or more compelling in a UDR? Эlcobbola talk 18:19, 18 August 2020 (UTC)
    True, but at a minimum a DR must remain open for at least 7 days (unless it is speedy deleted). A {{Copyvio}} tag often gives the uploader little time to address the allegations, and the file might already be deleted by the time they see it. Finally, the fact that no one commented is not an indication that no one reviewed the situation; someone might have reviewed it and concluded that the conclusion was so obvious they don't need to waste time !voting to get the closing admin to make the right decision. -- King of ♥ 18:38, 18 August 2020 (UTC)
    I'm neutral on the whole discussion but about "Can you provide data to substantiate this?": note that Ankry is quite active in UDR and their opinion even without advanced proof is probably based on their experience and is surely quite relevant therefore. Christian Ferrer (talk) 18:46, 18 August 2020 (UTC)
  • I think a guideline for admins that older images should be checked much better, then recent uploaded images, before deletion would be enough. If it is not clear on the first view it is always possible to change it to a regular DR. --GPSLeo (talk) 20:52, 18 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per Эlcobbola, a copyvio is a copyvio. If anything should be changed, then the awareness of the deleting admin that it may be a case that required extra attention. Maybe a warning can be shown if the upload is longer than a few weeks ago? --Krd 06:31, 19 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per Эlcobbola and Krd, furthermore administrators are elected, and it is a fact that the elections are not so easy, they are supposed to be trusted for the decisions to delete or not. Maybe a note can be written in our policy Commons:Criteria for speedy deletion in order to encourage administrators to pay close attention to the files thus tagged which have been here for several years. Christian Ferrer (talk) 10:58, 19 August 2020 (UTC)
  • Symbol neutral vote.svg Neutral I might change the text of CSD to emphasize that finding other images on the net are likely only meaningful if they predate the Commons upload (or Wikipedia upload, if uploaded there first). I'm not sure we have guidance like that on the criteria page. The copyvio tag is only for obvious copyvios, which finding other image on the net after upload does not demonstrate. Proving that does get increasingly harder for older images, for sure. On the other hand, there are blatant copyvios that have simply escaped attention for years -- not sure we want to absolutely bar those from being quickly deleted. And yet back to the first hand, older images are far more likely to be in use (either on wiki, or external) and it is nicer to have an explanation for the deletion if someone comes looking to see why an image disappeared, and regular DRs leave a record while speedy deletion does not other than the deletion comment, which is often pretty terse. I do tend to prefer DRs for older images. I'm just not sure a blanket ban is a good idea, but maybe adding some guidance that discourages use of speedy deletion for older images unless it's quite obvious. I've always had a problem with the wording "apparent copyright violation", since that seems to say that speedy deletion is appropriate when there is a possible copyvio but the nominator is unsure. Those seem more like DR situations to me. Carl Lindberg (talk) 03:02, 20 August 2020 (UTC)
    "Apparent" is horrible wording, because it is a contranym: it can mean either "blatant" (e.g. "the problems are apparent") or "probable" (e.g. "the apparent winner of the election"). -- King of ♥ 04:06, 20 August 2020 (UTC)
    +1 to that! This should be clarified before anything else: does "apparent" in COM:CSD#F1 mean "obvious" or "suspected"? I always assumed it was the former, but apparently the answer is not as obvious as I thought (scnr). --El Grafo (talk) 13:37, 20 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per above. 1989 (talk) 20:39, 25 August 2020 (UTC)
  • Symbol support vote.svg Support. I work regularly in speedy deletion requests and I find mistake ratio among old files relatively high. And on the contrary, among old files are relatively few copyvios. So I generally do not delete old files speedily, but change speedy DR-s into regular DR-s simply with reason "The file has been years in Commons and deserves a regular DR." For me X=5 years. Taivo (talk) 07:46, 28 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per above. If an admin is speedy deleting without checking dates, the admins rights need to be reviewed, not policies.--BevinKacon (talk) 15:09, 28 August 2020 (UTC)
  • Symbol support vote.svg Support -- Tuválkin 11:52, 30 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose Copyvio is copyvio. The issue won't be resolved as it stays longer on Commons. We can still see some old files on Commons being deleted as copyvio. Moreover, {{Copyvio}} or COM:CSD#F1 only applies to files that are apparent copyright violation. I believe that the admin will do a double check before deleting a file. If the file is not an obviously copyvio, they can convert them to DR. There is no need to establish a policy or guideline. --A1Cafel (talk) 04:21, 4 September 2020 (UTC)
  • Symbol support vote.svg Support --Tibet Nation (talk) 01:57, 26 September 2020 (UTC)
  • Symbol support vote.svg Support -- Infrogmation of New Orleans (talk) 04:07, 26 September 2020 (UTC)
  • Symbol oppose vote.svg Oppose current proposal, while I do agree that a copyvio tag on some files that are 1+ year old are incorrectly tagged as such, while some have been unspotted until someone comes along to categories, make it more descriptive or add some structured data, why should we turn a blind eye and clog the DR process. Copyvio should only be used when there is no doubt and DR when there maybe some doubt. Bidgee (talk) 04:58, 28 September 2020 (UTC)
    • But that is the thing, the fact that the file has been present on the project for a long time already creates doubt. If people have looked at the file and did not even nominate it for deletion means that they at least had doubt that it was a violation. ℺ Gone Postal ( ) 07:20, 28 September 2020 (UTC)
      • It depends on the situation and commonsense should apply. If you find a site that has the very same image (including file size, resolution) that has the same date or even a date prior to it being uploaded on Commons is enough doubt (checking Archive.org would help to re enforce it) or other cases are clear cut no FoP. Sadly files do get missed until someone is cleaning up categories (or the lack of them) for example. I have come across them in the past, researched and used the appropriate tag. Bidgee (talk) 23:43, 28 September 2020 (UTC)
        • I, too, have come across such files. Most of the time they were hiding in some categories that were from countries that we have very few users in, perhaps people are much more interested in their own culture than others and spend more time categorising their "home" files. And when I found such files I have filed a DR explaining the situation, and in most cases the file was deleted, and in some I was explained that I was in error. Perhaps I just do not see the point or maybe I am just pedantic, if we delete the file after 5 years and 12 days it is not a "speedy" deletion, and there is very little difference if that deletion took place in 5 years and 19 days. Both of those durations would be perceived as "5 years" by any rational individual anyhow. ℺ Gone Postal ( ) 01:24, 29 September 2020 (UTC)
  • Symbol oppose vote.svg Oppose as stated. There is merit in refining the guidelines as to different circumstances, but a blanket change may introduce harm as well as eliminating some. -- (talk) 09:41, 28 September 2020 (UTC)
    • Is it a matter of time or are you opposed to the change at all? If the file as been around for 10 years, I would assume that it has been viewed by many sets of eyes. Are you concerned about files that are in a rare language that are not well categorised that are hard to find, and thus the number of people that view those is smaller? Or is the concern that the law drastically changes, making previous analysis invalid? ℺ Gone Postal ( ) 12:22, 28 September 2020 (UTC)
      • No, no, not really and no. The harm referenced was the long term effect of decreasing the likelihood that anyone will even try to assess copyright issues with older files. Right now, if I tag an older file as having a copyright issue I get bad faith presumptions, literally that I "have a stick up my arse", and if I raise a DR I get even more intense personal abuse. That's before a systemic bias against trying properly to ask questions about older files gets enshrined in policy. -- (talk) 17:05, 28 September 2020 (UTC)
        • Interesting, I would say that our experiences are very different on that one. When I have found an old file that is a likely copyvio I have always started a DR and saw no abuse. The funny part is that the "roughest" experiences in the sense of emotions was when you have very correctly put me in my place by bringing up an archive that I have missed that showed a free licence. But even though I felt uneasy, it was the example of the way it should work. If I would mark the file as a speedy deletion, claiming that I cannot determine the correct licence, then there would be a large chance that an admin would be unable to find that archive, just as I did not, and there would be one less file on Commons. How would that be a good thing? ℺ Gone Postal ( ) 19:00, 28 September 2020 (UTC)