Commons talk:Criteria for speedy deletion

From Wikimedia Commons, the free media repository
Jump to: navigation, search
This talk page is automatically archived by ArchiveBot. Any sections older than 60 days are automatically archived. Sections without timestamps are not archived.


The current GA1 wording is "Mainspace pages (galleries) that are empty or contain no useful content, such as pages that contain text but no images or other media." A discussion at the Village Pump led me to Military units of Warsaw Uprising, which is a page that contains text but no images or other media. However, it's quite useful: it's basically a directory of relevant Commons categories with additional links to Polish and English articles on Wikipedia. What if we made an exception to this criterion, something such as "This excludes gallery pages created to help navigation"? Nyttend (talk) 13:23, 5 October 2015 (UTC)

I would hope that the 'or contain no useful content' would cover this (since the 'no media' is stated as an example), but I don't see any harm in giving a counter-example of a type of no-images page that should not be deleted. I don't think it would really be an 'exception' (the content is obviously useful) but making it more explicit won't hurt anything. Revent (talk) 02:33, 6 October 2015 (UTC)

Criteria codes instead of criteria numbers[edit]

I suggest we change the criterion numbers listed in this article to the criterion codes used by the {{SD}} template. E.g. Instead of listing them as 1., 2., 3. we should use G1, G2, G3. That way users don't even need to click on the link to the list of criteria codes to see them; they can just scroll down. I don't see any significant downside.

Note that I already made a presumably non-controversial change to the mention of this template to say {{SD|<criterion code>}} with an example, since I was confused by the previous text {{SD|<criterion number>}} which I presumed meant I could just use something like {{SD|7}} (which won't work).WinTakeAll (talk) 03:11, 24 March 2016 (UTC)

No opinions against it, so I went ahead and made this small change.WinTakeAll (talk) 19:42, 3 April 2016 (UTC)
Symbol oppose vote oversat.svg Strong oppose This page is already complicated enough. Also, the codes are not good for anything. If you want to nominate a page (or file, ...) for speedy deletion, you should use a text reason and not one of these more or less meaningless codes. --Didym (talk) 20:13, 3 April 2016 (UTC)
Symbol strong support vote.svg Strong support. It clearly makes things simpler, and not the contrary. Saves the editor from typing sentences. Rehman 13:22, 4 April 2016 (UTC)
  • Symbol oppose vote.svg Oppose Deletion templates should have readable names, not gibberish codes. --Stefan2 (talk) 19:52, 4 April 2016 (UTC)
  • Symbol support vote.svg Support, some folks not including me use the criterion codes, and changing n to Gn in the "general" section as used in {{SD|Gn}} is harmless for others + useful for these users. Ditto Fn, Tn, Un. And whatever these users like for gallery != general (maybe A?), category != commons (maybe P as in project?). Be..anyone (talk) 17:10, 6 April 2016 (UTC)
  • Support Standardized text is useful. Anyone who wants to write their own prose should be able to do so, but since so often deletion rationales for many files are the same, it is useful to have a shorthand. In English Wikipedia this system worked well, and that is supporting evidence that a similar notation might be similarly effective here. Blue Rasberry (talk) 20:52, 19 July 2016 (UTC)
  • Symbol oppose vote.svg Oppose i see no need. --Steinsplitter (talk) 16:42, 2 December 2016 (UTC)

F9 criteria update[edit]

Current Updated
9. Embedded data
The file contains additional embedded data in the form of a password protected archive.
9. Embedded data
The file contains additional embedded data in the form of a password protected archive. If the information can be lossless removed without impacting the rendered image in any way, preserve the new version while deleting the earlier version.

Proposed update intends to address files that are unusually large. This isn't intended to remove metadata and other important features of files and instead focuses on removing the junk data. -- とある白い猫 ちぃ? 16:28, 2 December 2016 (UTC)

I would generally agree with this, with a big caveat. I understand that sometimes software might add some data to a file, however this would be expected to be in the form of identifiable (if not readily parseable) tags (exif, icc profiles, or whatever). That stuff, while it might easily be malicious if we cannot parse it, could conceivably be explained and thus would merit simple removal. I have not seen a believable explanation for data appended to the end of a JPEG, and as such that greatly reduces the amount of good faith I feel able to assume. I doubt such files in general can be assumed to be created by the uploader. Storkk (talk) 20:51, 2 December 2016 (UTC)
@Storkk: While I have revdel a few of the 'egregiously' large cases after losslessly removing the excess data without trying to id it (like, where it was over 50MB), I think we should word this in such a way that we apply it (revdel) only to when we actually 'know' there is an embedded archive. See File:Briefmarke LindauerHuette 6S.jpg... this is a useful file, but the original version contained a 7z archive (which contained a PDF brochure for the ski resort, for some very strange reason). If we know there is an embedded file we need to delete it, one way or the other, to discourage people from abusing Commons to distribute illicit material this way. Reventtalk 01:29, 4 December 2016 (UTC)
However (as was pointed out by Dispenser Adobe Fireworks uses PNG as a 'native' file format, and includes non-image data about layers, paths, history, etc in private EXIF fields, so they are 'absurdly large overhead' legitimately. Reventtalk 01:31, 4 December 2016 (UTC)

@Revent: perhaps we are talking slightly at cross-purposes, but I think it would be prudent to be quite wary of large data inside of undocumented tags until they have been explained. So Fireworks PNG are probably OK, but incredibly large ICC profiles, unexplained binary metadata tags, etc. we should probably strongly consider stripping/re-compressing and revdel'ing. And I've seen no plausible innocent explanation at all for binary data that's simply appended to the end of the file. That should raise extreme suspicion, IMO. Storkk (talk) 17:40, 4 December 2016 (UTC)

@Storkk: I think we've just saying it differently.... if there actually 'is' such suspicious data, yes, we should make it go away, my point is more that sometimes simple 'large overhead' is just due to something like not checking the 'optimize' button when saving a jpeg, and we should probably avoid being accusatory toward people unless we actually 'know' it's something suspicious, and not just inefficient or broken. Reventtalk 03:49, 5 December 2016 (UTC)
@Revent: Sorry, I'm not sure how to answer that except to re-iterate my first reply to the proposal above. Weird tags embedded: OK, just remove them, not of-themselves damning, and not of-themselves a reason to speedily delete the whole file. Unparseable binary data appended to the end of the file I think is by itself extremely suspicious (is this where we disagree?). I still have yet to see an innocent explanation for that, and someone has to deliberately put it there. The JPEG's compression level is tangential, I guess that's why your reply has puzzled me. Storkk (talk) 14:55, 7 December 2016 (UTC) edited to add "Unparseable"... 7z files with clearly non-copyvio inclusions I agree are recompress, revdel candidates Storkk (talk) 14:58, 7 December 2016 (UTC)
@Storkk: Optimization of a jpeg has nothing to do with it's compression level... it's just how efficiently the compressed data is stored. The point I am making is that we need to word this in such a way that we don't end up with people deleting, or rev-del, images and accusing people, explicitly or not, of being 'bad actors' merely because optimizing the image made it a lot smaller, without knowing that it specifically 'was' excessively large because of the various suspicious factors you named. As a test of this point, I just took an 15MP image of, literally, a blank neutral white painted wall with my cellphone camera. 'jpegtran -copy all -optimize' then reduced the file size by about 15%.. and this was not a specifically formulated test case, just me taking a photo of the wall by my front door. I'm just saying we should try our best to make sure that people aren't considering such images as 'suspicious' just because they are easily shrunk by significant amounts, especially since the first 5-10% of compression of a jpeg makes a huge difference. Just resaving the image in Gimp as 100% (it was at 93%) without optimization made the 'overhead' well over a megabyte. Reventtalk 21:49, 7 December 2016 (UTC)
@Revent: Can we agree for the purposes of this conversation to disregard entirely the actual JPEG image data (and also any parseable Exif/IPTC/other metadata tags)? We are still, I think, getting hung up on that. Storkk (talk) 22:32, 7 December 2016 (UTC)
@Storkk: I think you are misunderstanding me. I quite agree with deletion of files with large amounts of unexplained data outside of the image itself. I'm merely concerned that we word this in such a way that people who do not know how to specifically identify the existence of such data are not using this to speedily delete files like the image I discussed above and then accusing the uploaders of acting in bad faith. Reventtalk 22:59, 7 December 2016 (UTC)
@Revent: I agree that we should not allow or encourage that. Sorry if I misunderstood you. I don't think I have advocated the use of jpegtran (or pngcrush or whatever) as a basis for discriminating good from bad, and I would strongly agree that it should not be. Storkk (talk) 23:28, 7 December 2016 (UTC)

Speedy deletion of **empty** categories[edit]

Categories may become empty by accident, or because files or subcategories that should be there are not present in it.

I'm totally opposed to any form of "speedy deletion" (without even leacing any redirect, really a deletion creating red links!) for these categories that were really meant to have content.

I've seen people recategorizing contents agressively, deleting significant differences (e.g. redirecting contents related to former countries or regions, or their historic documents, to a new different region: this is NOT the same topic at all), and then leaving empty categories which were abusively deleted with speedy deletion.

Empty categories are NOT in scope of Speedy deletion per the rules. Stop this ! This is clearly an abuse by some users using their privilege to delete content that has to be recreated from scratch (the deletion even hides the history completely, it's not simple to recreate them).

Speedy deletion is meant for abusive contents breaking strong policies (e.g. copyright issues) or for files/galleries/categories created by error with a bad name. This is not the case of most empty categories.

Instead of deleting them, please use redirects (or category redirects), keeping the history, so that these can be reverted easily. Stop deleting the page history abusively when there was absolutely no breach of policies. Or at least use the more formal proposals for deletion, so that users can discuss this.

Most of pages/categories that were "speedy deleted" were poorly checked: those doing that have left many red links everywhere, and broken the navigation in many pages. They cause difficulties for the maintenance and will finally fill up many other maintenance categories where these broken links are listed.

Admins that abuse their deletion privilege for bad reasons (notably empty categories) without discussing it (and not even reading this criterai page) or checking what they are breaking, should have their admin privilege revoked. They don't help this wiki, they just break it !! verdy_p (talk) 17:33, 2 May 2017 (UTC)

We can have a discussion about changing the current policy or about how it's applied, but I think you need to calm down a bit first. Shouting and calling other users aggressive or abusive is not helpful. I have a really hard time picturing admins spitefully deleting categories while laughing maniacally like Dr. Evil at their own power. The statement that empty categories are not candidates for speedy deletion according to the current rules is factually incorrect. COM:CSD#G1, COM:CSD#C1 and COM:CSD#C2 all contain provisions for this. LX (talk, contribs) 17:48, 2 May 2017 (UTC)
@Verdy p: Can you give us an example of a category that shouldn't have been deleted so we can better understand what you mean? --99of9 (talk) 00:06, 3 May 2017 (UTC)
Almost all categories for former French regions before 2015: they have been deleted and their content incorrectly merged to the new region, mixing their distintive history.
There are countless examples on Commons were this occurs: people are moving categories in hurry as soon as there's an adminsitrative change, and frequently this is controversial.
Note that former French regions in 2015 are likely to be restored soon as they were before their merge (the two presidential candidates have shown that this merge has failed and want to cancel this law and restore the independance of regions, or allow diufferent groupings: this was discarded under Valls ministry, but the national and regional parliaments have highly criticized this decision), and they have not disappeared completely in many other domains (even if their regional councils have merged, there are other topics not r,elated to these councils), and we have tons on documents on Commons that clearly make the distinctions between former regions (photos, buildings, statistics, maps, elected people, culture...) but still very few related to the new regions as a whole. This means that both kinds of regions have to coexist (even if we can subcategorize old regions into the new ones, we MUST NOT empty them). verdy_p (talk) 13:44, 3 May 2017 (UTC)
  • Comment I think there is an issue here, as admins tend to shoot-on-sight with empty categories if they get tagged with {{speedy}}. One persistent problem is deletion of moved categories, which have the {{category redirect}} removed and tagged for deletion - think of the situation with OSX.
Another example would be Category:Grave of Yulian Markowski, which was moved to Category:Grave of Julian Markowski at Lychakiv Cemetery. If Yulian is an acceptable variant on his name, then that category should have been retained as a redirect. This indicates to me we need a way of getting admins to look for a target and create redirects instead of deleting.
This would also address Verdy p's concerns - if a merge happens it should leave behind redirects (and page histories). If they are unmerged in the future, all that needs doing is reverting to the last edit prior to the redirect.--Nilfanion (talk) 01:47, 4 May 2017 (UTC)
I've taken a snapshot from the deletion log (User:Nilfanion/Category deletions) and will analyse it, that will take some time. My gut feeling is being being empty should not be a deletion reason by itself, and if it is empty we should look to see if a redirect is sensible. If now, for instance its got a spelling error, then delete away.
Verdy p's complaint is about ones like Category:Gates in Midi-Pyrénées.--Nilfanion (talk) 11:34, 4 May 2017 (UTC)
Not just this category, I saw people moving ENTIRELY the contents for the former French regions themselves and then speedy deleting the categories themselves, without informing anyone); but there are plenty of examples with countries/regions that have more or less recently have administrative changes: these speedy deletion cancels their past history, as if the topics had never existed, and merging cannot be redirected category content is not easy to revert when the category has been speedy-deleted by admins that hurry on speedy deletion requests (and just leave a comment "as per COM:SP" which is absiltuely not giving this reason as valid). Speedy deletion of empty categories is clearly invalid, unless there's an obviuous typographic error and the initial name was very incorrectly chosen (this often comes from the first author that made an error), or the content or title was offensive/abusive, in all other case, a normal deletion request may be queried, but {{category redirect}} should almost always used instead (contents may then be moved but this is still easily reversible: all is kept visible in the page history, and at least we can still search and find the former names that have MANY references of valid uses when the former regions were official.
If any region or country had an official status, there's NEVER any good reason to delete them, as if they had never existed! This just complicates later the new imports of documents related to them, that are hard to categorize correctly, or these new files are left compeltely uncategorized as importers don't know where to put them and have never created any category page: the just use the import tools and select some broadly relevant categories, and this adds much maintenance work for others to recategorize these new contents that should have easily fallen in the former (deleted) categories. verdy_p (talk) 16:13, 4 May 2017 (UTC)
Yes, not just that one there are dozens of examples. Current policy clearly states all empty categories may be speedy deleted. I don't think that is right, but it is current policy - so its valid.
As for these actual categories, we need to careful with them as we don't want them used for new uploads. If I see a gate in Lourdes, take a photo and upload it, we do not want me to put it in Category:Gates in Midi-Pyrénées but in Category:Gates in Occitanie. That's the current unit, we want photos in there. A redirect is probably appropriate for Midi-Pyrénées, as it was been merged into a larger unit. If Midi-Pyrénées had been split between Occitanie and Nouvelle-Aquitaine, deletion would be only valid option.
We aren't wiping Midi-Pyrénées from existence by deleting cats like Gates in Midi-Pyrénées from existence. The category for Midi-Pyrénées itself still exists, and there is no reason to change that. Certain other categories relating to it should also be kept, such as Category:Maps of Midi-Pyrénées. @99of9:, anything you wish to add to that?--Nilfanion (talk) 09:29, 7 May 2017 (UTC)
I agree with my quick reading of what Nilfanion wrote. Category redirects can be put in place where appropriate. I don't think the loss of the category history is a big deal, since categories hardly ever have much history. --99of9 (talk) 04:31, 8 May 2017 (UTC)
I don't remember specific examples right now, but I've seen this happen dozens of times, maybe a hundred times, over the last 10 years: A user deletes a category, with no edit summary reason other than "empty category", or tags it for speedy with no other reason than "empty category", and it usually turns out that the same user emptied it 30 seconds earlier and caused the situation, usually with some batch tool, instead of bringing the category to discussion. Sometimes the category was well-populated. The user never discloses being the one that emptied the category, let alone a reason why the category was emptied: Their "reason" for why it was emptied is always just the self-justifying "empty category". It's a massive dodge around the general requirement to discuss controversial deletions, and one of the cases where Commons policy that "Administrators should take care not to speedy delete pages or media except in the most obvious cases" is summarily ignored: No administrator ever questions anymore why a plausible category, even a long-standing one, has suddenly become empty without even a redirect. (Maybe someone can search for my name involving empty category speedies, but I can't find anything right now; I know I've pointed it out in the past though.) Somewhere long ago I believe the guideline was that speedy deletion was only for categories that had been empty for 7 days or something, and somehow this requirement got wiped out; it was before the "formal" COM:CSD reasons came into effect. CSD needs to be changed to remove empty categories from "new" speedy deletion criteria G1: The empty-category situation isn't the same and has never been the same situation on Commons. Speedy deletion for being an empty category shouldn't be available to the user who emptied the category; if there's a good speedy reason, then the user should be able to cite one of the other speedy reasons. Otherwise, it can and should go to discussion. --Closeapple (talk) 05:07, 8 July 2017 (UTC)

Photos of children with geolocation[edit]

I've just tagged a kid's selfie with geotags for deletion. As a matter of child protection shouldn't photos of children with geotags be speedy deleted?

Perhaps with an exception where the tag is explicitly for a past event where the geotagging wouldn't result in any ongoing ability to locate the child, e.g. reportage of the bombing at the en:Ariana Grande concert. Cabayi (talk) 11:58, 7 July 2017 (UTC)

As a general rule, that seems very sweeping and rather pointless. LX (talk, contribs) 16:11, 7 July 2017 (UTC)
ACK: We've got COM:SELFIE, I don't really see the need to speedy delete things like this. --El Grafo (talk) 20:46, 7 July 2017 (UTC)

My two cents:

This is obviously about when a little girl named Shelly uploads a selfie called Shelly.jpg with a geolocation at the mall, then creepy guy with black van can say "Hi, you are Shelly, right? I'm your uncle, your Mom is sick. Trust me. I know your name. Come quick into the van. "

I think Cabayi is right, but do we need a policy for it? They must be spotted case-by-case.

LX says "sweeping" and "pointless". We may not be talking about new policy here. Just what admins ought to do.

El Grafo says we've got COM:SELFIE. That doesn't address anything like this. Correct me if I'm wrong.

When I see the next little Shelly.jpg with geolocation, I'm speedy tagging it. You can decline the speedy if you wish.

Anna Frodesiak (talk) 23:29, 7 July 2017 (UTC)

If the photograph is within COM:SCOPE (which should filter out most selfies), and the topic of the photograph isn't tied to its location, wouldn't it be less destructive to strip the EXIF geocoding, add {{Location withheld}} to the page text, and then suppress the old version like we do with certain copyright violations that have been blurred out? --Closeapple (talk) 05:29, 8 July 2017 (UTC)