Open main menu

Commons talk:Criteria for speedy deletion

This is the talk page for discussing improvements to Commons:Criteria for speedy deletion.
This talk page is automatically archived by ArchiveBot. Any sections older than 60 days are automatically archived. Sections without timestamps are not archived.

Crossnamespace redirectsEdit

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"Edit

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 pagesEdit

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 changesEdit

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.jpgEdit

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).Edit

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?Edit

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.Edit

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 filespaceEdit

  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 (d) 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)

Return to the project page "Criteria for speedy deletion".