Commons talk:Criteria for speedy deletion/Archive 2

Spam!

The page does not mention spam. Major omission. Palosirkka (talk) 08:21, 7 May 2013 (UTC)

it could use some links to COM:ADVERT Penyulap ☏ 10:17, 7 May 2013 (UTC)

Spam and advertisement should definitely not be a reason for speedy deletion. Although I agree that it should be the reason for a regular one. Everything can be considered spam by somebody. A person uploads several pictures of a work of art, that's spam to promote a particular artist. Another person uploads designs of tables, that's spam of table making companies. Etc. Etc. Etc. Sinnamon Girl (talk) 16:59, 7 May 2013 (UTC)

Yet again, a reasonable suggestion opposed without sufficient appreciation of what's dumped on us on a daily basis, probably precisely because judicious administrators do delete unambiguous spam on sight. (Most of it is textual rather than file uploads, and not just in the gallery and user namespaces, where it is actually mentioned.) As I've stated repeatedly, policy should be descriptive rather than prescriptive. People blocking every suggestion put forth on this page seem to think that all our administrators are raving lunatics who cannot be trusted to make sound judgements on their own lest they'll delete every single file on Commons. Meanwhile, they seem to believe that as long as we limit the number of criteria on this page, said raving lunatics will surely exercise restraint. —LX (talk, contribs) 19:37, 7 May 2013 (UTC)

Please let me be the first to misquote "...all our administrators are raving lunatics who cannot be trusted to make sound judgements on their own..."

Brilliant and concise.

Admins can do the job, but the page is not just for admins, it's for everyone, and newbies have to learn somewhere, a few extra links can't hurt. Penyulap ☏ 20:03, 7 May 2013 (UTC)

It's not about them being raving lunatics, but about them actually performing random "cleanups", and then I have seen several undeletion requests where the deletion admin says "I am not restoring the file only to open a regular deletion request, find another admin". So there is a huge hurdle for people for people to actually argue for each specific undeletion which is needed for them to even make their case that file should not be deleted. However, if we have some specific guidelines then it would be much easier to point to it and say "per COM:SPEEDY". So it is not "a reasonable suggestion opposed", but rather "an unreasonable suggestion proposed". If I would propose that photos taken in Paris during the night should be speedy deleted, I would be met with the exact same response, and it's not about any kind of -scriptive, it would be that FOP of light work is an issue for DR. However, since you've slightly altered what was being said by your example of the text based spam, I will agree with something like "Text only contributions to the gallery space can be speedy deleted, especially when they appear to play a role of spam", although details should be discussed a bit more (what if somebody wants to move this text only contribution somewhere, etc). Sinnamon Girl (talk) 20:12, 7 May 2013 (UTC)

Actually that is fair enough, I see your point with admins who don't bother to do the job of undeleting images when requested. Probably best is to be flexible with criteria, but balance it by making the undeletion for a regular DR easier. There is the difference between UDR's that follow a DR and UDRS that follow a speedy. Penyulap ☏ 20:40, 7 May 2013 (UTC)

There has been some useful progress. Shall we try again?

I have just found the time to read this proposal and the discussion in full, and all I can say is that it perfectly exemplifies the difficulty of using MediaWiki for collaborative editing. Some of the discussion reads too much like an English Wikipedia 'drama page' rather than a typically mellow Commons discussion. That has probably harmed the opportunities for community agreement. My take on this - as a so-far uninvolved editor - is that there is in fact a large measure of agreement that the very basic speedy deletion rules currently set out at Commons:Deletion policy#General: speedy deletion could be improved upon and could be better exemplified, although there is disagreement about the potential scope of any new rules and also whether they should be defined as policy or merely as a guidelines.

It ought to be possible to do better than this, and I'd like to see whether a plan along the following lines would have community support:

• 1. The existing draft and comments should be archived onto a separate subpage and labelled Draft 1
• 2. A new working draft should be prepared taking into account all uncontentious/unchallenged suggestions that have already been made on the talk page, and an effort made to summarize the major points still at issue
• 3. This should then be widely publicized, for constructive comments but not votes.
• 4. During the discussion phase nobody should touch the working draft so that there is a fixed text for discussion
• 5. At the end of the discussion phase, repeat from step 2 (or step 1 if a total re-write turns out to be needed)
• 6. Assuming a high level of community agreement can be obtained, then and only then call for a vote.

To avoid the tendency for discussions like this to fracture hopelessly, I suggest we should informally appoint an editor as unofficial clerk. The clerk's job would be to prepare the next working draft (point 1 above), to move things along, to keep discussions on track, and to be responsible for making community-agreed changes to the drafts at the end of each discussion stage. I don't have strong views as to who should take on that the clerk role provided that he/she can act impartially. If anyone wants to put themselves forward as a volunteer please do so. If nobody wants to stick their head above the parapet, I'll offer to do it myself, but wouldn't want to force that on anyone. --MichaelMaggs (talk) 17:49, 2 May 2013 (UTC)

• why is it needed ? what is broken ? There are pedantic people and always have been, some admin came to my talkpage demanding I fill out source and licensing for three versions of a broken file (the file was large, wasn't uploading properly so I was re-trying to upload it about once per hour and hadn't yet been successful, so it's like, I'm being told to polish up a turd before flushing it into the toilet. First cab off the rank is the same thing "1. Gallery without images or other media files." Someone starts an argument with someone who is not yet finished their work, citing this page. Where is the sky falling is all I'm asking.
• I think that the less we have written down to argue over the better, because the alternative is THINKING. That's a painful, but effective, alternative. Penyulap ☏ 23:50, 2 May 2013 (UTC)

It's needed because the current speedy deletion rules have not been looked at in many years and are out of date. It's absolutely mot true that "the less we have written down to argue over the better", as will be well understood by anyone who has been here long enough to remember the huge anger that was directed towards Commons in the days before we had a proper definition of Scope, and images were being deleted based solely on admin discretion. That has (largely) subsided, but unannounced speedy deletions can still cause huge irritation to users on other Wikis, and the least we can do is to have some agreed definitions that admins can work to. The purpose is clarity and transparency. --MichaelMaggs (talk) 08:06, 3 May 2013 (UTC)

• One thing that would be very useful is to state that this is the exclusive list of reasons, currently many admins engage in what some of them call "cleanups" and delete massive amount of media that has never been discussed or that is currently being discussed. There's nothing wrong with deleting something right after it's been shown that it's a copyvio, but there is a lot wrong with the deletion of an image that a single individual can't find the educational use for. So we list things that are absolutely needed to be removed right away, and say "for all else go through the discussion for a week, since it will hurt nobody". Sinnamon Girl (talk) 16:54, 3 May 2013 (UTC)

I absolutely agree. We should define as closely as possible an exclusive list of reasons that admins can use to delete quickly in the expectation of general community support, with everything else left to DRs. --MichaelMaggs (talk) 17:55, 3 May 2013 (UTC)

One good reason for moving towards an agreed set of criteria for speedy deletion is to avoid the type of issue that has happened at Commons:Administrators' noticeboard#Mass speedy image deletions without due process or rationale. --MichaelMaggs (talk) 12:17, 12 May 2013 (UTC)

G7: Personality rights

As per here, this change needs to be implemented to reflect COM:IDENT and existing practice.   — C M B J   00:33, 16 June 2013 (UTC)

Please rephrase. "Author/uploader requests to delete depictions of a living person should be honored regardless of date or use." also covers pictures of Obama, Angelina Jolie, etc.

Also state why it has to be speedy, why is a normal dr not sufficient. Speedydeletions are reserved for uncontroversial deletions, your example however is not. --Isderion (talk) 01:11, 16 June 2013 (UTC)

The fact that the above example generated any friction is an example of why this codification is necessary. If someone—anyone, regardless of status—feels threatened, shamed, regretful, or that their identity is being unnecessarily damaged, or that their personal privacy has been violated, or that their personhood has been otherwise compromised in any way whatsoever, then we plainly shouldn't continue disseminating such content, both as a legal precaution and more importantly as a matter of human compassion. The only foreseeable occasion when an exception should be made is if for some reason a media file itself is iconic or irreplaceable, for example Beatles - Abbey Road.jpg if it were freely licensable, which might then warrant special community consideration.   — C M B J   01:58, 16 June 2013 (UTC)

Personality rights (aka publicity rights, generally the use of one's image in commercial contexts such as advertising) is not a reason for regular deletion, let alone speedy. I think what you are referring to is more about privacy or other human decency concerns, where personal exposure on Wikimedia sites has unintended or unwelcome consequences. It's a legitimate concern, but very different, so I would not use the term "personality rights" when discussing this at all. As for the proposal... I can't really favor a no-questions-asked automatic-deletion policy on such matters; that would be too open to abuse for me. Secondly, the standards on public figures should be very different in my opinion. I would certainly support waiving the normal 7-day waiting period for such types of requests in normal DRs, but I think there still needs to be some discussion, and I don't like it being added to a speedy deletion guideline, which is primarily for very obvious situations. If there is a sensitive private matter, I could see it being handled through OTRS as well. Your proposed addition is much too far over-the-top for me, and I think you should get general consensus (probably somewhere other than this page as well) before making that edit on the policy page (even the proposed policy page). Carl Lindberg (talk) 03:48, 16 June 2013 (UTC)

Commons' use legally constitutes commercial use and the issue at hand here is very much one of personality rights, at least in the most general definition of that term, but you're right in that this is primarily about the issue of privacy—a fundamental human right under international law. The problem of abuse is something that I'd sincerely prefer to see deterred by any provision in this area, but requiring someone to engage in a public discussion about an unflattering picture of themselves is not a conscionable demand for multiple practical reasons. As for public figures, I recognize that they are open to a greater level of scrutiny, but I see no valid reason why we would deny any person's request to cease distributing a photograph of them that causes anguish unless we have some pressing reason to retain it in the public interest, which would be something like 0.01% of the 0.00001% of media that could ever be caught up in such a scenario.

In any event, OTRS handling is a fine suggestion and I would be fully supportive of that as being where we direct all such requests, but we need to have a dependable plan of action that is standardized across all policies and help pages. That's all I ever sought to accomplish here.   — C M B J   06:48, 16 June 2013 (UTC)

The more unnecessary criteria we have, especially on controversial DR's, the greater potential we have for abuse.. obvious, very public abuse of the criteria, and the resulting public damage that does. Where people want to have a say, a Streisand effect on a cover-up won't help the projects goals. Better to have and use the existing criteria which people are quite happy with to deal with all of the urgent cases, or get some support first, rather than marching every reason we can think of into the closed shop one by one. Penyulap ☏ 04:32, 16 June 2013 (UTC)

I am not trying to propose a framework for abuse or convoluted censorship. In fact, it was this discussion that prompted me to come here, and in which I ironically found myself being forced to defend a very controversial portion of this project's content. I have also vehemently opposed every incarnation of this monstrosity every time it has tried to come back from the dead. However, I do strongly believe that we should respect anyone's genuine request to cease distributing photographs of their person, whether legal or not, and without causing them further distress. We supposedly honor such requests under current policy, either by way of appealing an administrator directory or by invoking office action, but I can see from the handling of Joshb's timid requests that the existing deletion criteria can fail miserably and in such a way that should not ever be allowed to happen again. I am not opposed to hashing out a very precise way of handling this problem, but the central point I am trying to make here is that we must implement a standardized and straightforward approach so that nobody leaves here feeling like a victim.   — C M B J   06:20, 16 June 2013 (UTC)

That is precisely what I'm trying to do at the village dump right now, section title is commons a tool for tools. Apparently it is. We have Jimmy doing everything to defend himself, as he should, in what unfortunately appears to be the most partisan way possible, so it applies only to him, and everyone else can continue to use commons this way. It has to be fixed, I'd like to try and use the momentum to make useful improvements in this area.

Incidentally, I am not surprised by the mishandling you point to, see the top of my talkpage. (facepalm)

The signpost idea, which, roughly translated and summarised as a RL analogue would be "We can fix the United States of Utopia's problems, and all the rest of the worlds problems including silencing our critics, by making the whole world just the same as the United States of Utopia." Penyulap ☏ 07:00, 16 June 2013 (UTC)

Artistic depictions (e.g., caricatures) really shouldn't fall into the same category because that would violate someone else's right to expression, especially in the context of public figures, so I can't really back Jimbo on that one. The Signpost discussion was out of touch to say the least, though, that's for sure.   — C M B J   07:19, 16 June 2013 (UTC)

I think they could be included in something of a talkpage consensus sort of thing. I think we have different standards for a consensus according to the type of discussion and that is nothing new. So if there is at least a 25% objection that allows an image to be deleted then conversely adding a few more people to the discussion would bring it back. Keeps out attack images, keeps in caricatures and everyone is happy. Penyulap ☏ 07:53, 16 June 2013 (UTC)

Time to make this policy?

Numbering?

As this has been brought up above, let run the following as a sperate proposal - should the criteria be numbered, either (a) formally, (b) for template use only, or (c) not at all. --Mdann52talk to me! 19:22, 15 March 2014 (UTC)

 Comment It has been suggested above that this looks too much like enwiki, but in fact at least eo:Vikipedio:Regularo pri tuja forigado, es:Wikipedia:Criterios para el borrado rápido, fr:Wikipédia:Critères de suppression immédiate and probably others also have this. I've no opinion on whether it's a good idea. darkweasel94 20:45, 15 March 2014 (UTC)

 Support formally. I see no plausible issues whatsoever in implementing this entirely. It would also make linkages and referencing-to much more easier. "We should be different from the Wikipedias" is no valid reason to not make this improvement (I'm referring to old discussions which we had here years ago). As a separate proposal, it would also allow us clean out the clutter from the current delete-reasons in the dropdowns; a link on the number to the CSD description would direct the reader to a much more brief and meaningful explanation on why their/the content was deleted. The link could, of course, be the prefix to a much shorter delete-reason description. Rehman 03:49, 16 March 2014 (UTC)

{{S}} for template use only --Zhuyifei1999 (talk) 04:50, 22 March 2014 (UTC)

 Oppose = (c). As soon as the criteria would be numbered, it would be likely that only the numbers are used in discussions, making it more difficult to follow for newbies. --Leyo 10:55, 22 March 2014 (UTC) PS. To be honest, I do not fully understand option (b).

Completely agree, but that is not a bad thing. Yes, people would most probably use codes more frequently, at discussions. But the deletions logs, and other key areas will have/should use the full version (C2. Renamed or duplicate category.). At discussions, saying deleted per "G1" (preferably with [[COM:CSD#G1|G1]] link) is much more convenient that saying deleted per "Test page, accidental creation, or page containing nonsense or no valid content". Just my thoughts. Rehman 16:04, 28 March 2014 (UTC)

 Support (a) as inevitable: If we implement Now that we have a specific list of speedy criteria, people will probably start using namespace+number or letter+number as shorthand whether it's approved here or not. We should nail down which labels mean which thing, before users start inventing their own and mixing up Category with Commons and Gallery with General. Even on Wikipedias where there is a single language, discussion participants sometimes provide awkward references by a phrase instead of a label: Sometimes users reword the title, and newbies can't easily find that title on the speedy criteria page; or sometimes weird people make up their own titles and nobody else can figure out which criterion it was supposed to mean. These labels are probably even more important on Commons because it's a multi-language project. It would be very easy for regular discussion contributors to use a template like {{sdreason|A1}} in discussion, which could show a tooltip (short phrase when hovering the mouse over the label) and a link; and those could be shown to the user's preferred language quite easily, I think. --Closeapple (talk) 21:31, 26 March 2014 (UTC)

 Oppose per Leyo. --Steinsplitter (talk) 11:06, 28 March 2014 (UTC)

 Neutral. Please simply leave this page (the policy page) as it is. If you want to link to specific anchors, it's possible right now but we gain nothing in further promoting shortcuts like F1. Anyone is free adding parameters to our speedy-deletion-templates for shorthand versions but the template then must sufficiently explain what F1 is and the template must continue being usable without these shortcuts. -- Rillke^(q?) 12:04, 31 March 2014 (UTC)

Sometime in the (near) future, I will implement shorthand codes (eg. F1) for templates only, but leave a link to the full reason here (basically, implementing Rillke's suggestion above). Any complaints? --Mdann52talk to me! 07:32, 1 April 2014 (UTC)

When to use speedy

I don't quite understand should all non-controversial deletions be marked speedy or should speedy be reserved for stuff which are urgent, like copyvio? The word itself would seem to suggest the latter interpretation. Palosirkka (talk) 13:10, 26 March 2014 (UTC)

Uncontroversial requests should fit in existing criteria. Is there something that is not mentioned? To answer your question, uncontroversial requests are best tagged as speedy, as it would save a lot of time and hassle. But of course, doing so is not required. Rehman 14:23, 26 March 2014 (UTC)

I realize uncontroversial deletions could be marked as speedy but I was wondering whether it was the preferred way. Thanks for the answer, made things clear. Palosirkka (talk) 19:59, 26 March 2014 (UTC)

Because of the broadly-worded criteria on the page currently, I think it should be made clear that (1) discussion is always a safe option and never a prohibited option, and (2) particularly for Commons criteria, just matching a criterion does not automatically make a page safe to delete instantly: it must also be highly unlikely to survive a deletion/move discussion, and the admin should consider whether someone would want to comment or disagree before the deletion happens, regardless of the criterion. --Closeapple (talk) 22:03, 26 March 2014 (UTC)

Tagging

Per the docs to the Extension Translate (mw:Special:MyLanguage/Help:Extension:Translate/Page_translation_example and mw:Special:MyLanguage/Help:Extension:Translate/Page_translation_administration) a page should not have useless translate-tags (see examples) and list mark-up should not be omitted in units. Please not abuse vandalism-fighting-only rollback tool for rolling back edit's made towards the docs. --BaseSat (talk) 17:45, 30 March 2014 (UTC)

Proposed change to File criterion number 8, concerning which duplicate to delete

I've been having a minor dispute with billinghurst (talk · contribs) (see User talk:darkweasel94) over which files to delete when there is a duplicate, and I have now noticed that this policy appears to support his view.

The problem is that I've been tagging some duplicates (both versions uploaded by myself), and I've been tagging the ones with the inferior categorization and description for deletion, because that saves the work of redoing the better categorization. Many times, that better-categorized file was actually the newer one, and this policy says that the newer one should be deleted, which is what billinghurst (but not other admins) has done. That creates far more work for me to redo the categorization than it would for the deleting admin to create a redirect.

I therefore suggest that we change this wording:

The generally accepted rule is to delete the newer duplicate, but that may not always be the case, such as when comparing between a user uploaded file, and a bot uploaded file.

to something similar to:

In general, the file that has more informative and accurate existing description and categorization should be kept. If it is not clear which description page is more informative and accurate, the newer file should be deleted.

Thoughts? darkweasel94 13:40, 14 July 2014 (UTC)

You always have the opportunity to seek community comment in an RFC. At this stage, I am just mopping.  — billinghurst sDrewth 13:53, 14 July 2014 (UTC)

Last time I processed duplicates, there was a tool that made it easy to merge descriptions and categories no matter which was kept. I support the status-quo rule, because it makes it easier for non-administrators to verify how long we have had the file (which is useful in evaluating some copyvio issues etc). --99of9 (talk) 00:56, 15 July 2014 (UTC)

I agree that we should, as a general rule, keep the older file, mostly because, as 99 says, it preserves the original upload date, but also because having a firm rule is helpful rather than having to decide which one has the better information. I think it is overstating the case to suggest that it is very difficult to combine the two descriptions and cats -- it's a simple cut and paste.

And, in any case, I think the proposed change is backwards:

"In general, the file that has more informative and accurate existing description and categorization should be deleted."

It should read:

"...more informative...should be kept."

.     Jim . . . . (Jameslwoodward) (talk to me) 11:48, 15 July 2014 (UTC)

Ah. Yeah. Stupid me. I was a bit confused yesterday due to lack of sleep, sorry. I've corrected it above. As for your point - combining description and categorization isn't "very difficult", but if you have many files, then it can be time-consuming. More so than creating a redirect. The original upload date can always be looked up by seeing a redirect in the usage list and looking at its upload and deletion logs. darkweasel94 11:58, 15 July 2014 (UTC)

Update page to have templates that are listed at Category:Candidates for speedy deletion

I'd like to see T:10 read:

If a category or any other kind of page is empty you can use the template {{emptypage}} that's equal to {{speedydelete|It's empty}}. For copyright violations use {{copyvio|optional URL}}. For duplicate files use {{duplicate|other file}}. The template {{speedydelete}} is deprecated for most uses.

So that it recommends the current best practice of only using the speedy delete template for things that don't fall into other categories. The copyvio template isn't even mentioned on the page currently. Zellfaze (talk) 20:32, 24 July 2014 (UTC)

Proposed criterion - unused out of scope pages by users with no cross-wiki contributions

Hello. I would like to propose a new criterion. FWIW, I have been using this criterion for a long time before I even knew about this page (and possibly before it even became policy).

It would read something like this:

10. Newly uploaded, unused, out of scope files by users with no meaningful cross-wiki contributions

Commons is not a web host. "Meaningful cross-wiki contributions" is here defined to mean any edits which are not vandalism, are not test edits, and are not to pages which were immediately deleted on the host-wiki. Files falling under COM:PORN are explicitly exempted from this criterion and should be nominated for deletion via the standard process.

In essence, this clause is meant to combat the utter flood of out of scope images uploaded by new users. By "flood", I mean hundreds per day, literally (as a species, we are just not very good at realizing the depressing truth that we're not very important - and as such, think that their photographs should be uploaded here). Take a look at any recent page on User:OgreBot/Uploads by new users to realize the breadth of the problem.

These files include, in order of frequency:

• Selfies
• Pictures of family/friends
• Curriculum vitae
• Personal essays/attempted Wikipedia articles (e.g., File:MANUEL YARLEQUE ESPINOZA.pdf)
• Motivational images/religious texts. E.g., Pretty-colored images stating things like "God loves you," "Allah believes [this or that]" (usually in Arabic, Persian, or Urdu), etc. (e.g., File:تبلیغات پویش.jpg - deleted as copyvio, sorry).

I have explicitly exempted pictures of genitalia, although they are frequent, because there is controversy on when they are in scope, and we probably should have them go through a discussion before deletion. If anyone has a problem with any of these types I just mentioned, I would be willing to compromise and remove them, with the exception of selfies and family/friends.

Magog the Ogre (talk) (contribs) 16:17, 31 August 2014 (UTC)

•  Support because too many new users are treating Commons as a free webhost. I think one selfie should be accepted if the user makes at least 25 unreverted edits on any content wiki including Commons. I understand that some outreach activities encourage new users to upload a personal photo for their user pages but I think such photos should be clearly marked and limited to one per user. PDF/JPG essays and CV's have no good reason to be on Commons and should be speedily deleted as should any motivational images unless irrespective how inspiring the calligraphy is because Facebook is full of them, usually accompanied by a chorus of likes. Green Giant (talk) 00:11, 2 September 2014 (UTC)
•  Support Commons seems to be a homepage to many new users.--Motopark (talk) 03:49, 2 September 2014 (UTC)
•  Support Yann (talk) 05:32, 2 September 2014 (UTC)
•  Support --Steinsplitter (talk) 06:10, 2 September 2014 (UTC)
•  Oppose the examples "selfies" and "pictures of family/friends",  Support the rest. Photos of human beings can sometimes be in scope in unexpected ways, and possible reasons why they might be unique enough deserve to be heard for a week. darkweasel94 08:23, 2 September 2014 (UTC)
•  Oppose photos of people. They can occasionally be useful and may deserve a deletion discussion.  Support curriculum vitæ and useless texts such as File:MANUEL YARLEQUE ESPINOZA.pdf. I'm not sure exactly what "Motivational images/religious texts" means, and the example has been deleted, so I won't comment on that. Some religious texts may be personal essays or attempted Wikipedia articles. --Stefan4 (talk) 17:56, 2 September 2014 (UTC)

Stefan, I think Magog is referring to the kind of religious images that can be seen here, here, and here. Green Giant (talk) 18:53, 2 September 2014 (UTC)

I agree that it is a good idea to speedily delete such files, unless the text can easily be removed. Some of them might be useful without the text. --Stefan4 (talk) 18:56, 2 September 2014 (UTC)

Perhaps they might be useful, but the elements of the image are often not free in those cases –⁠moogsi (talk) 23:50, 2 September 2014 (UTC)

Please don't get me wrong - I respect everyone's opinion here. But at the same time, I'm not sure that you're aware of how much overhead in DR it would create to disallow speedy deletion of selfies. Yes, technically, they might be useful somewhere, somehow. But we can put in a clause that says something to that effect. Really, I'm going to be honest, the chances that any project will find a selfie of a 15-year old kid to be useful are tantalizingly low. Magog the Ogre (talk) (contribs) 00:42, 3 September 2014 (UTC)

Not to mention that pictures of minors (including selfies) without proper consent should be speedy deleted. Regards, Yann (talk) 10:42, 3 September 2014 (UTC)

That's actually neither in the criteria now nor is it under discussion here. If you want to propose that, it's better if you do so in a dedicated section. darkweasel94 11:42, 3 September 2014 (UTC)

Perhaps a solution could be to do it similarly to how we now have templates for "no source", "no permission", etc., i.e. with dated templates and categories and deletion after seven days of no objection? That way we would be reducing overhead in the DR system but still give people seven days to possibly defend the image by starting a DR. I wouldn't want one trigger-happy admin to speedily delete a photo of Homo sapiens that could still be within scope (which isn't limited to possible on-Wikimedia use, after all) in a not-completely-obvious way without anyone having the ability to give counterarguments. darkweasel94 11:42, 3 September 2014 (UTC)

Low quality selfies and family snaps are the main problem; "no source", "no permission", etc. don't cover them. A new template to handle not a web host may be enough so that uploader can make counter argument (on file talk page) within 7 days. Jee 12:02, 3 September 2014 (UTC)

Yeah, that's what I mean. I'm just opposing speedy deletion of "personal" photos. Not easier deletion, such as through such a new template, although I'm not sure about the best name for it. darkweasel94 12:27, 3 September 2014 (UTC)

If the problem is low quality selfies, let us include "low resolution or bad quality" in the criterion. We may very well get very good examples on people from corners of the world not well represented otherwise. --LPfi (talk) 09:19, 5 September 2014 (UTC)

•  Support Jee 11:28, 3 September 2014 (UTC)
•  Support I'd very much welcome a solution with a template comparable to "no source", "no permission", etc. as proposed above. Ideally, add it to the Quick Delete gadget for easier usage and automatical posting of an appropriate message to the uploader's talk page. A grace period as used in the existing criterion 5 may be a good idea as well. --El Grafo (talk) 14:48, 3 September 2014 (UTC)
•  Oppose: It is exactly because Commons is not a hosting service, that when evaluating a file its uploader’s motivations and envolvement in the project(s) should be irrelevant. And for that same reason (that Commons is not a hosting service), the opinion of the uploader should weight not more than anyone else’s concerning its worth for Commons (indeed much less, for the kind of new, unexperienced users this proposal aims to).

Imagine a drive-by vandal uploading a self-created image with the sole purpose of vandalizing a wikipedia page — the uploader may be banned or vanished, their edits undone, their user page blanked… but yet the properly contributed image is now one of our best items under Category:Animal feces, for instance. Ditto for that selfie which was uploaded on nothing more than a moment’s frivolity and yet perfectly illustrates a specifc type of eyewear, dental barces, freckle pattern, facial expression, hairdo, jewellery, et c., et c., et c.…

Some times well-meaning users upload files they deem useful for Commons and which yet end up deleted for a number of reasons (low quality, copyvio, et c.); why should the opposite not be allowed too: That useful content is created and donated by a frivolous, oblivious uploader?…

But anyway…

• …too many uploads for the community to handle with proper DRs? Simple, just turn off mobile uploads (unless that gets super-protected, in which case the matter would have to wait a whole WMF election cycle to be sanitized) — any upload its promoter is ready to postpone and prepare is less likely to be the kind of frivolous rubbish we all agree should be discouraged.
• …too few admins to close DRs? Simple, just stop boycotting the creation of a new group “Deleter”, and maybe stop stonewalling resourceful and hardworking people from becoming admins for unsaid reasons.

All the examples listed in the OP above would / were / will be swiftly deleted in regular DRs (or as copyvios, for the tacky backgrounds); no need for new policies. -- Tuválkin ✉ 14:10, 5 September 2014 (UTC)

•  Oppose. It's official Commons policy that you don't need to be a member of any other WMF project to upload/use files hosted here - the only requirement is that they be correctly licensed, and have a realistic educational use. It doesn't take a genius to realise there are many legitimate reasons why someone might upload an image to Commons, without having any other "meaningful cross-wiki contributions", therefore falling under the proposed wording of the new criteria. The potential harm to Commons of having their uploads mistakenly deleted should be obvious, even though some people will no doubt claim it doesn't take any effort to undo such errors (when it obviously does). If there is a need for speedy deletion of specific classes of image which an admin might think are uncontroversial cases of COM:NOTHOST, then I would prefer something like Darkweasel's suggestion, a process like en.wikis PROD system, but limited to just a small class of images, e.g. Template:Prod-seflie, Template:Prod-CV, Template:Prod-text, and only applied to images uploaded by new users (who might not yet be aware of COM:SCOPE). I would like each template to be specifically worded, so that there can be no confusion at all as to when it applies and when it does not - e.g. Template:Prod-seflie would say something like, "unused self-portrait of a living person, with no apparent educational use". Ultra7 (talk) 16:50, 5 September 2014 (UTC)
• I'm also noting that I've previously seen admins delete e.g. images of computer keyboards without discussion as "out of scope". (See Special:Log/Montehurd, at least some of them were, as I recall, images of (parts of) MacBook Air keyboards that were far from totally unusable, similar to the two that are still there and that I just categorized). If we actually write such wording into the policy, I'm sure its vagueness will be used to justify these kinds of deletions, which is an obviously bad thing. (Pinging User:Montehurd, User:Denniss here as this is about their actions.) darkweasel94 17:20, 5 September 2014 (UTC)
• "Commment - I'm distressed to see the high number of slippery slope fallacious arguments here. No one is talking about deleting keyboards or animal feces or uploads by people just because they're new uploaders. If any admins are deleting such an image, then they should be censured, just like improper deletions under the current criteria are held. The only thing we're going after is images which by very definition are out of the project scope and thus not useful. Maybe those of you who are opposing will volunteer to handle the DRs for hundreds of selfies uploaded every day. But hey, let's not delete those utterly non-educational and unremarkable picture albums of your BFF's 16th BD OMG LOL :D because animal feces and logic. Magog the Ogre (talk) (contribs) 17:43, 6 September 2014 (UTC)
  • No one is saying "let's not delete them". Only "let's hear arguments why they should not to be deleted for a week". User:Tuvalkin has given some examples of how photos of human beings can be in scope at second thought, even if they appear not to be at first thought. Allowing an admin's first thought to be the only deciding factor in such cases is a bad idea. It also strikes me as absurd that COM:PORN is exempted from it: that means that with this criterion, admins can speedily delete images of noses, faces, elbows, toes, but not of penises or breasts, giving the latter preferential treatment. The reason we're hosting images of penises is that we consider them simply another part of the human body – and now we're going to have a criterion that allows speedy deletion of images of all body parts except genitalia? I absolutely defend that we illustrate all body parts, including genitalia, but not especially genitalia. darkweasel94 09:44, 7 September 2014 (UTC)
  • If the criteria says an admin can unilaterally delete an image just because they can't see a use for it and the uploader has "no meaningful cross-wiki contributions", then you can bet your life they will. And any admin who does that thousands of times a day won't be censured, they'll be applauded as being the best admin ever - that's just how some people here see the role, unfortunately. If you truly believe there's a few classes of image which are "by definition" out of scope, I'm not seeing what would be so difficult about incorporating specific wording to that effect into the proposed criteria. Not only would that solve the problem of this proposal going directly against policy as written, it would also give the uploader at least an idea of why their upload was summarily deleted. Ultra7 (talk) 19:52, 7 September 2014 (UTC)
•  Oppose We can try to define some types of "obviously out of scope files" but the definition should be based on the content and usability of the file, not on the person of the uploader and his/her activities. --ŠJů (talk) 18:17, 6 September 2014 (UTC)
  • A few selfies are in scope if a user contribute to one or more Wikimedia projects. However if his/her only contributions accross all projects are selfies here, they are out of scope. That's a pretty clear and objective criteria to me. I don't see the point of creating a DR for these. Regards, Yann (talk) 05:00, 7 September 2014 (UTC)

•  Oppose per ŠJů. I'd support a speedy criterion "obviously and beyond any reasonable doubt out of scope", but the crosswikiness of the uploader is not necessarily relevant. --Krd 19:27, 21 February 2015 (UTC)

Pushing this policy into full effect

Hi all. Even though so much effort were put in to make this an official Commons policy at least up to a year ago, none of the criteria is used in the deletion logs even today. This is bad, obviously because most of the deletion summary currently used is with very little meaning, or links to something very general/broad that doesn't really explains much to a newbie.

I propose that we finally change the MediaWiki:Deletereason-dropdown page, so that it would include only:

1. The existing criteria per official CSD policy.
2. Only one additional line on top of the General section, which just reads "Per".

As most of you working with deletions would already know, there are two fields for entering a summary when deleting content. The first field directly fetches from the Deletereason-dropdown MediaWiki page, while the second is optional, and left blank for the admin to fill. 2. above will be used for all other non-CSD deletions (such as Deletion Requests, etc), and will make use of this blank space. For example, a non-CSD deletion summary would look something more like: Per Commons:Deletion requests/File:Inti Wiki.png. The link was picked randomly from the deletion logs.

The summary format for 2. is already the format currently being followed (mostly via automated processes), so there is no impact to that segment. The additional line only supports for those who does it manually.

I'm not sure how many of you are still watching this page, so I will reference this discussion on other pages, to direct folks to this page. If there are no solid reasons going against this proposal, I will go head and update the dropdown lists in goodfaith. Rehman 04:38, 19 February 2015 (UTC)

•  Support TBH, not that I watch the deletion logs particularly (or have the ability to delete files) but 'merging' the official CSD criteria with the list of actual 'options' admins have seems like a no brainer... it doesn't actually change 'why or how' things are deleted, it's just a matter of making the 'interface' match the actual policy for the sake of better logging. Revent (talk) 06:35, 19 February 2015 (UTC)

•  Support Agree that this would be helpful to newbies -FASTILY 06:39, 19 February 2015 (UTC)

• Is this only about speedy deletions (given where this is being discussed) or about deletions in general? Looks to me like it's the latter.
  Given that, do I understand correctly that this means that when deleting a poorly named category, there will be no way to indicate the correct name of the category in the log? If so, then **Oppose**. If not, then probably this proposal needs to be explained more clearly. - Jmabel ! talk 08:41, 19 February 2015 (UTC)

Yes, that will still be possible, and will remain unchanged. As I mentioned earlier, the changes will only be to the dropdown field. The second blank field (where the correct category name would be mentioned), will remain untouched and mostly irrelevant to this discussion. Rehman 09:13, 19 February 2015 (UTC)

@Jmabel: Yeah, the actual 'proposal' is a bit hard to parse (no offense intended). The idea is to refactor the options in the 'dropdown' menu for admins when deleting a page (the first field) to actually match the CSD criteria, while still having a 'per this DR or whatever' option, and still allowing you to put whatever text you need to in the second field. Merely an interface tweak to match the CSD criteria instead of having a big list of 'general' reasons, so that people can find what deletions were done by a 'specific' CSD reason in the deletion log. The only 'real' change, as I understand it, would be to the edit summary when you delete a page. Revent (talk)

There you go! Thanks Revent. :] Rehman 09:41, 19 February 2015 (UTC)

Thanks, that is much clearer. Support. - Jmabel ! talk 16:21, 19 February 2015 (UTC)

• I think I support, in principle, but it's unclear exactly what the end result is going to be. Could someone please list exactly which options are going to be provided in the fully-revised drop-down list? There are lots already (too many) and if the proposal is simply to add more that will in practice make it harder to select the right option when deleting things. We should take the opportunity to rationalise the existing options as well as adding new ones. --MichaelMaggs (talk) 10:00, 19 February 2015 (UTC)

The existing list would be replaced entirely, to match the criteria laid out per the CSD policy page. The only additional field would be the "Per" field, as discussed above. In other words, no, it is not a pile-on to the existing list. Hope this clarifies. Rehman 10:17, 19 February 2015 (UTC)

I started to edit MediaWiki:Deletereason-dropdown/proposal, but oddly that page already exists (and I can't edit it). (DR anyone?) I would suggest (and I think this is Reh's idea) ....

* General

Per: (to be filled in the second field with a ref to the discussion or policy)

* CSD

(mirror the list on the CSD page)

or something to that effect. Revent (talk) 10:39, 19 February 2015 (UTC)

The proposal is a good one, but seems to assume that all possible deletion reasons are listed on the CSD page. That's not a fault of this proposal but a lack of clarity on what is on the policy page. If in fact the page does list all possible deletion reasons, then the list should be moved to a new 'Criteria for (normal) deletion' page, with the the CSD page adding the additional criteria needed for the deletion to be speedy. Anyway, that is another issue that could be dealt with separately, and would not stop this proposal being enacted now. --MichaelMaggs (talk) 10:56, 19 February 2015 (UTC)

The CSD list does not include all possible deletion reasons, such 'out of project scope', and it would a pity to lose that from the drop-down list as it is used so often. --MichaelMaggs (talk) 11:05, 19 February 2015 (UTC)

Such a reason could be "Per: COM:SCOPE", and listed as a 'general' option... I freely admit that my 'text' above is not based on actually knowing how the page is parsed, I'm rather AGF that whoever makes the edit will have more clue than me (lol). The idea is to make the CSD specifically accessible in the summaries in the deletion log. Revent (talk) 11:25, 19 February 2015 (UTC)

The most used deletion reasons should be keep imho. I mean, not making a CSD only dropdown-box. --Steinsplitter (talk) 11:28, 19 February 2015 (UTC)

The broad "out of project scope" is broken down into various criteria (also mentioned in the description). Just for discussions sake, is there any specific type of case that you know which wont fit in the existing list? I agree that this is a bit difficult for us admins nah, scrolling and deciding a proper reason is not really difficult, but it does increases the quality/meaningfulness of the deletion logs. Rehman 11:29, 19 February 2015 (UTC)

I have no problem with adding CSD criteria but widely used criterias like "Copyright violation; see Commons:Licensing" should be keept. :) --Steinsplitter (talk) 11:33, 19 February 2015 (UTC)

Copyright violation is included. First entry in the File section. :) Rehman 11:41, 19 February 2015 (UTC)

Michael, presumably the intention is that the deletion reason for anything that's not a speedy deletion should be a reference to a deletion discussion, which in turn would contain the more specific reason (such as a link to Commons:Project scope). —LX (talk, contribs) 20:52, 19 February 2015 (UTC)

Ah, good point. --MichaelMaggs (talk) 04:31, 20 February 2015 (UTC)

• I have created speedy deletion templates for criteria I frequently use (such as {{SDG1}}). Should such templates be created for all criteria and users asked to use them? Fully implemented, a CSD dropdown wouldn't be necessary.    FDMS  4    13:16, 19 February 2015 (UTC)

  We could definitely use more speedy deletion templates, but please give them meaningful names, and don't write out numbered criteria in the link labels. These should only be used as link targets and possibly as shorthand template redirects. You'll find plenty of clear opposition to any tendencies towards cryptic number jargon in the archives of this page. {{Copyvio}} is a heck of a lot easier to remember than {{db-f9}}. —LX (talk, contribs) 17:27, 19 February 2015 (UTC)

@LX: There are often several "meaningful" alternative names of speedy deletion criteria (for example, {{Test page}}, {{Accidental creation}}, or {{Nonsense}} instead of {{SDG1}}), but templates can only have one name (but many redirects), and the speedy deletion templates should probably follow a common naming scheme. The "CSD G1" serves as a link to COM:CSD#G1, and I don't see how writing it out can be harmful in any way. In case it has been unclear: I don't want to forbid the "human" usage of {{Speedy}}, and I don't want Commons to adopt something from the English Wikipedia just for the sake of it (IMO "delete because [hyphen] [reason]" is a pretty nonsensical name for a template BTW).    FDMS  4    01:10, 21 February 2015 (UTC)

•  Oppose In any case we should not adapt the numbering system from en.wikipedia. This is Commons. Rehman tried to do this before, a few years ago I guess. --Leyo 23:16, 19 February 2015 (UTC)

@Leyo: , where in the above proposal have I suggested using a numbered system? Rehman 01:16, 20 February 2015 (UTC)

•  Oppose, I think I got the idea of this policy, supported it, and read it several times. Nevertheless I virtually always use {{speedy|prose reason}}, and in doubt I check that I actually matched one or more (typically more) official CSD reasons. Good enough from my POV, no more bureaucracy needed. –Be..anyone (talk) 00:17, 20 February 2015 (UTC)

This has no direct relationship to what template was used to tag for deletion. Rehman 01:16, 20 February 2015 (UTC)

•  Oppose This looks like we're trying to fix what's not broken. The dropdown list we have is fine and doesn't need to be changed. We also have instant delete, delete links, and visual file change with set rationales that would need to be altered to match up with the dropdown list if it was changed, and on all speedy deletion-nominated pages/files you have a little garbage can to click which gives individualized reasons, often the url where the image came from, or things like album cover, screencap, or movie poster (these are blatant copyvios usually uploaded by users who'll never make a good edit or upload a proper image). Also, empty category is very much a needed speedy reason, especially when it's dozens of maintenance cats, many of them tagged by bots with that set rationale, or you've emptied a cat with a mass DR close, etc, etc. INeverCry 00:33, 20 February 2015 (UTC)

  {{Bad name}} documented @COM:REDCAT covers some cases of "empty cat", and {{EmptyCatGood}} protects some cases of "empty cat", are there any unsolved problems with empty categories? –Be..anyone (talk) 00:56, 20 February 2015 (UTC)

  Using an always-changing custom made list, that doesn't match any official deletion policy is not fine. We might as well not even have a CSD policy page since nothing was broken then as well. No offence, but this is an improvement that should be made for the sake of the larger non-admin community. Yes it is easy for us admins to pick an easy entry from the dropdown, but does the log really help the user, other than direct them to a page with a broad description of why we delete stuff, and a whole lot of other gibberish? And to answer your points: The addition content in the log will not be affected as this is only relating to the dropdown field. Empty category can be deleted as "page containing nonsense or no valid content". Rehman 01:16, 20 February 2015 (UTC)

  It's rather hard to find a worse name than {{Bad name}} for a specialised template designed to finish off empty categories after a move. OTOH this is the established name here since 2006, and there is no compelling reason to change it. Maybe put a policy tag on the page containing COM:REDCAT, I quote it more often in CFDs and DRs than all official policies + guidelines together, with the sole exception of COM:INUSE. –Be..anyone (talk) 02:43, 20 February 2015 (UTC)

• I suggest we ping our most prolific deleters who haven't commented, to seek further feedback on this proposal: @Yann: @Krd: @Green Giant: @JuTa: @Ellin Beltz: @Jameslwoodward: @Túrelio: @Denniss: @Natuur12: @Didym: @NahidSultan: @Magog the Ogre: @EugeneZelenko: . --99of9 (talk) 10:30, 21 February 2015 (UTC)

• Why Other reason is not enough? --EugeneZelenko (talk) 15:15, 21 February 2015 (UTC)
•  Oppose This whole page of discussion is confusing, I don't see the need to make any changes. Ellin Beltz (talk) 18:17, 21 February 2015 (UTC)

FWIW my 'support' was a bit in the 'moral support' sense, since this doesn't directly affect me, but I can see the logic of having the logged reasons more directly linked to the actual criteria. This discussion does make it fairly clear that the actual proposal was not clearly defined, and that most admins don't seem to see the need for the change. Revent (talk) 18:51, 21 February 2015 (UTC)

•  Strong oppose to any reason code system or similar. The currently list of deletion reason probably is longer than needed and some redundant reasons could be consolidated, though. --Krd 19:32, 21 February 2015 (UTC)

  This proposal is about shortening the list, and also doesn't involve any code system... :/ Rehman 01:08, 22 February 2015 (UTC)

  If the codes mentioned in the table below will be included neither in the deletion reasons nor in the documentation, I  Support the change. --Krd 07:14, 22 February 2015 (UTC)

Comparison of criteria

I don't think it's possible to have a meaningful discussion regarding this without having a side by side comparison between the current list of reasons for deletion from MediaWiki:Deletereason-dropdown and the criteria for deletion as listed in this policy (Commons:Criteria for speedy deletion)... so I made one. On the left are current reasons, on the right are my effort to distill and adapt the policy headings to something that would be meaningful to readers of the deletion log and to admins trying to pick the right option. The criteria numbers are included for reference only and are not intended to be part of the log entries. For the current list of reasons, I've had a go at indicating the nearest proposed equivalent and others have since modified this in ways I disagree with 10:39, 21 February 2015 (UTC). The sections are in the same order as in this policy, except for the namespaces that don't have sections in the policy, which are at the bottom in their original order.

wikitable

Current Proposed Gallery Empty or single image gallery; please see Commons:Galleries (GA1) GA1 Gallery without media files User intended to create a category but did not use "Category:" as the prefix (GA2) GA2 Mistakenly created gallery – page intended for another namespace Out of project scope -- Commons galleries are for collections of images, articles belong in Wikipedia (GA3) GA3 Misplaced encyclopedic or biographical content – outside of Commons' project scope Out of project scope -- Commons galleries are for collections of images, biographies belong in Wikipedia (GA3) GA4 Promotional content Out of project scope -- Commons galleries are for collections of images, not text (GA3) Category Empty category (G1) C1 Renamed or duplicate category Renamed category (C1) C2 Improperly named category Commons Empty deletion requests log (COM1) COM1 Improperly filled or routinely emptied deletion request or log File Copyright violation; see Commons:Licensing (F1) F1 Apparent copyright violation – see Commons' licensing policy Copyright violation, found elsewhere on the web and unlikely to be own work (F1) F2 Fair use content – not allowed on Commons Fair use material is not permitted on Wikimedia Commons (F2) F3 Derivative work of non-free content – not allowed on Commons Copyright violation, can usually be uploaded to your local Wikipedia as fair use if an article exists (F1) F4 Failed license review Derivative of non-free content (F3) F5 Missing essential information such as source, license or evidence of free licensing or public domain status Mass deletion of copyrighted or other inappropriate content (Fx) - depends on what is being deleted F6 License laundering License review: Non-free license, or license disallowing commercial use and/or derivative works (F4) F7 File description page with no associated media file Permission granted only for one or more Wikimedia projects (F2), (F3), or (F4) F8 Exact or scaled-down duplicate Screenshot of non-free content (F3) F9 The file contained embedded data in the form of a password protected archive OTRS: Unaccepted or insufficient permission for use on Commons (F4) License laundering (F6) Missing essential information such as license, permission or source (F5) File is corrupt, empty, or in a disallowed format (F9), (G1), or (G6) File page with no file uploaded (F7) Exact or scaled-down duplicate (F8) Exact or scaled-down duplicate with non-descripive file name (F8) Uploader requested deletion of a recently uploaded unused file (G7) Template Unused template (T2) T1 Duplicate template Recently-created template that duplicates an existing template (T1) T2 Unused template User User requested deletion in own userspace (U1) U1 User requested deletion of their own user space content Userpage of non-existent user (U2) U2 User page of a non-existent user Inappropriate use of userpages (U3) U3 Inappropriate use of user pages Userpage of indefinitely blocked user (Per...) General Out of project scope (GA3), (GA4), (G1), (G1), or (G3) G1 Test, accidental creation, nonsense or no valid content – use the sandbox to experiment Out of project scope: promotional content (GA3), (GA4), (G1), (G1), or (G3) G2 Unused and implausible, or broken redirects Test page or page with no valid content (G1) G3 Vandalism, threat, or attack Accidental creation (G1) G4 Recreation of previously deleted content without undeletion request Nonsense (G1) G5 Temporary deletion for history cleaning or revision suppression Spam (G1), (G3), or (Per...) G6 Uncontroversial maintenance Vandalism (G3) G7 Author or uploader requested deletion of recent, unused content Unused and implausible, broken, or cross-namespace redirect (G2) G8 Page dependent on deleted or non-existent content Recreation of content deleted per community consensus (G4) G9 Office action by Wikimedia Foundation Staff Improperly named (G6) Temporary deletion for file renaming (G6) Temporary deletion for category renaming (G6) Temporary deletion for history cleaning or revision suppression (G5) Temporary deletion for history merging of different uploads of the same file (G5) Temporary deletion for history splitting of overwritten files (G5) Author requested deletion of page (G7) Page dependent on deleted or non-existent content (G8) Housekeeping or non-controversial cleanup (G6) Redundant or duplicate (C1), (F8), (T1), or (G6) Cross-namespace redirect (G2) Cross-mediatype redirect (G2) Cross-wiki spam (G1), (G3), or (Per...) [Associated namespace] talk Inappropriate use of [associated namespace] talk pages (G1), (G3) Orphaned [associated namespace] talk page (G8) Unneeded [associated namespace] talk redirect (G2) MediaWiki Local value is equal to default value (G1), (G6), or (Per...) Deprecated or non-functional script (G6) or (Per...) TimedText Redundant Timed Text or timed text belonging to a deleted file (G8) Invalid Timed Text (G1), (G6) Timed Text does not match audio content (G1), (G6), or (Per...) Unfree timed text (Per...) - how often do we get these? Creator/Institution Unused and unlikely to be needed Creator/Institution template (T2), (G6) Recently-created Creator/Institution template that duplicates an existing template (T1), (G6) Unused and implausible, Creator/Institution template redirect (G2) Content out of project scope of Creator/Institution templates (G1), (G6), (Per...) }}

—LX (talk, contribs) 20:34, 19 February 2015 (UTC)

Thank you, LX, that's very helpful. I think those who would change the edit comments have lost sight of the audience. These are meant to be read by people who are far less knowledgeable about Commons than we are. Attempting to create a one-to-one correspondence between the rules and the list of comments means that some little used rules will be clutter in the list while frequently used sub-cases of rules will not get good explanations.Take just the top four in the list. I do very few deletions off the {{Speedy}} list, but I do a lot of New Page Patrol, so, I use these a lot. (Each section below has the existing and proposed on successive lines).

Empty or single image gallery; please see Commons:Galleries (GA1)

Gallery without media files

"Empty or single image" is clearer to the novice than "without media files". Do people with EN2 know the word "media"? And, since our rules do not allow single image galleries (with some minor exceptions), the proposed line will lead a novice to object to a deletion of a single image gallery.

User intended to create a category but did not use "Category:" as the prefix (GA2)

Mistakenly created gallery – page intended for another namespace

This is a frequent case -- close to daily. The explicit reason is very clear and, hopefully, will prevent the novice from just creating it again because he doesn't understand what's wrong. "Page intended for another namespace" isn't clear. And, again, will an EN2 understand "namespace" the first time he sees it?

Out of project scope -- Commons galleries are for collections of images, articles belong in Wikipedia (GA3)

Out of project scope -- Commons galleries are for collections of images, biographies belong in Wikipedia (GA3)

Misplaced encyclopedic or biographical content – outside of Commons' project scope

I agree that these two could be combined, but again, how many novices understand "encyclopedic content"? It's far clearer to the novice to say right out that articles and biographies belong in WP.

I could go on similarly for most of the proposed changes, but the point here is that the list of edit comments should match the frequency of specific problems and should be very clear to the novice. Certainly each of the comments must be well grounded in policy, but they must also be as clear as possible to the novice user. I think that the proposed changes will increase the number of questions on my talk page, the number of UnDRs that are not well based, and generally create more confusion rather than less. .     Jim . . . . (Jameslwoodward) (talk to me) 13:52, 21 February 2015 (UTC)

Thanks. I'm sure a lot of the entries on the right could be made easier for beginners to understand; that's mostly my fault. While that's something that would have to be resolved, the main purpose of the comparison is not to focus on the wording, but to look at how the list of reasons differ in terms of coverage.

As I mentioned, my comment was altered, so some of the suggested mappings are not my own. For example, I don't think that "Improperly named" is a "near equivalent" of "Uncontroversial maintenance". That may be the option you'd have to use, but it's obviously not a close match at all. If anything, its closest equivalent is "Improperly named category", which means it is only applicable for deletions in the Category namespace. Is that a change we would like to make? Are there a lot of "Improperly named" deletions in other namespaces? If no, the change might be a good thing (reducing the number of reasons in the general section). If yes, it might not be so good (making the nearest option much less to the point). I think that's an important question to ask: would we be making deletion reasons more generic (like losing the distinction between screenshots of non-free content and other derivatives of non-free content)? —LX (talk, contribs) 10:57, 22 February 2015 (UTC)

I think I missed making an important point above. I see no reason why there needs to be a one-to-one correspondence between the policy list and the list of reasons for deletion. The reasons list should certainly (as I said above) be firmly grounded in policy, but should also reflect the frequency of various types of specific mistakes that bring about {{Speedy}} deletions. Out of scope is only one item in the policy list, but, as I noted above, might have several entries in the reasons list to fully cover the most common reasons that a page is out of scope. Telling the user that empty or single image galleries are OoS is far more helpful than directing him or her to [[COM:SCOPE]. .     Jim . . . . (Jameslwoodward) (talk to me) 16:26, 22 February 2015 (UTC)

G9 is complete nonsense. "Office action" is based on the "Term of Use", it is not a "speedy deletion". Anybody trying a {{speedy|G9}} is confused, either they are entitled to impersonate WMFOffice, and can just do it as designed, or they need several clues. –Be..anyone (talk) 21:24, 23 April 2015 (UTC)

Proposed update

I think this page could really use some examples of which template to use when, like Speedy Delete. I have set up an example of what it would look like at User:ARTEST4ECHO/sandbox2. I am not suggesting Policy changes.

For example F1 would read:

1. Apparent copyright violation.

Content is apparently a copyright violation, with no clear evidence of Commons-compatible licensing being issued by the copyright holder. Repeated uploading of copyright material may lead to the uploading user's account being temporarily or permanently blocked.

• {{Copyvio}}, {{SD|F1}}, {{Speedydelete|[[COM:CSD|F1]]}}

Again, No Policy changes would be made, just adding which template to use when, in order to make it easier to decide which template to use. This is is how Wikipedia:Criteria for speedy deletion does it, and I think it is very helpful. If a consensus in agreement is reached, User:ARTEST4ECHO/sandbox2 is ready to be copied over immediately (unless changes are suggested)--ARTEST4ECHO ^talk 13:33, 23 April 2015 (UTC)

Good idea (except for the bullet and the third method), but not going to happen anytime soon, see the discussion on this page.    FDMS  4    19:50, 23 April 2015 (UTC)

I think the Bullet is necessary. That is how Wikipedia dose it also. I'm not sure what you mean by "the third method". However, I took out that way anyway.--ARTEST4ECHO ^talk

MUST or SHOULD

I've reverted a recent modification.

old

To tag a page for speedy deletion, you may use the template: {{speedydelete|<Reason>}}.

 

If a category or any other kind of page is empty you can use the template {{emptypage}} that's equal to {{speedydelete|It's empty}}.

newer

To tag a page for speedy deletion, you may use {{speedydelete|<reason in prose>}} or the shortcut {{SD|<criterion number, see list>}}.

newest

To tag a page for speedy deletion, you may use {{speedydelete|<reason in prose>}}, optionally linking reasons to the relevant speedy deletion policy sections.

Good riddance for {{Emptypage}}. But for numerical reasons linking is not only OPTIONAL, arguably it's a MUST, or at least a SHOULD. I18n obviously happens at the policy page, as long as folks manage to link to the relevant English sections numerical reasons should work.

How they do this, with a new {{SD|…}} or something in their own script/language, is their own business, and not really relevant in the policy. Maybe somebody wants to expand {{db|…}} inspired by enwiki Template:delete because, fine, as long as text and link are clear. –Be..anyone (talk) 22:25, 23 April 2015 (UTC)

File redirects

This was raised in 2013 (Commons talk:Criteria for speedy deletion/Archive 1#Redirects), but is still causing issues in that redirects are being for nominated for speedy deletion despite not falling under COM:CSD#G2.

I would like to see a criterion added specifically for file redirects. This would state when a file redirect can be deleted speedily (eg file originally uploaded in last 7 days), when its not covered by the general criterion.

Longstanding file redirects should not be deleted, see the previous discussion for rationale where there was consensus for that position. This would make declining these easier, as it gives a simple test for the deleting admin (look at original upload date, if old, decline).--Nilfanion (talk) 10:05, 30 July 2015 (UTC)

GA1

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

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)

 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)

 Strong support. It clearly makes things simpler, and not the contrary. Saves the editor from typing sentences. Rehman 13:22, 4 April 2016 (UTC)

•  Oppose Deletion templates should have readable names, not gibberish codes. --Stefan2 (talk) 19:52, 4 April 2016 (UTC)
•  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)
•  Oppose i see no need. --Steinsplitter (talk) 16:42, 2 December 2016 (UTC)

F9 criteria update

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. Revent^talk 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. Revent^talk 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. Revent^talk 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. Revent^talk 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. Revent^talk 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

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)

@Verdy p, LX, 99of9, Nilfanion, and Closeapple: The C3 criterion is really very inappropriate and damaging. In case of empty categories, an administrator should ever consider why the category is empty and whether the category is promising, useful and meaningful. Generally, the fact that the category is empty (at the moment) should be not the reason itself but only an indication that the category may be unuseful.

Regrettably, the former content of a category cannot be tracked effectively by MediaWiki: it is not easy to discover where disappeared previous files and subcategories from the category.

• an empty category should be deleted if:
  • it was created probably by mistake or as a useless experiment and is quite unusable (falls under COM:CSD#G1); or
  • it was emptied and abandoned, moving the content uncontroversially to some better named duplicate or analogous category (consider to use a soft redirect instead of deletion); or
  • the category name/scope/item is erroneous, unsystematic, ambiguous etc. (consider renaming/moving instead of deletion); or
  • the item of the category doesn't exist or is not probable to have ever some files to the item; or
• an empty category should be kept if:
  • it is correctly named and represents an existing and relevant item which should have some related files on Commons; and/or
  • it is a part of a systematical categorization structure and/or is linked from systematical naviboxes, or linked to/from a meaningful Wikidata item, or linked from some Wikipedia articles and lists etc.; and/or
  • the page contains some useful description, meaningful categorization or additional information which would be lost if the page is deleted and later created again; and/or
  • the existence of the category is a subject of discussion or controversy, or the category is suspected to be emptied inconsensually or rashly; and/or
  • the page has been marked with an explanation of why it should be kept (with some of the previous reason or other relevant reason)
  • the page is a meaningful redirect or disambiguation page

The principles can be shortened and precised, some of the criteria are identical with general or parallel criteria. We can replace the current C3 criterion with more prudent one:

Unuseful empty category

If a category is empty, is not a redirect or disambiguation, is obviously unusable (incorrigibly wrong, unsystematic or unlikely to be ever meaningfully used) and has not been marked with an explanation of why it should be kept, it may be speedily deleted. In other cases, consider to redirect or rename the category rather than delete it.

This proposed wording is a bit overlaping COM:CSD#G1, but as I believe, it can be articulated separately and more sensitively here. --ŠJů (talk) 21:32, 3 September 2018 (UTC)

 Support I recently did have to re-create a ship category which was previously empty (perhaps only a non-free file in there) but had a bunch of info, after I identified an image in the unidentified ships category as being that ship. Would have been nice to simply have the empty category to populate, rather than re-create. Unsure why we delete empty categories which seem perfectly useful, other than having people search on them and then find no images. But not sure that is worth deleting them.

There were some discussions in the past:

Commons_talk:Criteria for speedy deletion/Archive 1#Speedy_categories

Commons_talk:Criteria for speedy deletion/Archive 1#Empty_categories

Commons_talk:Criteria for speedy deletion/Archive 1#RE:_categories_&_redirects

Commons_talk:Criteria for speedy deletion/Archive 1#Criteria_c1

There were many opinions that such categories should not be speedied, but I don't see any real justification for why they should, other than they were in the document from the beginning. @Rehman: , was it common practice before this policy, or is there some discussion of justification that I'm missing? Carl Lindberg (talk) 02:21, 4 September 2018 (UTC)

Hello Carl Lindberg. Replying from work, hence only read your question above. Yes, it was a common practice before the policy was written. You can also verify that by visiting MediaWiki:Deletereason-dropdown, where you can see that the empty category delete reason was existing during periods before the CSD was written. Best regards, Rehman 05:07, 4 September 2018 (UTC)

OK, yes, looks like it was added in this commit in 2008 without much debate, and it has stuck since. Carl Lindberg (talk) 05:26, 4 September 2018 (UTC)

It was added without controversy as it had been already been official policy for years. Speedy deletion of empty categories was added in 15 November 2004 as the second edit to Commons:Deletion policy as part of the original drafting of the Commons deletion policy (which was created about a month after the launch of Commons). —RP88 (talk) 06:57, 4 September 2018 (UTC)

Oops, ignore that, that policy was about blank, or almost blank, category pages as opposed to empty categories. —RP88 (talk) 07:15, 4 September 2018 (UTC)

 Support This wording seems sensible to me. --99of9 (talk) 02:56, 4 September 2018 (UTC)

I announced this proposal at Commons:Village pump/Proposals#Empty categories before its implementation to the policy page. --ŠJů (talk) 15:02, 8 September 2018 (UTC)

 Comment I honestly believe we should just get rid of this criterion at this point. The new criterion is so narrow, convoluted, and open to interpretation that admins will have a hard time to judge whether a category falls under that criterion, especially since they'd have to know the categorization standards of that particular sub-tree. Redirects don't hurt and we already have G1 and C2 for cases of obvious errors. In other cases, let's just have a DR. Sebari – aka Srittau (talk) 15:35, 8 September 2018 (UTC)

@Srittau: As I think, the proposed wording is "convoluted and open to interpretation" in similar way as all other criteria which require discernment of the admin. The main problem with the current wording is that some admins delete empty categories mechanically, regardless of common sense, without an attempt to have a think about it. The proposed wording has really an overlap with G1, C2 or others, but as i believe, they are some types of situations which fall not under G1 nor C2 but can be sensibly decided and resolved. The main problem of DRs is that they are very slow and inflexible. Most of requests stay unresolved for months or years. Categorization is a living system, such a freezing disrupt it. --ŠJů (talk) 08:47, 9 September 2018 (UTC)

I implemented the proposal to the text. Feel free to correct stylistics if needed. --ŠJů (talk) 15:53, 9 September 2018 (UTC)

Resolved

Photos of children with geolocation

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)

Yes, if there is a geolocation problem, that can be stripped out rather than being fully deleted. But as mentioned, most such files would fail COM:SCOPE in the first place, of which COM:SELFIE is a part, which would be the real deletion reason (even if not speedy). I can't imagine there would be any real opposition to stripping the geolocation if somehow the file was in scope. Carl Lindberg (talk) 16:30, 21 January 2018 (UTC)

Corrupt files

I think there should be a speedy deletion criterion for corrupt files, as there is at enwiki. The same can also be done for missing or empty files for the same reason. Corrupt/missing/empty files have no use whatsoever and must be removed as you may have done on your computer. LaundryPizza03 (talk) 04:00, 17 January 2018 (UTC)

Hi. Yes, I agree we need some sort of criteria for irrecoverable corrupt files... You might be interested in this past thread. Cheers, Rehman 05:49, 17 January 2018 (UTC)

Why can't they go to regular Commons:Deletion requests? Are these issues really so frequent that they would clog up the deletion request queue? As for each issue:

• Many users are not qualified to declare what constitutes a "corrupt" file without a discussion. Commons has had many files in the past that someone reported as broken, and it turned out they were not broken: Either the user's browser was behaving strangely, or the thumbnail was cached badly, or the MediaWiki software just generated an incomplete or broken thumbnail (which means that other users will say it's "broken" also without trying to figure out why). Images with print-ready CMYK color mapping instead of RGB color mapping sometimes get nominated for deletion because they are showing stripes or weird colors on Commons, but the weird effect is a MediaWiki thumbnail/resizing problem, and the uploaded file itself is correct; many of those CMYK files are the kind of high-resolution, high-quality photographs we want the most on Commons, and many image-conversion programs will produce an RGB derivative image suitable for wiki use.
• We already have criteria F7 for empty files. (However, zero-length files or descriptions without uploads happen occasionally when an upload tool fails: Usually the file is uploaded properly soon after. And rarely, someone uses a batch upload tool that creates description pages en masse, then uploads the files afterwards. If it's been more than an hour or two since the page was created, and there is no file, that probably indicates that it has been abandoned, though.) --Closeapple (talk) 06:56, 17 January 2018 (UTC)

Yes, contrary to my initial reply, Closeapple's comment makes total sense. A criteria will be useful only if it could be proven that we have such deletions more frequently. Rehman 09:50, 19 January 2018 (UTC)

G8

Due to Commons:Deletion requests/File:Rachel Kushner 2015 01.jpg (hist • logs • abuse log) I’d clarify that this criterion can’t be applied when an external resource certainly existed once in the past, but no more. May an anonymous Google Inc. employee force a Commons image under speedy deletion? Moreover, under very creative interpretation much of media here and here can be subjected to speedy due to on-the-ground “deletion” by ISIL and Islamic Emirate of Afghanistan, respectively. Incnis Mrsi (talk) 17:18, 8 March 2018 (UTC)

You are correct. I've added clarification on this. Rehman 02:42, 9 March 2018 (UTC)

Crossnamespace redirects

I notice cross-namespace redirects are specified for speedy deletion, yet we have had a guideline specifically allowing them since 2009 until now [1], but the guideline has never been revoked by consensus discussion. The discussion creating the guideline showed consensus for allowing them at the time. I'd like to request a link to the discussion which resulted in this policy being adopted, so I can understand better why this discrepancy arose. --Robert.Allen (talk) 21:53, 1 May 2018 (UTC)

Agreed, redirects from galleries to categories were allowed. I think the policy here was for other, nonsensical cross-namespace redirects and was not meant to overrule that other policy. Commons talk:Criteria for speedy deletion/Archive 1#Redirects, and some other sections there, mentions that. I think the change to Commons:Galleries should be reverted. That represents a change to long-standing practice -- rather, this policy should mention that practice (much like the en-wiki R2 criteria does). Carl Lindberg (talk) 01:26, 2 May 2018 (UTC)

The current practice is in line with the deletion policy, that is, many administrators will speedy delete these cross namespace redirects. A redirect from a non existing gallery to a category makes no sense. A link to a gallery should be red if there is no gallery. If you want to link to the category, just link to the category. Jcb (talk) 15:16, 2 May 2018 (UTC)

I don't think it is a good idea to delete these redirects, since more than just being harmless, they can be useful and do make sense. Converting them from a blue link that is useful to readers to a red link that is not useful is not an improvement. In the file descriptions, we often have links to the author or other names mentioned there, because not every reader will know to look at the list of categories at the bottom of the page. Plus it can put the link into a context which tells the reader why the name is of interest. It simplifies the links in the description if the category namespace does not have to be added as a prefix in a piped link. If in the future someone updates the redirect to a gallery page, it is linked automatically. In the past, another advantage was that the name would show up in the search field dropdown without the user having to append the Category prefix and/or execute the search (although it does seem the drop down has been improved, so this is no longer the case). --Robert.Allen (talk) 16:17, 2 May 2018 (UTC)

The exception allowing for gallery -> category predates this policy page. There is good reason for it to be grandfathered in, as Category-space is effectively Commons mainspace. Incoming links from other projects will be a major source of these links to these redirects. Those will not show them as a redlink, inviting a fix by an editor. Without a fix that no-one knows to make, any reader following the link gets dumped onto a non-page on Commons. A cross-space redirect to the relevant category is a better outcome. This particular exception should be included into CSD policy to stop trigger-happy admins.--Nilfanion (talk) 17:56, 2 May 2018 (UTC)

It has always been OK to replace simple galleries with redirects to the associated category if the gallery added nothing over the category (i.e. had all images in the category, with no captions, etc.). The galleries are often the incoming links from Wikipedia pages and the like. Deleting those redirects can break the links on Wikipedia articles and similar. If someone wants to work on a better gallery, they can replace the redirect. That was the policy agreed to in 2009 and has not changed since, as far as I know. This page failed to mention the exception, but that is the problem which should be fixed. Even en-wiki (where a lot of this policy was drawn from) allows redirects from main space to certain other namespaces. It makes sense for us too. Carl Lindberg (talk) 06:30, 3 May 2018 (UTC)

Till now only a guideline was cited in favor of accepting these redirects, while the official policy does not. If Wikipedia wrongly links to galleries, these links should be fixed instead. This argument is moot anyway since we have Wikidata, which shows a link to the category at Commons when it exists. Jcb (talk) 14:36, 3 May 2018 (UTC)

Proposal to modify the criteria for "Unused and implausible, or broken redirect"

In view of the comments above, I propose we add the following exception to item 2 of General reasons:

However, a gallery title can be redirected to a corresponding category and such cross-namespace redirects are not subject to speedy deletion.

--Robert.Allen (talk) 17:21, 3 May 2018 (UTC)

• No, of course no. No reason to bring back workarounds from our ancestors that make no sense anymore. If we would have wanted such a redirect for every category, we could have requested a software change to redirect all non-existing gallery pages to a category. If a Wikipedia article links to a non-existing gallery page, fix that link instead. Jcb (talk) 17:59, 3 May 2018 (UTC)

User:Jcb, I actually like your suggestion to request a software change to redirect all non-existing gallery pages to a corresponding category [if one exists]. If you were to propose it, I would support it. --Robert.Allen (talk) 03:44, 7 May 2018 (UTC)

•  Support I don't think they harm anything, and can help. Additionally, "fixing" them means editing other projects, rather than preserving existing functionality here -- the deletions can then break other projects through no fault of their own. Part of the idea of the redirects was so that a better gallery could be created in the future without having to change the Commons links on articles in other projects. For Commons, galleries and categories are more similar in purpose than any other project, and so the cross-namespace redirect makes more sense here. Furthermore, this has been standard practice for a long time, and to me there should instead be a consensus to change the other way. But affirming it here would not hurt. Carl Lindberg (talk) 01:49, 4 May 2018 (UTC)

You are wrong on several points. "For Commons, galleries and categories are more similar in purpose than any other project" is not true of course, which you, as a long term user, are expected to know. Then, the "this has been standard practice for a long time" part is also opposite to reallity. I often come accross situation where one user keeps recreating the same cross namespace redirect, while it has been speedy deleted already by several different admins, sometimes even 4 or 5 different admins for the same page. The long standing practice is that those links get deleted, where only a handful of users seems to have the counterproductive hobby to create them. The current, long standing practice is in line with the deletion policy and this reason for speedy deletion is already one of the standard reasons in the deletion interface for over 7 years. Jcb (talk) 08:23, 4 May 2018 (UTC)

Well, the above policy was made without any consensus to overturn the previous consensus to allow them -- this point was made as part of a large policy page which was overall very good, but missed discussing that point in particular to my mind, meaning that was an omission here in the first place (which admins, no doubt, have then followed). So the claim that this policy, by way of being a policy but without any specific overriding of the previously-existing consensus, should overturn that consensus purely because it was labeled policy (and not because there was a discussion about it showing a new consensus), is a bit specious. Secondly, this vote then is about changing the policy in question, so the argument that it shouldn't be changed because that's the way it is now doesn't work either. I don't see much of a problem with those particular links, so I don't see the need to speedy delete them, and am in favor of the proposed exception to the speedy delete policy. Perhaps the original 2009 discussion was ingrained more in my mind, but I don't see where that consensus was ever overturned, other than by back door here. Carl Lindberg (talk) 02:22, 5 May 2018 (UTC)

A broader discussion will be needed, long standing standard practice is not going to be changed by a short talkpage chat like this. Jcb (talk) 06:33, 5 May 2018 (UTC)

•  Support Especially when these were accepted prior to CSD being written; and that was because of the perceived benefits already described. More practically why delete them? What actual benefit is there? Jcb, please demonstrate the benefit of not adding the exception, or the harm of having these redirects. The fact there have been creation/deletion cycles is evidence that this exception would be useful - it would save unproductive time. If editors want to create them, why stop them?--Nilfanion (talk) 05:02, 5 May 2018 (UTC)

The assumed benefits are basically outdated by changes in the software since. Wikipedia articles link to categories via de Wikidata links in the left menu. For navigation purposes the gallery namespace is not needed and not meant. And "the fact there have been creation/deletion cycles is evidence that this exception would be useful" is a nonsensical argument of course. Jcb (talk) 06:24, 5 May 2018 (UTC)

Nope. The most prominent links to Commons are not the Wikidata-powered links in the sidebar. They are the links provided to sister projects in the body of the article, usually via template links near the end. Those links do not use the wikidata information, and while they could be improved are likely to dump readers into gallery space instead of taking them to a useful category. More to the point, this is not about mass creation of these redirects. Its about removal of them from the speedy deletion criteria, which in turn authorises mass deletion of long-standing links. They shouldn't be deleted unless their need has been negated, in practice not in theory only.--Nilfanion (talk) 13:16, 5 May 2018 (UTC)

• Oppose. I understand Robert's good intentions, but I strongly share Jcb's concerns that allowing mass gallery-to-category redirects is primitive and creates a larger (and more complicated) mess in the long run. If we really need something of that nature, we might as well get the software modified. Galleries and Categories are two entirely separate namespaces; we shouldn't treat it as opposite sides of the same coin. Rehman 07:44, 5 May 2018 (UTC)

User:Rehman, This could be about grandfathering and protecting the small number of existing redirects. Speedy deleting them breaks blue links which are not being repaired. Or, if the existing blue links were modified to link to the categories before the redirects were deleted, I would have much less problem with deleting the redirects. Also, instead of simply deleting the old guideline [2], perhaps the guideline could mention that such redirects were formerly allowed, but have been deprecated due to changes to Wikimedia software. After all, the guideline has been there since at least 2009. --Robert.Allen (talk) 14:10, 5 May 2018 (UTC)

For instance, the modification could read something like this: "Existing redirects of gallery titles to corresponding categories are not subject to deletion until all incoming links have been modified to link to the target category." --Robert.Allen (talk) 14:42, 5 May 2018 (UTC)

User:Rehman, this does not have to be about creating lots of redirects where they don't exist -- just not deleting the ones which have been there a while. For many topics, say France or Marseille, we have a curated gallery which is a much better introduction to a topic than a category. For those, the links from the Wikipedia articles are best sent to the galleries, not the category. The fact that Wikidata can't do that is a technical limitation and means that Wikidata is not as functional as it could be. There are times in the past where the category became better than the gallery, and so the gallery was turned into a redirect. We should *not* be breaking links in other projects and then tell them to go fix them, when they were not broken to begin with -- we should be supporting what the other projects have. The policy could simply be that creating new redirects is discouraged, but redirects should not be speedy deleted if they have existed over X amount of time, or were previously a legitimate gallery, or have existing links from other projects. I don't have an issue speedy-deleting a newly-created redirect which was never a gallery and does not have links from other projects. Carl Lindberg (talk) 14:50, 5 May 2018 (UTC)

Hello Robert and Carl. Thanks for the descriptive response. Yes you are correct; my oppose is only for creation of new redirects, and not supporting the deletion of existing/old ones that were once a valid gallery. Your suggestions to amend the text in existing policy/ies to reflect this view makes sense.

Separately (i.e. no impact to this discussion), I will try and see if we could get a bot to do a scan, to figure out how many gallery-to-category redirects are in existence. Just to get an overview of scale of the situation. At the same time, it may also be helpful to keep an eye on Commons:Structured data, which may or may not impact gallery/category relationships.

Furthermore, with regards to Wikidata not being able to link to Galleries, it can be done :) The gallery page should be entered on the right panel instead of in statement format (in this example, a gallery could be linked by replacing the category link added in the sidepanel). Best regards, Rehman 04:22, 7 May 2018 (UTC)

Gallery DAB pages

Jcb (talk · contribs) has deleted some gallery DAB pages, with the reason of being "single image or empty", they then said that they don't belong in the gallery namespace, I don't see why not, isn't that just like how DAB pages work on WP. Note that on WP, w:WP:A1/w:WP:A10 doesn't apple to DAB pages. Crouch, Swale (talk) 10:50, 4 May 2018 (UTC)

It is indeed how it works on Wikipedia, but you are here on Commons, not Wikipedia. Note that a recent UDR for such a DAB in wrong namespace was closed as 'not done'. Jcb (talk) 10:54, 4 May 2018 (UTC)

Where is that request, and how do we get people to the galleries, what should be at Columbus, should it redirect to Christopher Columbus or Columbus, Ohio then? Crouch, Swale (talk) 12:33, 4 May 2018 (UTC)

That request is here. There is no need for Columbus to be a blue link. The DAB is where it should be: Category:Columbus. Jcb (talk) 12:38, 4 May 2018 (UTC)

Then how do we DAB the galleries, I can't see why there shouldn't also be a DAB in the gallery space, just like at WP, the DAB at Category:Columbus (which I created) is for the categories. Crouch, Swale (talk) 12:43, 4 May 2018 (UTC)

We do not DAB the galleries. Galleries are there to help presenting the files we have on a specific theme. They are not there for naviation purposes. Christopher Columbus can be reached from Category:Christopher Columbus. At en:Christopher Columbus in the left menu there is a link to Category:Christopher Columbus in the 'in other projects' section. Jcb (talk) 14:34, 4 May 2018 (UTC)

How else do we index them then? Wikipedia has a DAB at w:Columbus and at w:Category:Columbus. I think that we need to review how we deal with categories and mainspace DABs, that is do we include links to categories on mainspace DABs. Crouch, Swale (talk) 06:40, 6 May 2018 (UTC)

Commons does not have 'mainspace' like Wikipedia. They namespace without prefix is gallery namespace. Jcb (talk) 10:37, 6 May 2018 (UTC)

If there are several disambiguated galleries a DAB mage must exist under the unqualified name, otherwise they can't be found under the basic name and will create disputes over which one to have under the unqualified name, Mercury for example. Which one should be there? Crouch, Swale (talk) 08:07, 18 June 2018 (UTC)

Gallery pages are found from the category. Navigation goes via categories at Wikimedia Commons. Jcb (talk) 14:40, 18 June 2018 (UTC)

And there are sometimes multiple galleries that require disambiguation, Jcb would you please revert all of your deletion of galleries that disambiguate galleries. Crouch, Swale (talk) 09:28, 14 July 2018 (UTC)

No, of course not! Disambiguation goes in Category namespace at Commons, not in Gallery namespace! Jcb (talk) 07:28, 15 July 2018 (UTC)

@Jcb: Of course yes, if there are multiple galleries that use that term then one has to exist, please read w:WP:D. You shouldn't have unilaterally deleted hundreds of functioning DABs that were sometimes a decade or more old. Crouch, Swale (talk) 11:46, 1 September 2018 (UTC)

This is not Wikipedia, you are here at Wikimedia Commons, which is different from Wikipedia and has different means of navigation. Jcb (talk) 19:57, 1 September 2018 (UTC)

The navigation applies both with galleries and categories, same as WP. Crouch, Swale (talk) 12:04, 4 September 2018 (UTC)

Several proposals for changes

I have made several proposals for changes (mainly additions) to the criteria at Commons:Village Pump/Proposals. Please have a look. Sebari – aka Srittau (talk) 21:23, 22 July 2018 (UTC)

Nominated by mistake -- File:WMMS-HD2 PSD display.jpg

I recently uploaded a file which qualifies for speedy deletion under GSD#7. I mistakenly nominated that file for a regular deletion, however. I withdrew the regular deletion and placed the speedy deletion request: both tags are now listed. Please revert if appropriate. I apologize for any inconvenience. Also please note this related topic: Commons_talk:Deletion_requests#Nominated_by_mistake. Levdr1lp / talk 12:02, 25 August 2018 (UTC)

Please disregard. File has already been deleted. Levdr1lp / talk 12:06, 25 August 2018 (UTC)

Proposal F11 : Unusued or Low quality explicit image(s).

Commons main objective is as a media to support educational or academic content. Commons is NOT a host for porn.

Therefore, I feel there should be a CSD for unused 'explicit' images, which would also encompass COM:NOPENIS deletions. ShakespeareFan00 (talk) 19:15, 11 March 2019 (UTC)

This was literally shut down at the proposals village down a month ago, in fact Wikimedia Commons has a shortage of many explicit images because of this cavalier mentality. I am not saying that we should be a porn site, but we shouldn't be overly exclusive with nudity for arbitrary reasons. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:24, 11 March 2019 (UTC)

Do you have a link to the archived discussion? I would rather that Commons as a community voluntarily implements an appropriately proactive policy on 'explicit' images, as opposed to being forced into implementing unreasonable retroactive censorship by external interests (such as the authorities in the UK, and certain third party charitable organisations) which would disrupt the ability of commons to meet it's objective of supporting academic, education or cultural content. As you may have heard, the UK is going to start enforcing in law a provision that requires UK based sites with 'explicit' content (which is otherwise legal) to carry out mandatory age verification (The law is intended to force UK based porn sites to ensure that they don't have under-age viewers). Commons is not UK based of course, but the UK is also considering blocking 'explict content' on foreign sites that don't age check. As "blocking" would be unreasonably disruptive applied against Wikimedia Commons (And doubts remain as to the technical feasibility of blocking specfic content), a tighter regime about explicit images with respect to application of genuine educational,academic or cultural scope on Commons would be appreciated. This is why a new CSD was proposed. ShakespeareFan00 (talk) 19:36, 11 March 2019 (UTC)

Please see "Commons:Village pump/Proposals/Archive/2018/12#Exhibitionist uploads" and yes, the images stored here are stored for educational value but child pornography has never been allowed on Wikimedia Commons and the mere suspicion of it has gotten many images deleted in the past. Please also see "COM:OMGAPENIS" and as Wikimedia Commons is hosted in the United States of America so uploaders from outside the United Kingdom don't have to obey British laws. Plus nudity and pornography are illegal in many countries already and that didn't affect the content of Wikimedia Commons in the past so why would it affect the website now? Also just because an image contains nudity doesn't mean that it is automatically less educational than an image which doesn't depict any nude scenes or pornography. I do not want to scare away third (3rd) party donors either but a mass censorship campaign will hurt the website, not help it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:47, 11 March 2019 (UTC)

The issue isn't just nudity, as I have said elsewhere. ShakespeareFan00 (talk) 23:55, 11 March 2019 (UTC)

Bulk category deletions under C3, for "<place> by <year>" categories?

A while back, I needed to categorise a number of photos of British regions in the 1960s. Accordingly I set up a number of the categories Category:1969 in Lancashire (Furness) etc. The main reason for doing this was to have Category:1967 in Lancashire (Furness), so that any images of Donald Campbell's fatal speed record would go into the correct county. As I did not at that point know just what the distribution of such images would be, I set up a number of them, before I placed the content into them.

A number of these have now been deleted by JuTa under COM:CSD#C3. No discussion, no use of warning labels beforehand, simply immediate deletion.

1. Category:1968 in Westmorland
2. Category:1968 in Cumberland
3. Category:1967 in Lancashire (Furness)
4. Category:1966 in Westmorland
5. Category:1966 in Lancashire (Furness)
6. Category:1965 in Westmorland
7. Category:1965 in Lancashire (Furness)
8. Category:1965 in Cumberland
9. Category:1964 in Westmorland
10. Category:1964 in Lancashire (Furness)
11. Category:1964 in Cumberland
12. Category:1963 in Westmorland
13. Category:1963 in Cumberland
14. Category:1960 in Westmorland
15. Category:1960 in Lancashire (Furness)

As all admins are surely aware, CSD#C3 begins, If a category is empty and is obviously unusable, unlikely to be ever meaningfully used, it may be speedily deleted. So why are these structural categories, which form an obvious and well-defined purpose, up for CSD at all? Let alone doing so (against the rest of C3) without any attempt at discussion?

This is just yet another example of admin muda: useless, indeed negative, make-work to play at "serious admin business" whilst actually being the opposite of useful and deliberately irritating to other editors.

Is this a valid use of C3? It already seems clear enough that it isn't. Andy Dingley (talk) 10:36, 20 March 2019 (UTC)

I regularly work on User:Achim55/Unused categories which lists categories that are empty for more than 9 months. I think thats enough time to to assume there will be no meaningfull content within the next time. If not they are easily recreated or restored if you give me a call on my talk page. regards --JuTa 16:33, 20 March 2019 (UTC)

PS: You could prevent such deleteion if you put {{Prospective category}} to the category description pages. regards --JuTa 16:39, 20 March 2019 (UTC)

@JuTa: Be aware that C3 recently changed -- it is now empty categories *unlikely to be ever meaningfully used*, not strictly empty for any reason. I'm not sure these qualify per that wording, so don't think they are speedyable under the new standard. We probably do need a way to mark ones deemed reasonably likely to be used eventually so they don't end up in maintenance lists -- is the prospective category tag enough for that? If so, perhaps just adding that would be preferable to deletion. Carl Lindberg (talk) 17:58, 20 March 2019 (UTC)

Thx, Carl Lindberg I realy didnt noticed that change. Well, over the years I likely deleted several 10000s of empty cats that way. I rearly got complaints or restore requests and they didnt got recreated rarely. So about +95% (guessed) of the deletions were sensefull, because they still empty. If you have a look into old Versions of Achims page like this (Feb 2019), this (Aug 2018), this (Mar 2018), this (Mar 2017) or this (Mar 2016) you see that most of the links are still red. In my eyes permanetly empty categories do disturb the readers of commons by filling up (senslessly) i.e. internal and external search results or via templates i.e. on top of year in ... cats like Category:1989 in Tibet the 1982 cat here is shown as red link and evrybody knows its non-existant, But if its created before there is any content for it and shown as blue link, readers will click on it in the hope to find images and get disappointed to see its empty. PS: Pinging Andy Dingley for his interest. --JuTa 18:38, 20 March 2019 (UTC)

There was a period of six weeks (since these were created) when C3 supported deletion of everything empty. Before that it didn't even exist. Andy Dingley (talk) 18:47, 20 March 2019 (UTC)

I thought the empty category criteria had been there since 2008, per the archived discussion. It had been pretty common to speedy delete for that reason. Needed categories can just be re-created, no problem -- the bigger issue was when there was content in the deleted category, even if just several different parent categories, which would be more annoying to re-create. Carl Lindberg (talk) 22:21, 20 March 2019 (UTC)

That was G1. Which used to get used as an excuse to delete categories. But there was no C3. Andy Dingley (talk) 22:46, 20 March 2019 (UTC)

Ah, OK. But there was a bullet point which mentioned G1 applied to empty categories since January 2018. And it had been pretty common practice before that. Carl Lindberg (talk) 23:42, 20 March 2019 (UTC)

Or in the current example of Andy in Category:1961 in Lancashire (Furness) people would klick on the 1960, 1964, 1965, 1966 and 1967 cats (which I've deleted) to find more suitable images for their purpose and see all of them are empty and might have given up before they klick on the 1969 cat where there is realy an image. Now they easily can identify where to find content and where not. regards --JuTa 18:54, 20 March 2019 (UTC)

There is generally an image count listed in the parent cat before you click -- if you were coming from Category:Lancashire (Furness) in the 1960s you would see the cats were empty. The index is a bit more problematic, to be sure. At any rate, nothing prevents them from being nominated for regular deletion -- that way someone could argue for keeping them, at least. It's just the no-discussion speedy deletion which can be an issue. Carl Lindberg (talk) 22:21, 20 March 2019 (UTC)

• So you assume that readers looking for "anything from the 1960s" will only search a fixed number of categories before giving up? Rather than looking at those which meet their needs. Positively psychic. Andy Dingley (talk) 22:49, 20 March 2019 (UTC)

@Carl thats only the case if people using the parent-category link and not the template links at top of the page.

@JuTa: Sure, but that navbox is not the only way categories are used. I suppose it's more common with these "by year" categories, but that does not apply to all categories. And maybe it's possible to modify {{Decade years navbox}} to use the PAGESINCATEGORY magic word to change the color of those links to gray or something. Carl Lindberg (talk) 15:39, 21 March 2019 (UTC)

@Andy, I dont know when people giving up to search further images when they find only empty categories. Some might give up after the first false positive hit, mome after the fifth some never. But its not hard (for me) to imagine the frustration while searching for images and (only) hitting empty cats. regards. --JuTa 07:50, 21 March 2019 (UTC)

How to appeal an invalid CSD Nomination.

File:The Know Show - Bob Novella with LARP prop.jpg has been nominated for Speedy Deletion, with the claim that it is a screen shot. But it is not a screen shot - the user took the photo himself on his phone. So the CSD notice is not valid at all. The CSD notice says that the only way to appeal is to replace the CSD tag with "a regular deletion request". But there is nothing about how to keep the file, and not delete it. --Gronk Oz (talk) 15:10, 28 April 2019 (UTC)

@Gronk Oz: Only Administrators are allowed to just remove a CSD tag, except in cases of clear vandalism.   — Jeff G. ツ _{please ping or talk to me} 17:42, 28 April 2019 (UTC)

@Jeff G.: thanks for the quick reply. What is the process to request an Admin to do that?--Gronk Oz (talk) 00:48, 29 April 2019 (UTC)

@Gronk Oz: In this case, there is already a DR where you can !vote {{Vk}}. In another similar situation, you could post on the page's associated talk page, but that might not be noticed, or you could also post on the user talk page of an Admin who has helped you in the past, or you could post to one of our noticeboards like COM:AN. See also COM:DP.   — Jeff G. ツ _{please ping or talk to me} 01:18, 29 April 2019 (UTC)

@Jeff G.: thanks.--Gronk Oz (talk) 01:47, 29 April 2019 (UTC)

@Gronk Oz: You're welcome.   — Jeff G. ツ _{please ping or talk to me} 01:50, 29 April 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.   — Jeff G. ツ _{please ping or talk to me} 02:50, 25 May 2019 (UTC)

Proposal: Blatant copyright violations outside of filespace

1. I think there should be a speedy deletion criterion for blatant copyright violations outside of filespace (i.e. text copyvios), for although they do not happen often, they can be just as serious as file copyvios, and deletion is likely to be uncontroversial in such cases.
2. Perhaps clarify that speedy deletion criterion F1 (for copyright violations in filespace) should be used only for "unambiguous" cases, i.e. where a file is an obvious copyright violation. –LaundryPizza03 (dc̄) 02:43, 15 May 2019 (UTC)

Indeed it would be more sensible to separate text copyvio (say, G11) from more ubiquitous F1–F6 (file copyvio). Imagine: someone uploaded a new free file, but stuffed {{Information}} with copy-and-paste from a copyrighted document. Then the copyrighted stuff on the namespace-6 page can be blanked and revision deleted under G11, but the file may remain intact. Incnis Mrsi (talk) 04:24, 15 May 2019 (UTC)

Clarification for G7 (deletion requested by uploader)

Commons:Criteria for speedy deletion#G7:

Old and proposed text:

−

Original author or uploader requests deletion of recently created (<7 days) unused content. For author/uploader requests for deletion of content that is older a deletion request should be filed instead.

+

Original author or uploader requests deletion of recently created (<7 days) content that is unused at the moment the request is made. For author/uploader requests for deletion of content that is older a deletion request should be filed instead.

Yes, this clarification appears to be needed to stop random editors from being able to sabotage G7 requests. - Alexis Jazz ^{ping plz} 22:44, 18 October 2019 (UTC)

•  Support - Alexis Jazz ^{ping plz} 22:44, 18 October 2019 (UTC)
•  Neutral Looks like there is more to it than I thought. My vote is nuetral for now. Masum Reza^📞 23:53, 18 October 2019 (UTC)
•  Oppose Overly bureaucratic for what affects only a very low number of files. A regular DR is always the safer option anyway. Sebari – aka Srittau (talk) 20:52, 19 October 2019 (UTC)
•  Support, makes sense as an anti-sabotage measure.   — Jeff G. ツ _{please ping or talk to me} 02:05, 23 August 2020 (UTC)

Clarification for G7: discussion

Why this proposal feels so dramatic to me for some reason? And why it is here of all places? Amendment requests should be proposed on relevant talk pages which in this case is Commons_talk:Criteria_for_speedy_deletion. Masum Reza^📞 23:07, 18 October 2019 (UTC)

@Masumrezarock100: It's a policy page, and the change is more than fixing a spelling error. But I suppose the request could be here as well. - Alexis Jazz ^{ping plz} 23:35, 18 October 2019 (UTC)

Not sure this really helps with sabotage. Wouldn't users just make sure to go around and remove usages right before they make the request instead of after? Carl Lindberg (talk) 23:59, 18 October 2019 (UTC)

This seems like a lot of extra legwork that you are putting on reviewing admins. Not necessarily saying that is a bad thing but you are saying that admins now have to look at every single use and determine when the image was put on that page, not necessarily an easy task if it is a more edited article. If something is reasonably in use I'm of the mind that G7 never applies. Period. Doesn't matter if it is within the seven days or not. Provided the copyright is fine it was released under an irrevocable license. I'm all for common courtesy and deleting things that people reasonably ask to be deleted but if it is properly in use on an article deleting it is a detriment to the projects and to those we serve. --Majora (talk) 00:02, 19 October 2019 (UTC)

@Majora: Well not quite but kinda yes maybe but not like that. G7 shouldn't be refused because someone added the file to an article after the request. I don't mind if the onus is on the uploader or any other user to prove that. But if someone points out the file was added to an article after the request, G7 shouldn't be refused, like Christian Ferrer and Taivo did. (I pinged Taivo after that comment, he still didn't honor the G7)

The wording could be changed to "content that is unused or proven to have been unused at the moment the request is made", would that help? - Alexis Jazz ^{ping plz} 01:22, 19 October 2019 (UTC)

I think we have opposing views on this matter. I follow more closely with the ideas stated in COM:NOTUSED. If something is reasonably in use (keyword there) then we should air far more on the side of keeping the image. Imagine if the image is of something rare, something we don't have any other illustrative material for. You would still deprive our users of that image simply because someone changed their mind? That is an extreme example, sure, but the idea that we should delete something, or not, just because of the timing of when it was placed in an article seems a little extreme as well. Admins were given the mop because of the community's trust that they will make good judgement calls. Forcing the deleting of something that is legitimately in use simply because of an arbitrary time frame stated in G7 is, again, a detriment to those we serve. --Majora (talk) 01:37, 19 October 2019 (UTC)

Hmm, you have a point. Pictures of rare things should not be deleted just because the uploader requests deletion. A DR would be a better choice. But if the image in question is of low resolution, blurry or better images are available, G7 request should be honored in my opinion. Masum Reza^📞 01:50, 19 October 2019 (UTC)

Bad quality photos would not be able to be reasonably used. Again, the keyword here is if the image is reasonably in use on a project. That word allows for admin discretion which is the whole point of having human admins. If we want to talk about changing the wording of G7 we should change it to allow for more admin discretion (codify the word "reasonable" into the wording). --Majora (talk) 01:52, 19 October 2019 (UTC)

@Majora: I don't know if our views differ all that much. Yes, of course it is always a shame to lose a valuable image. But the issue is more complicated than that. Imagine we refuse to delete Commons:Deletion requests/File:SharafkhanehPort00007.jpg because that swwiki editor added it to an article, knowing full well it could be deleted shortly. Awesome, we get to keep an image that's certainly useful and in scope! But.. I don't think we should expect any more contributions from this photographer ever again, if we punish mistakes like that. And also.. we'd be hosting an image that quite possibly isn't actually free. Clicking "continue" in UploadWizard is hardly a binding contract in many countries. If someone actively tries to get their uploaded file(s) deleted shortly after upload, the license is probably not enforceable. A re-user who grabbed that file in good faith and never looked back before the uploader tried to get it deleted wouldn't be liable, but also likely wouldn't be allowed to continue distributing the file with that free license once they are notified.

Hewhoreleaseshisworkunderafreelicensesayswhat? - What? - GOTCHA! - Alexis Jazz ^{ping plz} 02:14, 19 October 2019 (UTC)

• @Alexis Jazz, Clindberg, and Majora: Should we add the following text to G7? (make it more like en-wiki criteria) If the sole author blanks a newly created page other than a userspace page, a category page, or any type of talk page, this can be taken as a deletion request. While patrolling new pages, I've seen some pages that had been blanked by it's author but couldn't find the correct criteria. Masum Reza^📞 07:11, 23 October 2019 (UTC)

  For example, K-177_(Kansas_highway). The only contributor blanked it's page. I tried to tag it per G1 (I thought it was a accidental creation), but Tulsi Bhagat deleted it per GA1. That criteria was applicable but I wanted a more specific criteria. Masum Reza^📞 07:16, 23 October 2019 (UTC)

  We don't need to special case every little thing. Administrators are able to think for themselves. Sebari – aka Srittau (talk) 12:28, 23 October 2019 (UTC)

  I also agree with this sentiment. I'm thinking this is more and more looking like an enwiki idea en:WP:CREEP. Where we just keep adding rules little by little until we are smothered by them. Admins were made admins because they are trustworthy enough to made decisions. If there are problems with this then we should be discussing individual cases. Not wholesale adding new rules like this. --Majora (talk) 22:09, 23 October 2019 (UTC)

  G1 seems okay for that. - Alexis Jazz ^{ping plz} 15:05, 23 October 2019 (UTC)

Extending eligibility time for G7 vote

Can the community vote on extending eligibility of G7 to 2 weeks. The reason for my request proposal is so recent uploaded files that the users don't want anymore have more time to be eligible for G7. Please come join this discussion. --VKras (talk) 16:02, 23 October 2019 (UTC)

@VKras: You can still request non-speedy deletion after 7 days. - Alexis Jazz ^{ping plz} 16:02, 23 October 2019 (UTC)

@ Alexis Jazz Files uploaded more than 7 days ago take much longer to be deleted. --VKras (talk) 16:04, 23 October 2019 (UTC)

@VKras: Could you clarify some things for me? What do you mean by Files uploaded more than 7 days ago take much longer to be deleted.? Masum Reza^📞 22:35, 23 October 2019 (UTC)

@ Masumrezarock100 Basically, files uploaded more than 7 days ago need regular DR to be deleted. --VKras (talk) 07:31, 24 October 2019 (UTC)

User talk pages and G8

G8 doesn't currently have an exception for user talk pages of users who have non-existent user pages. I think that should be added. Like "The criterion only applies to content within Wikimedia, and does not apply to external content (i.e. deleted source) and or user talk pages." pandakekok9 10:18, 27 March 2020 (UTC)

User talk pages don't depend on the user page content, so I don't think they are within G8 currently, but wouldn't hurt to be explicit. (Should it be or user talk pages ?). Carl Lindberg (talk) 15:01, 27 March 2020 (UTC)

Yeah, it should be "or". You're right though that user talk pages don't depend on the user page, so I won't mind if this change doesn't pass because it's unnecessary. Wherever this proposal goes, at least it would be clear that user talk pages are exempted from G8. pandakekok9 02:12, 28 March 2020 (UTC)

Merge CSD GA2 into CSD G1

Hello!

I see no difference between these criteria. I propose a merger into CSD G1. Any questions?Jonteemil (talk) 18:09, 1 April 2020 (UTC)

• Support for the sake of simplicity, pending further discussion. I also propose the older criteria (currently GA4 and C1) be removed and replaced, as they weren't used recently. Yes older link would be broken, but I think that is a sacrifice we'd have to make to keep the current list neat and concise. If necessary, we could add a separate sentence describing what the criteria was previously. MediaWiki:Deletereason-dropdown would also need to be updated. Thoughts welcome. Rehman 01:34, 2 April 2020 (UTC)
•  Support per Rehman. --pandakekok9 02:29, 2 April 2020 (UTC)

---

@Rehman: Since no one seems to protest I guess this proposal has been successful. Can you edit the page? It seems a bit to techy for me to dare.Jonteemil (talk) 09:39, 22 April 2020 (UTC)

Jonteemil, sure. Let's keep this open over the weekend, in case anyone has any last-minute feedback. I will get to it by next week. Being the CSD for Commons, I'd like to take this slow. Cheers, Rehman 10:10, 23 April 2020 (UTC)

Sounds good.Jonteemil (talk) 10:31, 23 April 2020 (UTC)

Ping @Rehman: .Jonteemil (talk) 16:10, 30 April 2020 (UTC)

Jonteemil, changes done. Cheers, Rehman 07:59, 1 May 2020 (UTC)

Perfect.Jonteemil (talk) 10:39, 1 May 2020 (UTC)

User:Tacsipacsi. Re this revert, the renumbering was done per consensus above. Would you mind reverting the revert, and discussing our way back if necessary? Rehman 05:02, 2 May 2020 (UTC)

I went ahead and reverted your revert, per above, considering consensus was reached. Please feel free to start a new discussion, if you'd still like to keep the old references. Thank you. Rehman 11:58, 3 May 2020 (UTC)

@Rehman: {{SD}} doesn't work now because of the removing of criteria. Can you please update it?Jonteemil (talk) 04:50, 7 May 2020 (UTC)

Jonteemil, thanks for the ping. Can you tell me what exactly doesn't work? I'll look into it. Cheers, Rehman 04:51, 7 May 2020 (UTC)

@Rehman: Well, the template is built with the pre-updated version of COM:CSD in mind so {{SD|C2}} is still coded as {{Bad name}} in the template, when it should be "empty category".Jonteemil (talk) 04:54, 7 May 2020 (UTC)

Jonteemil. Ah right. It's fixed now. Can you check? Rehman 04:54, 7 May 2020 (UTC)

@Rehman: It still doesn’t work unfortunately. See Category:ICA Maxi Birsta.Jonteemil (talk) 04:58, 7 May 2020 (UTC)

I added {{SD|F6}} to show how it should look like.Jonteemil (talk) 04:59, 7 May 2020 (UTC)

Thanks, Jonteemil. I made a typo there. It is now fixed. Rehman 05:05, 7 May 2020 (UTC)

@Rehman: Perfect, thanks!Jonteemil (talk) 05:07, 7 May 2020 (UTC)

Rearranging deletereason dropdown

Hello. I'd like to propose a change to the deletereason dropdown. Please see Commons:Administrators' noticeboard#Rearranging deletereason dropdown. Thank you. Rehman 11:03, 14 May 2020 (UTC)

Does speedy deletion for misspelling in redirect is ok for deletion ?

Hello,

Following this discussion, does speedy deletion for misspelling in redirect is ok for deletion ?

Thanks beforehand, Bretwa (talk) 10:49, 23 May 2020 (UTC)

SVGs that just contain an embedded raster image

It's fairly common that people will see {{Convert to SVG}} on a raster image, will completely misunderstand the point of SVG, and will upload an SVG file that just embeds the original raster image, rather than actually creating a vector version. I think we should either explicitly expand the F8 criterion to cover these files, or add a new criterion for them. Jackmcbarn (talk) 03:27, 19 August 2020 (UTC)

Typo fix

{{Edit request}}

Please add a comma before the etc. "...deletion can be controversial, the category was recently unconsensually emptied, etc. Consider..." — Preceding unsigned comment was added by 2601:5c6:8081:35c0:f1af:98b:c9e4:b142 (talk) 00:36, 8 October 2020‎ (UTC)

 Done, thanks!   — Jeff G. ツ _{please ping or talk to me} 00:54, 8 October 2020 (UTC)

Deletion of Image On My Profile

How can I delete the image on my profile? Can somebody please help me. Anthea Roa Murfet (talk) 06:15, 1 February 2021 (UTC)

@Anthea Roa Murfet: Hi, and welcome. File:Anthea Roa Murfet.jpg was already deleted per COM:HD#Deleting an image.   — Jeff G. ツ _{please ping or talk to me} 15:11, 1 February 2021 (UTC)

Thank you so much Jeff! Anthea Roa Murfet (talk) 10:19, 13 February 2021 (UTC)

@Anthea Roa Murfet: You're welcome!   — Jeff G. ツ _{please ping or talk to me} 13:31, 13 February 2021 (UTC)

Proposed changes to F1 and F3

Here is my proposed revision of F1 and F3, developed in collaboration with others at Commons talk:Deletion requests#Changes to CSD text:

F1. Clear copyright violation

Content is a clear copyright violation, with no good evidence of Commons-compatible licensing being issued by the copyright holder or status as a free work.^{Note: See revised version as of 06:34, 14 September 2021 below.} This does not apply whenever there is a reasonable possibility of discovering that the work is public domain through further research or a plausible argument that it is below the threshold of originality. Repeated uploading of non-free material may lead to the uploading user's account being temporarily or permanently blocked.

F3. Derivative work of non-free content

Derivative works based on non-free content (such as screenshots of non-free content). This does not apply to photographs taken in a public place, though the photograph itself remains subject to the other speedy criteria if its authorship is in question. Given the complexity of copyright rules like COM:FOP and COM:DM, it is best for such issues to be resolved in a formal deletion request.

I've basically taken my proposed changes 1 and 2 from that section as-is, and revised change 3 to be more generic. I've also swapped "apparent" for "clear", since "apparent" is a contranym which could mean either "obvious" or "seeming", and we want to emphasize that F1 is not for mere suspicions of copyvio. @Ikan Kekek, SHB2000, Nelson Ricardo 2500, Christian Ferrer, ArticCynda, Andy Dingley, A.Savin, Jeff G., Davey2010, and JWilz12345: @廣九直通車, Tuvalkin, Liuxinyu970226, Yann, Pere prlpz, and LPfi: Your feedback is appreciated. -- King of ♥ ♦ ♣ ♠ 05:46, 14 September 2021 (UTC)

•  Support LGTM. SHB2000 (talk) 05:48, 14 September 2021 (UTC)
•  Support, especially the F1 change. I might still try to work in a link to COM:FOP in F3. Carl Lindberg (talk) 05:51, 14 September 2021 (UTC)

  @Clindberg: How does it look now? -- King of ♥ ♦ ♣ ♠ 05:59, 14 September 2021 (UTC)

•  Comment I like F3 but would suggest rephrasing F1, because there are users who believe that mere small (or even not that small) size constitutes "no good evidence of Commons-compatible licensing" and produces a presumption of copyright violation, such that even photos from 2005 by photographers who uploaded them in good faith but may be dead should in their opinion be deleted. My proposed rephrasing: Content is a clear copyright violation, with good evidence that no Commons-compatible license was issue by the copyright holder, nor is it a free work. This does not apply whenever there is a reasonable possibility of discovering that the work is public domain through further research or a plausible argument that it is below the threshold of originality, nor is mere size clear evidence of copyright violation. Repeated uploading of non-free material may lead to the uploading user's account being temporarily or permanently blocked. -- Ikan Kekek (talk) 06:24, 14 September 2021 (UTC)

  @Ikan Kekek: How about we invert it: "Content is a clear copyright violation, with evidence that no Commons-compatible licensing has been issued by the copyright holder." (No need to mention size in that case.) The most common form of such evidence would be an external website with no free license predating the Commons upload, but other forms of evidence would include Getty Images in the metadata or watermarks which indicate that the image is from a notable copyrighted work such as Google Maps or a copyrighted TV show. (What we don't want is people tagging for speedy deletion just because a random name in the file description, metadata, or watermark does not match the uploader's username; those are for npd or DR.) -- King of ♥ ♦ ♣ ♠ 06:34, 14 September 2021 (UTC)

•  Support I definitely support that phrasing. -- Ikan Kekek (talk) 06:37, 14 September 2021 (UTC)

 Support phrasing as of 06:34, 14 September 2021 (UTC).   — Jeff G. ツ _{please ping or talk to me} 10:48, 14 September 2021 (UTC)

 Support. I suggest the simplest English wording (short sentences), while we still have a precise explanation, so that it can be understood by non-native speakers. It also makes translations easier. Regards, Yann (talk) 17:46, 14 September 2021 (UTC)

 Support This is an improvement. Christian Ferrer ^(talk) 18:43, 14 September 2021 (UTC)

 Support. -- Geagea (talk) 19:34, 14 September 2021 (UTC)

 Support --A.Savin 22:24, 14 September 2021 (UTC)

 Support Lotje (talk) 04:27, 15 September 2021 (UTC)

 Support looks good to me! --El Grafo (talk) 14:12, 15 September 2021 (UTC)

 Support Excellent improvement, nice work! ArticCynda (talk) 20:16, 21 September 2021 (UTC)

 Support. Sensible to clarify SD shouldn't be used in some more nuanced cases. Aranya (talk) 15:50, 24 September 2021 (UTC)

Seeing that there is unanimous support after a month, I have made the change. Please take a look at the new version of the page. -- King of ♥ ♦ ♣ ♠ 22:41, 16 October 2021 (UTC)

U1

U1 currently says:

User requested deletion of their own user page or user-subpage. User pages that are blanked by the user may also be deleted under this criterion.

The linked page is a rejected proposal! Why is it linked here? The rejected proposal links to meta:Help:User page; perhaps the CSD should also link to that help page. Brianjd (talk) 11:33, 9 November 2021 (UTC)

Creations by blocked or locked users

I think we need a new criterion based on en:WP:CSD#G5.   — Jeff G. ツ _{please ping or talk to me} 10:37, 16 November 2021 (UTC)

This has been rejected at least once before. Tokfo (talk) 16:51, 16 November 2021 (UTC)

I think the reason is similar to why we allow original research on Commons (which can be as simple as visiting a remote area of a national park to photograph it and having others trust that the image depicts what it purports to depict). Copyrighted text can be easily transformed into Wikipedia prose in a way that is not considered a derivative work, so it is not a huge loss to delete contributions by banned users. However, images don't work the same way, so 1) we don't require images to come from a reliable source and 2) we can't afford to lose useful content created by a banned user which can't easily be recreated. Now, if it's out of scope, it can of course be deleted for that reason alone. -- King of ♥ ♦ ♣ ♠ 17:25, 16 November 2021 (UTC)

The reason for the blocking is important. If someone persistently creates new accounts to upload copyrighted images, then asking for each one to be individually checked is a huge sink of volunteer time while in the meantime leaving copyrighted images hosted on Commons under false licenses. Chipmunkdavis (talk) 03:19, 17 November 2021 (UTC)

@Chipmunkdavis: In my experience, a history of copyright-related warnings or deletions is already a significant factor in subsequent DRs where the copyright status is in doubt - even if the uploader has not yet been blocked. I don't see what this has to do with blocking. Brianjd (talk) 05:32, 17 November 2021 (UTC)

It's about potentially avoiding sucking up volunteer time in building the DR case and then adding to the months-long backlog of deletion requests. Chipmunkdavis (talk) 05:48, 17 November 2021 (UTC)

@Chipmunkdavis: Oh, I see. That's why you want to send these files to speedy deletion. But is individual tagging for speedy deletion (which implies individual checking of each file) really more efficient than a mass DR (which probably will not require individual checking in such an extreme case as a copyright-violating sockpuppet)? I don't have much experience with sockpuppets, so I am probably not qualified to answer this question. Brianjd (talk) 06:58, 17 November 2021 (UTC)

The COM:VFC plugin allows a user to add the same speedy deletion tag to any or all of a user's uploads in a few clicks, although I don't know how that looks to the admin deciding whether to delete or reject each one. Speedy deletion is more efficient in terms of how quickly the issue would be addressed, though: I've seen cut-and-dried block evasion DRs left open for six weeks. --Lord Belbury (talk) 11:36, 17 April 2022 (UTC)

As far as I am concerned, this quote sums it up:

An upload by a sock that has to be deleted and another day the same upload by a non-sock that has to be kept is patent nonsense.

— Achim55 at Commons:Village pump/Archive/2020/04#Request for comment: Deletion/undeletion of uploads by banned/blocked users

Of course, this quote would not apply to copyright violations, which seems to be Chipmunkdavis's main concern. What about Jeff G.? Why do you want this change? Brianjd (talk) 07:26, 17 November 2021 (UTC)

@Brianjd: I want to streamline the process of deleting the detritus left behind by locked or blocked proven sockmasters, sockpuppets, and copyright violators by allowing the use of Special:Nuke and more discriminating tools, as inspired by the frustration I see at User talk:Elcobbola#Sockfarm copyright issues.   — Jeff G. ツ _{please ping or talk to me} 11:28, 17 November 2021 (UTC)

I think a "speedy PROD" approach may be appropriate: any files uploaded by socks of blocked/banned users during their block/ban may be speedily deleted if no user in good standing endorses their existence. If a file is in use on any Wikimedia page other than the sockpuppet/sockmaster's user page (which is a broader definition than COM:INUSE), then it is automatically ineligible because someone else implicitly endorses its use. (If a non-banned user adds it anywhere including their userpage, then they are endorsing the file, though it can still be nominated for regular DR as out of scope. If the banned user adds it to an article, then the community is endorsing the file until and unless they remove it from the article.) If someone makes a keep !vote at DR, then it is ineligible as well. Finally, files speedily deleted under this criterion may be unilaterally restored by any admin or summarily REFUNDed at COM:UNDEL upon request by a user in good standing (and converted to DR if the patrolling admin has doubts, but they should not unilaterally decline the request unless it meets another CSD criterion). This criterion should only be used as a last resort, i.e. if there is sufficient evidence for F1 then F1 should be used. -- King of ♥ ♦ ♣ ♠ 20:06, 17 November 2021 (UTC)

 Support At least in case of globally banned users the situation is clear – just block, nuke & forget. It's not worth to loose volunteers' time for analysis what a vandal/abuser did. The global policy states: Accordingly, an individual globally banned by the Foundation may not edit, contribute, or otherwise modify any content on those sites, platforms, or lists, without the explicit permission of the Wikimedia Foundation and Any contributions made by a banned individual, directly or indirectly, may be reverted or removed as part of ban implementation. --jdx ^Re: 00:33, 18 November 2021 (UTC)

Productive users can get blocked or banned for reasons that have nothing to do with violating copyrights. If somebody's files were to be deleted on the ground that they are blocked, they need to have been blocked for that specific reason, and they should be new users so that their uploads can be regarded as one batch. I don't see why a deletion request for "unused files uploaded by NN" cannot be used for those cases, and I don't see what being blocked has to do with anything. Only a tiny portion of our files are used on any Wikimedia projects, so not being used is no guarantee for not being valuable. –LPfi (talk) 13:42, 18 November 2021 (UTC)

For the sockfarm issue, that can be handled by requesting deletion for any files uploaded by the specific user and his present and future socks, in an ordinary deletion request or whatever. Those are about very few users, so we don't need any shortcuts for the decision itself, and we don't need to couple it with blocks or banns, which are about a much larger group. –LPfi (talk) 13:52, 18 November 2021 (UTC)

• This is a really bad idea, a user known for uploading good images could be blocked and / or banned for basically anything unrelated to their uploads and if they evade their block to upload more useful free educational images these images would then be considered for speedy deletion (without discussion) while under the current system they wouldn't even be eligible for the normal deletion process. If a user only uploads copyright violations and is known for only uploading copyright violations then it's highly likely that they are already getting nuked in the current system without such an addition, in fact it doesn't even matter if there was a prior block (or ban) or not. Meanwhile it would automatically make useful (often used) images eligible for deletions simply because of the social status of the uploader and not the content of the file itself. There is this user who keeps telling me that I'm an idiot and that I should go fuck my mother, I have tagged around a hundred of their socks and I usually find their socks pretty quickly, but they manage to find extremely rare public domain images that otherwise wouldn't be on the internet if they didn't upload it with their socks, while I cannot say that I am a fan of that person, I very much appreciate his uploads and have defended a number of his uploads from being deleted after others that have had issues with him nominate them as "sock uploads" and nothing more, if they upload copyright violations of hoaxes I nominate them for deletion, but a lot of their uploads are free and educational and most important of all extremely hard to find online. If a user gets indefinitely blocked for uploading copyrighted screenshots of non-free websites after warnings and then registers a new account to upload free content and doesn't continue any disruption that originally got them blocked then deleting their good edits doesn't prevent any more bad edits, it would be deletion for the sake of deletion.

Deleting content on the basis of anything other than the content itself is a disservice to the Wikimedia Commons and its users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:39, 20 November 2021 (UTC)

Additionally, based on globally locked users puts extra powers in the hands of admins on other projects over the Wikimedia Commons (not talking about WMF banned users), if a user at the Turkish-language Wikipedia and Turkish-language Wikisource disrupts there and then gets globally locked (de facto globally banned) then all their contributions here would then be liable to deletion (despite official policy at the Meta-Wiki even stating that global locks aren't global bans and that lock evasion shouldn't immediately be greeted with another global lock if the new account isn't being disruptive, current version), in all cases, content should always come first and rehabilitation should come before blind punishment. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:48, 20 November 2021 (UTC)

•  Support for uploads that match the disruptive behaviour a user was blocked for, with it being enough for a nominator to say "likely copyvio" without providing an explicit source if a sockmaster has a talk page full of copyvio deletions. In a case like Commons:Requests for checkuser/Case/Yuiyui2001, the problem user seemed pretty happy to upload dozens of hoax police badges onto Commons under a new username every few weeks, seeing that it would often take Commons a month to discuss and delete each batch, at which point they could make a new account and upload some more. I'm also seeing cases where socks of copyvio uploaders get blocked for socking, but their uploads are left in place: there should be an option for a quick sweep of "block evasion, likely copyvio" speedy deletions, rather than expecting the blocker or nominator to comb through and provide source URLs for dozens of files. --Lord Belbury (talk) 11:23, 17 April 2022 (UTC)

Policy for users removing tags from their own images

{{Dont remove speedy}} says that users shouldn't remove speedy templates from their own articles and to "make your case on the image's talk page", but {{Speedydelete}} says to "replace this tag with a regular deletion request".

If the second is correct, is that the best advice to give to new users? An editor unfamiliar enough with Commons to be uploading problem images seems unlikely to know how to raise a "regular deletion request", and it seems rather backwards to say that if someone wants to save the image they should request its deletion. --Lord Belbury (talk) 13:33, 16 February 2022 (UTC)

Clarification for "F1. Clear copyright violation"

Hi! The most common case I encounter are SVG logos that are uploaded under the default license as "own work". Official licensing information for a work is often hard to find. Is it okay to just {{Copyvio}} the file or am I supposed to open a deletion request instead? On one hand I usually don't have proof that it isn't own work, but the uploader also provides no proof that it is own work or that the company that uses the logo allowed sharing it under cc-by-sa. TilmannR (talk) 21:42, 2 April 2022 (UTC)

I just found {{Logo above threshold of originality}}, which says "this media is a logo or a derivative work thereof, which are always presumed to be copyrighted [...]". So I'll just place this template and it'll be the uploader's responsibility to show that the logo is available under a free license, I guess? TilmannR (talk) 22:13, 2 April 2022 (UTC)

I'm also seeing some "own work" logos with "No permission since" ({{subst:npd}}). Is that the preferred method? TilmannR (talk) 23:03, 2 April 2022 (UTC)