Wikipedia talk:Criteria for speedy deletion/Archive 89

Archive 85

←

Archive 87

Archive 88

Archive 89

Prior to speedy deletion and or removal of a statement on articles ie… promotional, promotion of violence and discrimination etc…

An additional contributor page of the article like talk with statements or discrepancies to be highlighted Green the whole article/s/ word/s or statement/s stating that the edit or statement or article is under review or under verification being acknowledged by Wikipedia to be considered a true statement or its existence and are/is factual or within legal limits and boundaries and will be finalized by team for compliance and confirmation The Summum Bonum (talk) 12:04, 12 July 2024 (UTC)

@The Summum Bonum Please could you try rephrasing that? I've read it several times and still don't understand what you are trying to say. Thryduulf (talk) 12:31, 12 July 2024 (UTC)

My apologies I’m simply proposing that a statement/sentence or a word/words can be Highlighted by color green fonts or any other colors to visualize that the statement/sentence or words/phrase is under review or being reviewed to confirm or verify that its is a legitimate statement or source etc..prior to deletion or adding another page on article a contributor page or Edit page /article/talk/discussion/editor/ page< Visualized for your convenience hope you got it this time again my apologies.

it wasn’t my intention to speak in an Coded encrypted paragraph an old practice.The Summum Bonum (talk) 12:52, 12 July 2024 (UTC)

If a page is being nominated for speedy deletion, the entire page is problematic, and we would then be highlighting the entire page. If only part of a page is problematic, then it should be dealt with via removal and no CSD is required. Primefac (talk) 19:42, 13 July 2024 (UTC)

R3 and redirects ending with "(disambiguation)"

The final sentence of R3 currently says It also does not apply to [...] redirects ending with "(disambiguation)" that point to a disambiguation page.. My first thought was this should be changed to "...a disambiguation page or a page that performs a disambiguation-like function" to match the language of G14. However I then realised that I don't think that's quite right either. I think the intent is to exclude WP:INTDABLINK redirects from being considered implausible. However, it also excludes redirects that contain very obvious typos (e.g. Bulse (disambiguation) → Blues (disambiguation)) or other clear errors (e.g. British Rail Class 9001 (disambiguation) → Languages of the Congo) which cannot be the intention. I'm not sure what the best alternative wording is, but something along the lines of "...unless the part before the parentheses contains implausible typos or is implausibly related to the target" (along with incorporating the disambiguation-like language from G14) maybe? Thryduulf (talk) 01:05, 16 July 2024 (UTC)

Do we really need it at all? It strikes me as the sort of thing that got stuck onto the end of the policy unnoticed because one day a single admin decided to improve his placement on that awful ADMINSTATS scoreboard by deleting every one of these that he could find, to a universal chorus of "No, of course those aren't implausible." At most it should be stuck down lower in the #Non-criteria section. —Cryptic 01:19, 16 July 2024 (UTC)

Wikiblame says it dates from Wikipedia_talk:Criteria_for_speedy_deletion/Archive_45#"Foo_(disambiguation)"_redirects_created_in_accordance_with_WP:INTDABLINK -> Wikipedia talk:Disambiguation/Archive 35#Speedy deletion of "Foo (disambiguation)" redirects. I also found User_talk:DangerousPanda/Archive_7#Intentional disambiguation redirects (context), User talk:RHaworth/2012 Jan 29#Intentional disambig redirects, User_talk:Cindamuse/Archive_19#Intentional_disambig_redirects, User_talk:Fastily/Archive_4#Intentional_disambig_redirects. Of the four admins listed there two of them have been desysopped due to unrelated misconduct, one of them stopped editing in 2014, and one of them is still an admin but probably knows better a decade later. * Pppery * _{it has begun...} 01:55, 16 July 2024 (UTC)

Well that shows that BD2412 should be invited to express their opinion. Now that I'm more awake I realise that if we do want anything, we could be massively more concise and say something like "it also does not apply to [...] correctly formed WP:INTDABLINK redirects." Thryduulf (talk) 10:21, 16 July 2024 (UTC)

My opinion as expressed in the discussion is correct. A Bar (disambiguation) redirect (or even a BAR (disambiguation) redirect) pointing to the disambiguation page Bar (to which BAR also points) should never be speedily deleted as an "implausible" typo, because such a redirect is not implausible at all, it is policy-supported to have it. Word this as you wish to make it clear. BD2412 T 15:14, 16 July 2024 (UTC)

So many things would be so much better if ALL disambiguation pages ended with " (disambiguation)". There would be no barrier to newcomers understanding what a disambiguation was. Readers going to a page would know upfront that they were going to a disambiguation page. Most of these troublesome pages would never have been created. SmokeyJoe (talk) 11:31, 16 July 2024 (UTC)

There would still be a need for redirects like Languages of the Congo → Languages of the Congo (disambiguation) that I'm sure would cause about the same number of issues with deletion, incorrect bold retargetting and people not knowing/understanding (or disagreeing with) the exception to the usual primary topic is not disambiguated rule. Whether it would be better for readers I don't know, but it wouldn't be significantly better (or worse) for editors. Thryduulf (talk) 11:45, 16 July 2024 (UTC)

Redirects are cheap.

The disambiguation pages would be unambiguously disambiguation pages, and articles would be unambiguously not disambiguation pages. Simple obvious principles, rather than convoluted rules and practices, makes for less issues.

A page title accurately telling the reader what the page is, a dab page or not, is obviously better for the reader, in my personal experience for sure. SmokeyJoe (talk) 13:03, 16 July 2024 (UTC)

Allow creators to remove R4 tags

R4 is a criterion split from G6, but unlike G6, the redirect's creator is not allowed to remove the tag themself. I see no reason that restriction is necessary for R4 in particular and I think that it should be removed, much like it was done for G14. Nickps (talk) 12:32, 20 July 2024 (UTC)

Note that there are valid reasons to contest an R4 like the ones listed at Wikipedia:Criteria for speedy deletion § Other issues with redirects. Nickps (talk) 12:39, 20 July 2024 (UTC)

Has this actually been a problem? R4 is one of those criteria where the "objective" and "uncontestible" dogmas truly apply - either it has the same name as a file on Commons or it doesn't, and if it truly does then the problem is unfixable and it should always be deleted and if it doesn't than an admin will decline. In either case there's no value to the creator removing the tag. * Pppery * _{it has begun...} 15:40, 20 July 2024 (UTC)

I'm not aware of a convenient way to find all contested R4 deletions so I can't answer that. My motivation for this change is mostly to regularise the CSD process and make it less hostile towards new users. For example, up until today, {{db-redircom-notice}} (as well as {{db-talk-notice}}, {{db-disambig-notice}} and {{db-rediruser-notice}}) directed editors to a non existent "Contest this speedy deletion" button. After I fixed that, I also realised that there is really no reason to disallow the creator removing the R4 tag so I brought it here. Since, as Thryduulf has pointed out, R4 isn't entirely objective and there is a valid reason for the creator of a redirect to remove the R4 tag, can we put this to rest now and add R4 to the list? Nickps (talk) 16:31, 20 July 2024 (UTC)

And realistically there will never be file redirects with useful page history so your second comment doesn't apply. * Pppery * _{it has begun...} 15:43, 20 July 2024 (UTC)

If there incoming links then it is not eligible unless they are "clearly intended for the file on Commons" (which is subjective). The implication being that links to the image that is not at this title on Commons need fixing first, and the creator could be highlighting the existence of such links. I don't see a problem with the suggestion. Thryduulf (talk) 15:44, 20 July 2024 (UTC)

In that case they may as well fix them rather than removing the tag and allowing things to remain indefinitely in a state the community has declared verboten. * Pppery * _{it has begun...} 16:38, 20 July 2024 (UTC)

That assumes that the creator can fix all of the incoming links, which will not always be true - for example some may require discussion (e.g. where the intended target is not clear) or be on pages that they cannot edit (e.g. protected pages). The page can be nominated for G4 again when the links are fixed or taken to RfD at any time. Thryduulf (talk) 08:24, 22 July 2024 (UTC)

• I think its fine to allow authors to remove R4 tags, many users dealing with redirects are experienced and unlike R3 which is similar to A7 and A9 R4 doesn't seem like its too much of a problem to allow authors to remove in the rare cases where they object. RFD would be sufficient in such cases. Crouch, Swale (talk) 17:33, 20 July 2024 (UTC)

F8 and keep local

I can understand why quite a number of those uploading files might want to keep their creative content local by adding the template {{Keep local}}, but it seems that this template might also be being used by others with respect to content they didn't create. The thing that started me thinking about this is File:The Penguin (TV series) logo.jpg. It's obvously not the original work of the uploader. It was originally uploaded as non-free but subsequently converted to a PD license and moved to Commons based on c:Commons:Deletion requests/File:The Penguin (TV series) logo.jpg. The uploader then added a {{Keep local}} template to the file. I know some file uploaders have had some bad experiences with Commons, but it seems a bit odd for someone other than the original copyright holder of the content to be able to request such things. There certainly can be time and effort involved in finding content to upload to Wikipedia for use in various articles, but that doesn't really create a claim of ownership over the content for the uploader. So, it seems odd that acknowledgement of such a claim (at least in my opinion) is being given just to whoever adds "Keep Local" to a file, particularly in the case where the file licensed as PD.

FWIW, I'm not trying to single out one particular file or one particular uploader by linking to the file mentioned above; I'm only using it as one example of what are probably lots of similarly tagged files. It seems that there should be some restrictions placed on the use of this template, including perhaps limiting it to original content uploaded locally to Wikipedia in which the uploader/copyright holder is the making the request. For reference, Category:Wikipedia files on Wikimedia Commons for which a local copy has been requested to be kept has almost 6000 entries. How many of these really need to be or should be kept local? -- Marchjuly (talk) 03:00, 12 July 2024 (UTC)

{{keep local}} is simply is a request to retain a local copy, not a claim of ownership. Not seeing any reason to add an ownership component to it. Nikkimaria (talk) 03:14, 12 July 2024 (UTC)

I’m still newb about most issues regarding verification and what are facts and informations that are red flag in layman’s terms and our rules and regulations are evolving continuously as new technologies introduction of ie..AI but we must stand firm to some rules that are foundation to the organization, I introduced a proposal of team confirmation and a editor or contributor page highlighting Green on the statement word link etc… stating Color green as under verification to be factual or within legal limits boundaries including this issue you have encountered. Proposal of a Green Highlight as a flagged feature on wiki. Or any other color for easy visualization that an issu is presentThe Summum Bonum (talk) 12:34, 12 July 2024 (UTC)

@The Summum Bonum: I think you might've mistakenly posted your above comment in the wrong discussion thread or maybe even on the wrong talk page because it doesn't seem to be about what's being discussed here. -- Marchjuly (talk) 23:38, 13 July 2024 (UTC)

It's unlikely that someone "might want to keep their creative content local". A file file would not need to be kept local if the uploader is the copyright holder. If the user is the copyright holder, the file normally must have a free license. So, it can be on Commons without problem. Unless it is out of scope, but then it is likely out of scope on Wikipedia also.

The most usual use of the template "Keep local" would be for some files of which the user who adds the template is not the copyright holder. A typical use can be for files whose public domain status might be considered borderline or disputable or anyway not undoubtably 100% certain for everybody. And consequently there might be some possibility, even if small, that the file might be deleted from Commons. It happens that files are kept on Commons at one point but deleted some months or years later.

The file "The Penguin (TV series) logo.jpg" is a mild example. It was uploaded to Wikipedia on 13 Avril 2023, copied to Commons on 15 April 2023, deleted from Commons on 18 April 2023, undeleted on Commons on 10 May 2023, deleted from Wikipedia per F8 on 11 May 2023, nominated for deletion on Comons on 15 June 2023, undeleted on Wikipedia on 15 June 2023, kept on Commons on 17 October 2023, deleted from Wikipedia per F8 on 17 October 2023, undeleted on Wikipedia on 18 October 2023.

It can be noted that on 15 June 2023 it was not the uploader who added the template "Keep local". The template "Keep local" was added on Wikipedia by the user who nominated the file for deletion on Commons. Adding the template was indeed the wise and logical thing to do in that circumstance, while the file was still on Commons. That deletion discussion on Commons was closed as "kept", but if the file had been deleted from Commons, the template "Keep local" could probably have been replaced with the template "Do not move to Commons".

It can be noted also that the file was deleted from Wikipedia on 17 October 2023 despite the fact that the file was marked with the template "Keep local" at that time, so it was deleted in violation of the policy Wikipedia:Criteria for speedy deletion. Fortunately, that was noticed by another admin the next day and the file was undeleted.

We've seen typical worse examples, where files go through multiple such cycles of deletions and undeletions in a game of ping pong between Wikipedia and Commons. It's a waste of time and effort every time to have to track the deleted files, find an admin to undelete the files, only to have, six monts later, some user come from nowhere and, without thinking, pull a F8 again and destroy all the work and restart another round of the cycle.

The purpose of the template "Keep local" is that the file cannot be speedy deleted only by invoking F8. It's not that the file cannot be deleted. It could be nominated for deletion with a convincing deletion rationale. If the user who added the template is still active on Wikimedia, they should be consulted, to at least know and understand their reason and to check if they think the file must still be kept on Wikipedia. -- Asclepias (talk) 15:05, 12 July 2024 (UTC)

As pointed out below by JPxG, I think someone "might want to keep their creative content local" does happen, and it happens particularly because of the reasons they gave below. There are uploaders who have had really bad experiences with Commons; they, therefore, want to keep local files of their own work just in case. This seems (again at least to me) to be a valid reason for keeping the local file. I also do get that "keep local" is just a precaution against unnecessary speedy deletion and doesn't mean a file can't ever be deleted. FWIW, I haven't gone through each of the entries in Category:Wikipedia files on Wikimedia Commons for which a local copy has been requested to be kept. Maybe they're all like the files JPxG is referring to, but there are almost 6000 files in that category. My guess is that a good lot of them probably have been on Commons long enough to no longer justify a local version also being kept. Of course, removing the "keep local" doesn't mean the corresponding Commons file will never end up deleted. If, however, that happens for a really strong-polciy based reason (not some bot error or personal preference reason), it would also seem to imply that the local file should go as well. -- Marchjuly (talk) 23:38, 13 July 2024 (UTC)

When I upload files locally, it is on purpose, and there is a reason for it. I've often noticed (sometimes months after the fact) the mysterious silent disappearance of stuff I've uploaded to/embedded from Commons. This includes stuff which is unambiguously my own work and duly noted as such. Then I will look back, and see that it was deleted for some nonsensical reason: e.g. a bot failed to parse the license information from the license text I typed into the file description and marked it for deletion as "unlicensed". Sometimes images in active use will be nominated for deletion (with zero reference to policy or guidelines; on the explicit basis that the nominator doesn't like them) and this will go through after a second person agrees with them. At one point, there was an image which someone was slow-motion edit warring to remove from an enwp article, and after one of the removals, it got tagged for deletion at Commons as "unused", it was gone.

The times I've made undeletion requests on Commons or left messages to ask administrators directly about closures, they've been ignored, so I don't really have much choice except to upload the files locally on enwp, where there tend to be fewer frivolous deletion requests in the first place, but in the event there is one I will at least see it on my watchlist and be able to deal with it within a couple days, rather than realizing eight months later that some page looks different, digging into the edit history, and seeing that the image was delinked by a bot after a DR with the text "Hfdjksl". jp×g🗯️ 21:11, 13 July 2024 (UTC)

Can you link specific examples of instances where you've had files deleted without warning and/or had undeleteion requests ignored? Agreed that Commons isn't intuitive to navigate, but it should be possible to get help when you need it. Also if you are in a situation where you are being ignored, please feel free to loop me in, I'll apply pressure in all the right places :) -Fastily 22:58, 22 July 2024 (UTC)

Procedure for rejected draftified articles and declined/rejected AfC submissions improperly moved or copies to mainspace

So, this is something I've seen happen in some cases, usually involving inexperienced editors who have just gotten autoconfirmed. First there is the instance I've dealt with, where an article is draftified (when I've done it, it's usually for lacking references) and the author immediately recreates it by either moving it or, more often, by copy-paste. I haven't seen an exact consensus on what to do in this instance. Some have said db-copypaste might apply, but not all admins will delete in this instance. The other options would be re-draftify, PROD, or AfD.

The other instance would be declined or rejected AfC submissions that are moved or copied to mainspace without improvement. My understanding is that declined AfC pages that are resubmitted without improvement are usually summarily declined. If a submission is declined multiple times, that would indicate consensus that the page, in its present state, is unsuitable to be an article, putting it in a similar position to a page that meets G4. TornadoLGS (talk) 22:01, 1 June 2024 (UTC)

I think straight to AfD is usually the right choice. If it has already been moved to mainspace after a decline, there's strong reason to believe a prod would be contested. And as a contested deletion, it's not really a good candidate for a speedy deletion. That said, AfD is not mandatory. It happens that the draft reviewer can be wrong. Only take to AfD if you still believe it is not notable. —David Eppstein (talk) 22:30, 1 June 2024 (UTC)

That's unfortunate since AfD takes up a lot more editor time than CSD. Quick question on that. At which point does contesting a deletion count? Since I've seen plenty of authors go for the "contest deletion" option on G11, U5, and at least one A7 but it's ignored by the deleting admin. TornadoLGS (talk) 03:43, 2 June 2024 (UTC)

We are not here to delete as much stuff in as little editor time as we can, but to make proper decisions on whether something is or is not suitable to be an encyclopedia article. G11 and A7 are also possible speedies for some drafts moved to mainspace, but not valid for many of them. —David Eppstein (talk) 04:31, 2 June 2024 (UTC)

I guess I thought that a draft that has been declined or rejected (especially multiple times) might be sufficiently unsuitable for mainspace to be speedily deleted. I had been tentatively floating the idea of whether a new CSD criterion might be established for this instance, though it seems like that sort of criterion wouldn't work at this point. TornadoLGS (talk) 22:33, 2 June 2024 (UTC)

Rejected is just the opinion of one editor. On occasion I have moved such pages to mainspace, as clearly the rejection was not appropriate. A speedy delete in the situation you say is controversial, so AFD or other existing speedy delete (eg advertising or no claim of importance) is best. Graeme Bartlett (talk) 01:54, 7 June 2024 (UTC)

(edit conflict) Draftspace and AfC are optional. If someone moves a page from draft to article space that doesn't meet an existing speedy deletion criterion, but you believe should be deleted then PROD and AfD are your only options. AfC rejections represent the opinion of the reviewer(s), not consensus. Thryduulf (talk) 22:31, 1 June 2024 (UTC)

Just noting that if a copy/paste has been performed, unless the original editor is the only content editor a {{histmerge}} will be necessary. Primefac (talk) 01:02, 7 June 2024 (UTC)

• Use AFD, there shouldn't be a criteria for deleting such articles as it would discourage people from using AFD in the first place. Crouch, Swale (talk) 17:17, 7 June 2024 (UTC)
• AfC is not mandatory by any means. Any number of declines is not a consensus of any sort. AfD is the appropriate path in such situations described above; a speedy criterion based on drafts evaluated through a voluntary, non-binding process would be highly inappropriate. — Godsy ^(TALK_CONT) 07:41, 25 July 2024 (UTC)

Exclude G2 from draftspace

If WP:G2 doesn't cover userspace, why should it cover draftspace? The same reasons apply: experimentation isn't an unreasonable thing to do in draftspace, it's not indexed, and greeting a new user with Template:Db-test-notice is rather bitey. I'm also concerned that G2 is being used as a catch-all criterion to delete things that aren't test edits. I've listed the last 100 draftspace G2s here: hardly any are prototypical editing tests, while a large share are either blank pages (often good-faith placeholders that shouldn't be deleted) or low-quality but non-test efforts at writing an article or user page. The risk of bitey invalid deletions outweighs the handful of valid ones, and at any rate almost none of it needs to be deleted since detritus in draftspace is harmless and cleared out after six months anyway. I would suggest excluding draftspace from G2, just like we've done for userspace. Extraordinary Writ (talk) 07:14, 18 July 2024 (UTC)

Drafts in draftspace are meant to be drafts. Drafts of mainspace content, usually new articles, but drafting for merging to an existing article is perfectly reasonable. It’s not junkspace.

At MfD, we often delete draft pages for not being a genuine draft. This is softly worded delete justification for something that could be more aggressively called a test, vandalism or hoax, or implausible unverifiable material.

If a draftpage is obviously an old test, why not G2 it? Alternatives are to ingore it, or move it to the author’s userspace, Userfy it. Userfication of a test is much less bitey than speedy deletion, and if it was a test, the user will presumably want to look at again.

I think draft space tests should be userfied, unless “test” is a euphemism. SmokeyJoe (talk) 11:53, 18 July 2024 (UTC)

Support. I can't think of any reason why something in draftspace would be harmful enough to need speedy deletion and not fall under at least one of G1, G3, G9, G10, G11 or G12 and as Smokeyjoe says userfication or just waiting for G13 is going to be more appropriate in most cases anyway. Thryduulf (talk) 11:59, 18 July 2024 (UTC)

Oppose. These is actually a case where a test edit won't be dealt with by G13. If the test page is a redirect, then G13 doesn't apply. WP:R3 won't always apply either due to the "recently created" requirement. Being able to retain a test page forever by sticking a "#REDIRECT Wherever" on top goes against the principle that draftspace is not junkspace. Nickps (talk) 12:11, 18 July 2024 (UTC)

WP:RDRAFT says most redirects in draftspace should be kept. In other cases take it to RfD, from the list compiled by Extraordinary Wit there was only one redirect and that could (probably should) have been deleted under G8 anyway so there doesn't seem like RfD will be unable to handle the few remaining cases where a redirect in draftspace needs to be deleted. Thryduulf (talk) 12:17, 18 July 2024 (UTC)

RDRAFT concerns redirects made by moves. I'm talking about the case where a test page is created and as part of whatever test edits the editor makes, they also happen to make the page a redirect. In that case G13 won't apply, so RfD and userfication are the only ways forward. That was the point I was trying to make. Honestly, userfication is a better approach anyway, so I'll think about retracting my oppose, but G13 is still a flawed argument. Nickps (talk) 12:39, 18 July 2024 (UTC)

In my experience, G2s anywhere are mostly used as a catch-all criterion to delete things that aren't test edits. An old analysis. —Cryptic 12:28, 18 July 2024 (UTC)

Perhaps it's time for someone to write WP:!G2? Nickps (talk) 12:40, 18 July 2024 (UTC)

Maybe the meaning of “test” is not technical, but a test of Wikipedian tolerance for a bad faith contribution. A breaching experiment often involving promotion. SmokeyJoe (talk) 14:30, 18 July 2024 (UTC)

LOL. * Pppery * _{it has begun...} 15:48, 18 July 2024 (UTC)

Agreed with Cryptic. I've declined several G2s for that reason, and yesterday I declined a G2 at Willy Hüttenrauch only to be overridden by another admin who deleted it a minute later in an edit conflict. But my motivation to aggressively patrol the deletion log has been low lately, so not much has gotten done. * Pppery * _{it has begun...} 15:48, 18 July 2024 (UTC)

Whether that was a test or not, it was also a broken redirect. —Kusma (talk) 12:32, 25 July 2024 (UTC)

• If admins could be trusted, I would oppose this (genuine edit tests should be deleted without having to wait 6 months). But Extraordinary Writ's analysis makes it clear they can't, so support. * Pppery * _{it has begun...} 15:48, 18 July 2024 (UTC)
• Strong support - Draftspace deserves a certain amount of leeway that it often has not been afforded as it has matured. It needs less technical maintenance, "cleanup", and deletion. This is a step in the right direction. — Godsy ^(TALK_CONT) 07:51, 25 July 2024 (UTC)
• There is a lot of junk in draft space that violates WP:NOTWEBHOST but has no chance to ever become an encyclopaedia article. Deleting it per G2 is suboptimal, but happens a lot when the only other alternative is G13. I am opposed to restricting G2 unless we extend U5 to draft space. —Kusma (talk) 08:10, 25 July 2024 (UTC)

  If you're deleting non-test pages using G2 then you need to stop immediately as you are abusing your admin tools. If these NOTWEBHOST pages are actually a problem and don't meet an actual speedy criterion (rather than one you would like to exist) then take them to MfD. If they are as frequent as you claim then you will soon have the evidence needed to craft a speedy deletion criterion similar to U5. Thryduulf (talk) 09:06, 25 July 2024 (UTC)

  From my own G2 deletions:

  • Draft:HS content was "HS"
  • Draft:Wow Beck hansen content was "Wow Beck fanpage".
  • Draft:Matilda luck content was a different person's name and "ewwwwwwwwwww". Possibly a G10, but who knows. Deletion as G2 assumed no bad faith.

  The general problem with "test pages" as a speedy criterion is that we are asked to judge intent, not content. For a lot of graffiti pages ("Jim loves Suzie!", "I am the Playstation KING!") it seems the most appropriate of the G criteria (otherwise these will probably get nominated as G11's). —Kusma (talk) 12:28, 25 July 2024 (UTC)

  Why did the first two of those need to be deleted before G13 applied? The third was a G10 - it served no purpose other than to disparage the subject. Thryduulf (talk) 12:31, 25 July 2024 (UTC)

  Maybe we should rename Draft space to "Anything goes for six months" space so people do not work under the mistaken assumption that it is for drafting Wikipedia articles. —Kusma (talk) 12:35, 25 July 2024 (UTC)

  Consensus seems to be that the purpose of draftspace is somewhere between "anything goes" and "strictly only for drafting Wikipedia articles." If you think something in draftspace is actively harmful but doesn't meet a speedy deletion criterion then that's what MfD is for. Thryduulf (talk) 12:40, 25 July 2024 (UTC)

• Support per nom. Draftspace is not a terrible place to do a test. —SmokeyJoe (talk) 09:33, 25 July 2024 (UTC)