Jump to content

Wikipedia talk:Criteria for speedy deletion

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Davidwr (talk | contribs) at 16:52, 19 September 2020 (→Explicitly recommending that page movers to do some types of "deletion via move" to avoid delays: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Require hoaxes to be recently created

I propose to change:

This applies to pages that are blatant and obvious misinformation, blatant hoaxes (including files intended to misinform), and redirects created by cleanup from page-move vandalism.

to:

This applies to pages that are blatant and obvious misinformation, recently created blatant hoaxes (including files intended to misinform), and redirects created by cleanup from page-move vandalism.

See Wikipedia:Administrators' noticeboard#8 years-undetected hoax article for context on the article that inspired me to bring this up, Battle of Ceber. Even if it turns out to be a hoax in the end, the amount of research required to ascertain that means that it is clearly not a blatant hoax. Often, whether a hoax is "blatant" is subjective, and if a page has survived for several years then it's good evidence that it's not a blatant hoax, if a hoax at all. Given that the purpose of CSD is to reduce the workload at AfD/PROD and we don't have a large backlog of several-year-old hoaxes waiting to be deleted, I think we should just make it a rule that old pages deserve more scrutiny at AfD instead of being speedied as a hoax. -- King of ♥ ♦ ♣ ♠ 17:40, 8 July 2020 (UTC)[reply]

Why on earth should we make it more difficult to remove false information? Absurd. Praxidicae (talk) 17:43, 8 July 2020 (UTC)[reply]
@Praxidicae: The phrasing used is such that pages that are blatant and obvious misinformation would still come under the criteria even if they were not recently created, it's fair to say. Naypta ☺ | ✉ talk page | 17:55, 8 July 2020 (UTC)[reply]
@King of Hearts: The idea behind this is a good one, but would it not be more sensible to add to the end of the G3 criteria, after Articles about notable hoaxes are acceptable if it is clear that they are describing a hoax, something like Non-recently created pages are not generally blatant hoaxes, and should normally go through other deletion processes? I can see a conceivable scenario in which a genuinely completely blatant hoax could just be missed in NPP, so a speedy was still valid; doing it through a clarifying statement rather than making it part of the criteria would suit that scenario better, and equally give deleting sysops a policy line to point to in declining a CSD of a non-recently-created article. Naypta ☺ | ✉ talk page | 17:46, 8 July 2020 (UTC)[reply]
  • (edit conflict) Support per nominator. In the context of R3 the precise meaning of "recent" is not defined and there is no clear consensus beyond "a few days old" definitely is recent and "more than about a month old" definitely isn't. I don't think that the timeframes for this need to be that short, but I don't have any firm opinions in what it should be. "Recent" meaning "less than about 6 months old" is what first comes to mind but as I say I'm more than willing to consider alternatives. However I do firmly believe there should not be an exact cut-off. Thryduulf (talk) 17:50, 8 July 2020 (UTC)[reply]
  • I tend to agree with Naypta here: An article that requires extensive research to determine that it is a hoax is not a blatant and obvious hax, and speedy deletion is not the way to deal with it. An article that has been around for more than a year in mainspace, say, is probably not a blatant and obvious hoax, or howm was it missed for such a long time. But an article describing, say, how King Kong is currently being exhibited by Barmum's Circus in Albany New York is a blatant hoax, even if it has somehow been missed for years. Whether gross misinformation on a more obscure subject is a blatant hoax I am not sure, say an article about an 11th century reigning Duke in one of the Germanies that places him in the 13th century instead, or better an article about a person saying that he is an 11th C ruler of a small state, when he in fact never existed and no source so much and claims that he did, a vandal made him up out of nothing, or perhaps imported him form a historical novel. Surely that is a hoax, but it takes some research to confirm that it is -- is this blatant enough to speedy? Fortunately, such cases seem to be rare. DES (talk)DESiegel Contribs 19:15, 8 July 2020 (UTC)[reply]
  • Oppose- I echo Praxidicae's befuddlement: why in the name of $DEITY would we want to make it harder to remove misinformation??? It's bad enough that obstinate individual editors make removing hoaxes difficult without enshrining such obstructionism in our policies. Reyk YO! 19:23, 8 July 2020 (UTC)[reply]
    • It's probably also worth pointing out that the longest-enduring hoax article we ever uncovered was deleted by G3 just last year- conclusive proof that the system works as it currently stands and is in no need of changing. Reyk YO! 19:56, 8 July 2020 (UTC)[reply]
  • Oppose If it's a hoax, it should be speedyable. SportingFlyer T·C 19:53, 8 July 2020 (UTC)[reply]

Per Naypta's comment, I think the following would be sensible:

This applies to pages that are blatant and obvious misinformation, blatant hoaxes (including files intended to misinform), and redirects created by cleanup from page-move vandalism. Articles about notable hoaxes are acceptable if it is clear that they are describing a hoax.
This applies to pages that are blatant and obvious misinformation, blatant hoaxes (including files intended to misinform), and redirects created by cleanup from page-move vandalism. Articles about notable hoaxes are acceptable if it is clear that they are describing a hoax. For suspected hoaxes which are not recently created, consider using other deletion processes instead, as the page may not be a blatant hoax.

In strictly WP:LAWYERly terms, this doesn't change anything about the policy. However, because people have a tendency toward too liberal an interpretation of CSD, especially when subjective words are concerned, this provides guidance that old pages generally should not be G3'd, but if it's obvious enough then G3 is still OK. It's saying in essence, if your gut tells you it's a hoax, check again, there might be a reason why it has survived for so long; if you're still sure after double-checking, then you can nominate it for speedy deletion. -- King of ♥ ♦ ♣ ♠ 22:59, 8 July 2020 (UTC)[reply]

  • Support, with thanks to King of Hearts for taking on the feedback! Perhaps this should be an RfC? Naypta ☺ | ✉ talk page | 23:01, 8 July 2020 (UTC)[reply]
    This talk page is well enough attended that we'll probably get enough traffic even without an RfC. But that's certainly an option if it looks like we don't have enough voices. -- King of ♥ ♦ ♣ ♠ 23:06, 8 July 2020 (UTC)[reply]
  • Support per my comments on the first proposal. Thryduulf (talk) 23:55, 8 July 2020 (UTC)[reply]
  • I support the revised proposal by King of Hearts, based on the comments of Naypta above. DES (talk)DESiegel Contribs 00:58, 9 July 2020 (UTC)[reply]
  • Oppose - it was a bad deletion, but this fixes nothing. The problem was that something that wasn't a blatant hoax was deleted as a blatant hoax, it would've been just as bad if the article was eight minutes old as eight years old. This is just bureaucracy for the sake of bureaucracy. If people fail to follow rules, adding more rules won't improve anything and usually makes it worse, since the more rules there are, the harder they are to know, and the less likely they are to get read. WilyD 09:03, 9 July 2020 (UTC)[reply]
  • Oppose As WilyD says, this was first and foremost a bad deletion; what is needed is for admins to follow the policies and guidelines we have (most do most of the time), rather than follow their own interpretations (plenty do too often). It's preventing bad deletions that's important, not changing the rules to make it easier for them to continue to happen. ——Serial # 09:17, 9 July 2020 (UTC)[reply]
    @Serial Number 54129: How would this chang[e] the rules to make it easier for [bad deletions] to continue to happen? Naypta ☺ | ✉ talk page | 09:28, 9 July 2020 (UTC)[reply]
    I don't understand why adding guidance saying basically "If the article is old, chances are a lot of people have seen it and not identified it as a hoax so take a second look and make sure it really is a blatant hoax before applying this criterion." will make anything worse? Thryduulf (talk) 10:37, 9 July 2020 (UTC)[reply]
    The longer a page is, the less well it gets read. And adding special notes for every rare occurance just piles on clutter. If there was some reason to think this was a persistent problem it'd be different, but this is closing the barn door after the horse escaped ... via a secret tunnel. It wasn't the problem in this one instance, and it's not an ongoing problem. WilyD 12:22, 9 July 2020 (UTC)[reply]
  • I'm definitely opposed to actually tightening the guideline; my read on the specific Battle of Ceber incident is that it was a bad deletion based on several parties under-rating the meaning of the word "blatant". It was therefore already not really an appropriate G3 candidate as the rule is currently written. The proposed reminder about thinking extra hard about non-recently-created pages is perfectly reasonable advice, but I do see WilyD's point about it just being another piece of clutter in an already long and complicated page. This is the first genuinely wrong G3 hoax deletion I've seen in a while, I'm not sure it's even warranted. I'm fairly neutral either way on that one. ~ mazca talk 15:22, 13 July 2020 (UTC)[reply]
  • Oppose. I don't find the justification compelling enough for this criterion specifically. Any speedy deletion criterion is less likely to apply to a page with greater longevity than a page more recently created, because the premise is longevity indicates acquiescence. If we want to include that advice for speedy deletion generally, I'd find that acceptable. --Bsherr (talk) 00:21, 14 July 2020 (UTC)[reply]
  • Oppose new policies to prevent the stupid thing Bob did once. Guy (help!) 09:05, 14 July 2020 (UTC)[reply]
  • Oppose, no real need to change policies and tie admin hands further. Stifle (talk) 09:58, 23 July 2020 (UTC)[reply]
  • I agree in principle with the revised wording, but also with the oppose comments above that this may not be required. I'm left somewhere in the middle. We should expect some sensibility from admins to exercise reasonable and proper discretion, given the process they go through for the right. Unless there's a pattern of improper G3 deletions (there might be?) I don't know if this is required? ProcrastinatingReader (talk) 11:35, 23 July 2020 (UTC)[reply]
  • One cannot count on the nominator to WP:BEFORE. Admins must also perform due diligence-- look at past revisions and consider the possibility of vandalism. It does not hurt to Google search as well. One should view with skepticism the idea that an article that has been around for years is a hoax.04:28, 20 August 2020 (UTC)

Proposed new criteria for articles copied from draft to mainspace without attribution

Per Wikipedia talk:WikiProject Articles for creation#Copy-Paste from Draft into Mainspace, User:Robert McClenon and others have observed instances in which an article is created in draftspace and review is sought, the draft is declined, and then another editor posts a copy of the draft in mainspace. I gather that the subjects posted are usually commercial, raising the specter of paid editing as the motivation for this odd sequence of events. Either way, one editor copying another editor's draft to mainspace without attribution clearly violates the GFDL, and creates a mess of issues raised in the linked discussion. Wherever this happens, it should be a speedy case, even if none of the existing speedy deletion criteria apply. BD2412 T 02:50, 11 August 2020 (UTC)[reply]

  • I don't oppose a WP:NEWCSD if it doesn't overlap, but to check: Does the following cover the problem?
(1) If it is a clean copy-paste, meaning no new edits to the draft after the copy paste, then solve everything with a WP:History Merge; or
(2) If it is messy, messy to fix with a history merge, or messy as in it doesn't belong in mainspace, then WP:CSD#G12 the mainspace page.
The another editor must be confirmed, because they created a new mainspace page? Threaten to block them (gently or escalate) for the copy-pasting in future, refer them to WP:MOVE.
This is a reminder to not delete duplicates, if there is any chance of losing the required attribution history. If in doubt, redirect, and fix later. --SmokeyJoe (talk) 03:02, 11 August 2020 (UTC)[reply]
I would guess that the article-space version would have the usual modifications of an article moved from draft to article space (draft templates removed, dormant categories made active). The issue raised with a history merge in the prior discussion is that it creates a false report that the article has been reviewed. If it is merged from draft to mainspace, the article is in mainspace despite not being accepted as a draft. It could be moved back to draftspace at that point, but that's more work to accommodate a mainspace version that never should have existed. BD2412 T 03:29, 11 August 2020 (UTC)[reply]
An alternative to 2b - doesn't belong in mainspace - that's sometimes appropriate is to history merge into the draft. I happened to do one such earlier today, as an alternative to either deleting as R2 (it had been redirected to the draft version by another editor and left that way, which is how I found it) or G4 (a very recent AFD had been closed as draftify). As I understand it, that should also fix the inadvertent autoreview. —Cryptic 03:34, 11 August 2020 (UTC)[reply]
It would be useful to have a policy statement somewhere that explicitly lays this out as the correct solution. By the way, I have no disagreement with SmokeyJoe's comments on dealing with editors who carry out such copy-paste moves. BD2412 T 03:41, 11 August 2020 (UTC)[reply]
I think we must already, somewhere - WP:CUTPASTE is procedural instructions, not policy, and even WP:Moving a page is the same. The only wrinkle here is that sometimes you don't want to leave the end result in the main namespace. —Cryptic 03:53, 11 August 2020 (UTC)[reply]
I did look at WP:CWW (guideline) which indicates using templates... Jo-Jo Eumerus (talk) 08:05, 11 August 2020 (UTC)[reply]
Thank you, User:BD2412. New CSD criteria should be: objective; uncontestable; frequent; nonredundant.
  • Objective - Copied from draft to mainspace without attribution seems clear.
  • Uncontestable - Something needs to be done when this happens, because the copying without attribution violates the GFDL.
  • Frequent - I do not have statistics, but it has happened several times in the past two weeks, and I will report each time that it happens.
  • Nonredundant - Yes. At present it requires a histmerge, a PROD, or an AFD.

Robert McClenon (talk) 03:56, 11 August 2020 (UTC)[reply]

By the way, there are at least two possible reasons for a copy without attribution from draft space into article space. The first is plagiarism, one editor ripping off another. The second is improper collaboration, meatpuppetry or sockpuppetry. Robert McClenon (talk) 03:57, 11 August 2020 (UTC)[reply]
I can imagine a new editor unaware of the page move protocol thinking that this was the correct way to move the content from a draft to an article, without ill intent, though I would be hard-pressed to believe that with an editor with any amount of experience. BD2412 T 04:07, 11 August 2020 (UTC)[reply]
  • This isn't typically a situation where we'd want to delete the page. The attribution issue can be fixed with a single edit (WP:CWW), so that's not a great reason for deletion. If the draft was declined at AfC then there's likely to be something wrong with it, but there isn't anything stopping any editor from moving a declined AfC draft to mainspace. Hut 8.5 18:25, 11 August 2020 (UTC)[reply]
  • This is excessively complicated. The much easier solution is to history-merge the pages and move the resulting page back to the original location. If abuse is suspected, create-protect the article. I can't say I do it all the time but I've definitely done it. Ivanvector (Talk/Edits) 18:33, 11 August 2020 (UTC)[reply]
    • If you history-merge the pages, and then move them back to draftspace, that is an action that many would perceive as a de facto speedy deletion. Apparently some editors question whether they can do this without it being laid out in policy. BD2412 T 20:05, 11 August 2020 (UTC)[reply]
  • I'm not seeing the non-redundancy with WP:CSD#G12. A recently created blatant non-attributing fork? CSD#G12 does not explicitly exclude "fixable", and if the fix is more work for a negative result than deletion, that seems completely reasonable. --SmokeyJoe (talk) 03:31, 12 August 2020 (UTC)[reply]
    • Could G12 be slightly expanded, then, with a statement like "including unattributed copying within Wikipedia"? My sense is that a lot of people don't think of this as a "copyvio" in the way they think of copying a chunk from some commercial website. BD2412 T 04:55, 12 August 2020 (UTC)[reply]
      • Unattributed copying within Wikipedia is easily fixed by adding an attribution. In probably most cases, you shouldn't be deleting copying within Wikipedia, you should be teaching the person how to do attributions correctly. It's a baby bathwater casse. WilyD 05:04, 12 August 2020 (UTC)[reply]
  • A WP:ATD possibility is to draftify, redirect to the source draft version, and warn the editor. —SmokeyJoe (talk) 07:34, 12 August 2020 (UTC)[reply]
  • In addition to those reasons brought above by Hut 8.5 and SmokeyJoe as well as others, this would be a fundamental change in policy. As Hut 8.5 correctly points out, AFC is not a requirement for new articles and there is no rule that a declined or non-reviewed draft cannot be placed in mainspace anyway. Creating a speedy deletion criterion like that would essentially create such a rule for copy and paste moves. The correct way to handle such articles imho is to merge the history for attribution purposes and then handle it as one would handle it if it had been moved to mainspace or created there in the first place. There appears to be no policy based reason to handle copy and paste moves differently from actual moves (with regards to speedy deletion). After all, most new editors are most likely not aware of such things as attribution and the "move" button. Regards SoWhy 08:15, 12 August 2020 (UTC)[reply]
  • Is there a technical preventative solution. When a large amount of text is added to a page, software checks for that the text is not a very close match to a preexisting page. If it does, warn the editor about copy-pasting. —SmokeyJoe (talk) 08:20, 12 August 2020 (UTC)[reply]
    • An edit filter might be able to do that, but comparing the text with every existing page sounds like it would be very expensive (computationally) to do, especially if the requirement is for a "close" match rather than identical, remembering that the comparison would have to be done for every edit. There is also the possibility of false positives, especially when splitting an article or creating one that is very similar to an existing one (e.g. someone creating articles about a set of items - railway stations on a new line, individual year editions of award shows, warships of a certain class, etc) - although not all of these should not be separate articles it is always something that requires human judgement. Thryduulf (talk) 09:21, 12 August 2020 (UTC)[reply]
  • To the original point - if the only "bad edit" happening is a copy-paste move, I'd think the best resolution would be to move the history to fix it - not speedy deletion. If the content is otherwise not appropriate, other deletion criteria should already be able to be used, basically the copying part itself isn't really the problem requiring speedy deletion. — xaosflux Talk 14:53, 13 August 2020 (UTC)[reply]
  • I object strongly to this, or any part of it, being made into a speedy deletion criterion. The only actual problem, the loss of attribution, is almost trivially easy to fix using m{{Copied}}, or one of the other methods listed in WP:CWW, or with a history merge.
    BD2412 says above that a history merge creates a false report that the draft was approved by an AfC Reviewer. It does nothing of the sort. An approving AfC reviewer leaves several specific entries in the page history, which a history merge would not, as well as adding an AfC banner to the new article talk page, which this would not do. One of those normally uses the words "approving AfC draft" in the edit summery. If a non-reviewer took the significant trouble to fake those entries, and knew how to, that is a very different problem than any discussed above, and I have not heard of such a thing. (Note that only approved reviewers and admins can use the AfC review script normally used for such approvals.)
    Robert McClenon wrote above of improper collaboration, meatpuppetry or sockpuppetry. What excludes perfectly proper but ignorant collaboration? That is, an editor thinking in good faith that a draft should be moved to mainspace and that a copy&paste move was an acceptable way to do that. I have seen semi-experienced editors who thought a copy&paste move was an acceptable way to rename a page in good faith. I have even seen experienced editors advise others that where there was no attribution issue -- where the editor involved had made all significant edits to the page -- a copy&paste move was perfectly acceptable, and editors getting such advice may not understand the limitations on it. Please to remember to WP:AGF.
    Several of the above comments seem to assume that is is improper to move a page from draft space to mainspace without AfC approval, or that it is improper to move a page submitted for AfC review and declined by an AfC reviewer to mainspace without approval. That is not correct. Any autoconfirmed user who believes in good faith that a draft is ready for mainspace may make such a move at any time. AfC is not draft jail. We discourage doing so, because unless the reviewer is incorrect, such a page is likely either to be speedy deleted or deleted by AfD fairly promptly. If it survives an AfD, the move is justified in hindsight. Even if not, until we require non-autopatrolled users to start all new articles in draft space, and use AfC (which I have heard proposed), a user is entitled to take the risk of deletion is s/he so chooses. The creating user does not WP:OWN a draft.
    I would have no objections to some project-space page, perhaps a guideline, perhaps a mere supplemental page, spelling out how to hanle this case. In my view, such a page should say something like:
    1. If the nbew mainspace page clearly fits any of the speedy deletion criteria, such as A7 or G11, it may be tagged and deleted just as if it were not a copy.
    2. If not speedy deleted, fix the attributions, by using {{copied}} or a dummy edit, or a history merge. Consider redirecting the draft to the mainspace article.
    3. If the mainspace page does not seem a proper article, use PROD or AfD to suggest deleting it; the draft copy can in that case remain for futher work.
    4. If the copying editor was clearly trying to game the system and knew better, having been previously warned about such actions, that would be disruptive editing and could be dealt with as such.
    That is my view of the way that this sort of thing should be handled. DES (talk)DESiegel Contribs 16:26, 13 August 2020 (UTC)[reply]
  • Oh, an edit filter was mentioned above as a possibility. That could be done. This is not then plae for detailed discussion of a new proposed filter, and I am not an expert in creating filters. But do remember that a filter must be run on every edit in the project, and that if a filter runs too long, the result is that later filters (or maybe all filters) are simply not run and edits that would have been caught by a filter go through. Anything that must check other pages that the one where the edit is being made adds to the time-cost of a filter, I believe, and needs a storng justification. many filters do a quick check for auto-confirmed and exit early if an editor has that right. A filter for this could not do that -- I suppose it could check for extended-confirmed and exit early in that case. The edit filter people generally want diffs of say 10-20 instances that the filter would block, to design the most efficient tests possible. DES (talk)DESiegel Contribs 16:34, 13 August 2020 (UTC)[reply]
    @DESiegel: not to dive too down a technical hole, but I'm not seeing a variable for an edit filter to say "IF (this added text) IS PRESENT IN (any other page)" - did you have an idea around that? — xaosflux Talk 16:55, 13 August 2020 (UTC)[reply]
    xaosflux I think you know edit filters much better than I do. Perhaps I was wrong when I wrote above That could be done. But I would think that that when an edit creates a new page X in the article name space, a filter could check if a page Draft:X exists, and if so if it is identical to the content of X. The more we want that comparison to be "fuzzy" -- that is to detect content that is similar but not identical -- the more expensive such a filter would be, I would think. But if it is limited to checking a draft page with the identical name, as was suggested above, I would think it was possible. Whether this happens enough and is a big enough problem to justify an edit filter is another question. I tend to doubt it, myself, but that would be discussed on the edit filter noticeboard, I would think. DES (talk)DESiegel Contribs 17:13, 13 August 2020 (UTC)[reply]
    @DESiegel: That's above the capability of the edit filters - but like I noted above, it is something that perhaps one of the copyright violation bots could take up (they are a bit 'slower' since they work off of recent changes feed and won't actually prevent the save), but catching and tagging this type of action may be enough to address the problem? — xaosflux Talk 18:55, 13 August 2020 (UTC)[reply]
    Very well, it seems I was mistaken about the possibility of an edit filter. A bot might be a goodf way to deal with such cases, either a new bot or an add-on to an existing bot, but this isn't really the place to discuss that. In any case, I still think that a new CSD is not the way to handle such cases, nor is deletion under G12, when attribution can easily be provided. DES (talk)DESiegel Contribs 22:25, 13 August 2020 (UTC)[reply]
  • I strongly oppose this, this is a violation of the principle that any autoconfirmed user can move an article to mainspace. Devonian Wombat (talk) 10:49, 15 August 2020 (UTC)[reply]
  • I also oppose this. These moves should be treated like any other moves. If it's a copy paste move, fix the attribution issue. If it's not, there's no problem with it. If another CSD applies, use that. If not, prod/AFD. Calliopejen1 (talk) 16:34, 19 August 2020 (UTC)[reply]
  • Oppose. Don't see why this is necessary when a history merge fixes the problem of attribution. SD0001 (talk) 02:34, 20 August 2020 (UTC)[reply]

Proposal: Deprecate P1 and P2

I am a big opponent of WP:CREEP, and one way to oppose instruction creep is to remove processes that are no longer needed or used. These two criteria certainly qualify: after last year's portalspace paredown, I don't think we have had any portals deleted under either of these criteria, and certainly not a volume that exceeds MfD's ability to handle, easily, any that come up in the future. I look at it this way: if proposed today, would either of these criteria be added as CSD criteria? Certsinly not: both would fail the frequency requirement easily. We can always revisit and consider re-adding in the unlikely event this is no longer the case at some future date. Thoughts? UnitedStatesian (talk) 02:17, 21 August 2020 (UTC)[reply]

  • Comment With just 500 portals around, its indeed questionable whether any P* criteria can meet the frequent criterion. SD0001 (talk) 07:12, 21 August 2020 (UTC)[reply]
  • All P1/P2 speedies. Since there aren't any other portal-specific criteria, we don't have much to gain from removing these unless they're being abused. I don't see evidence of that. Certainly, we don't want to divert A7s into the just-as-indexed portal namespace once self-promoters discover how much more work it's become to remove their autobiographies from there than it is to write them. —Cryptic 10:35, 21 August 2020 (UTC)[reply]
I assume that applying an MfD tag to a Portal immediately NOINDEXes it, correct? UnitedStatesian (talk) 01:59, 23 August 2020 (UTC)[reply]

Where is U4?

I am asking where is CSD U4? I only saw U1 U2 U3 and U5. -- PythonSwarm Talk | Contribs | Global 00:51, 24 August 2020 (UTC)[reply]

PythonSwarm, U4 was rescinded yonks ago. Wikipedia:Criteria_for_speedy_deletion#Obsolete_criteria. Adam9007 (talk) 00:59, 24 August 2020 (UTC)[reply]
Yonks? You mean years, right? Glades12 (talk) 05:58, 24 August 2020 (UTC)[reply]
Sorry, I didn't know that yonks was a word. Glades12 (talk) 06:00, 24 August 2020 (UTC)[reply]
Alternatively, make a link to WP:CSD#U4 and see where it takes you. --Redrose64 🌹 (talk) 17:09, 24 August 2020 (UTC)[reply]

G6 as applied to draft duplicates and redirects from typo in the draft namespace

Hey folks, could I please get some guidance on WP:CSD#G6 as applied to the draft namespace, specifically with regards to:

  • drafts which are near duplicates of another draft (may or may not have the same author(s)) (example)
  • redirects in the draft namespace which were created as a result of page move to fix a typo in the title (redirect target is either in the draft or article namespace) (example)

I've noticed several editors routinely nominating such pages for deletion. The admin response is all over the place, with some choosing to delete and others choosing to decline. Is it ever appropriate to apply G6 (or any speedy criterion) in any of the above cases? -FASTILY 05:19, 25 August 2020 (UTC)[reply]

drafts which are near duplicates of another draft: definitely not a G6. It's better to redirect the less-developed draft to the other one, so that the content remains visible in history so that it can be merged if necessary. SD0001 (talk) 06:07, 25 August 2020 (UTC)[reply]
Agree with SD0001 wrt duplicates. As for redirects, WP:R3 does apply to draft namespace as well and should be able to handle those redirects that are created from moves of recently created pages. For other redirects, the footnote in R3 does indeed point to G6 for obviously erroneous redirects. The reason R3 excludes other redirects that stem from page moves is to avoid breaking external sites linking to Wikipedia. With most drafts however, that should not be a problem, so that deletions should be okay. Regards SoWhy 06:50, 25 August 2020 (UTC)[reply]
In the cases of recently created drafts that duplicate the topic of an existing draft, (and I intentionally echo the language of criterion A10), these seem to me to be obvious speedies: why would he draft space be more retentive that the article space? In the case where the drafts have the same author, we see this all the time where a promotional editor appears to be trying to game the system by creating multiple drafts on the same topic, and speedy deletion is the obvious (to me) choice for the "extra" draft (or drafts). But even in the case of multiple creators, the case of redirecting seems weak, since the resulting redirect would then be subject to G6 (via R3's footnote) as an obviously erroneously titled page: why add the extra step instead of simply speedily deleting the extra draft? If editors are uncomfortatble with using G6, I will propose a new category (D10, to parallel A10?) to cover cases of recently created draftspace pages that duplicate the topic of an existing draft. UnitedStatesian (talk) 13:20, 25 August 2020 (UTC)[reply]
By R3's footnote, G6 is only for redirects created as a result of erroneous page moves. I don't see how the resulting redirect in this situation would be G6-eligible. Redirecting it or leaving the page as-is for an eventual G13 deletion are the options we have. SD0001 (talk) 14:40, 25 August 2020 (UTC)[reply]
Point of clarification: I think the redirect deletion can be done speedily when a page is moved from an incorrect title. Certainly there was no reason not to speedily delete Draft:Kkk when it was correctly moved to Draft:Government spending and economic growth in the United States. In such cases, the move is not erroneous, it is the original title/resulting redirect that is. UnitedStatesian (talk) 17:29, 25 August 2020 (UTC)[reply]
In my opinion G6's in draftspace should be pretty rare. I think its generally ill advise when there two independent or related draft articles on the same topic due to attribution requirements. Redirects are generally okay but probably best left to die naturally unless a specific need arises or perhaps someone else has moved something to mainspace a while ago. Draftspace should generally self-clean itself after 6/9 months or so or so I thought. Excessive CSD:G6 could be an indicator of someone truing to skew their edit count. Allow G6 which someone has a technical need; and then scutinise for plagiarism and non-attribution. Djm-leighpark (talk) 13:43, 25 August 2020 (UTC)[reply]
The rule of G6 is: If any reasonable person would raise an objection that isn't just a mere misunderstanding, it's not a G6. If you anticipate a misunderstanding, consider pre-emptively clarifying things in the deletion log. To use a made-up example, if you are deleting the mis-spelled redirect of Draft:John Smitth to make room for a bio of someone who actually has that name, consider logging it as: "Deleted Draft:John Smitth (now Jon Smitth), to make room for draft bio of John Smitth, a world-champion 18th-century Scrabble player." davidwr/(talk)/(contribs) 18:48, 25 August 2020 (UTC)[reply]
  • @Fastily: IMO, you made the right call on both examples. Steel1943 (talk) 21:10, 25 August 2020 (UTC)[reply]
  • In my view, the normal response to any such more-or-less duplicate draft should be redirection not deletion, whether by speedy or by MfD. I routinely opt for "keep but redirect" at MfD for such drafts, and would probably decline a G6 for such cases. There are several reasons for this:
    1. If the draft was created in good faith, the redirect lets the editor who created it know where the content is and where any new work should be done in an easy and natural way, harder to get wrong than needing to read and understand a deletion log entry.
    2. If the draft was created in an attempt to game the system, the redirect leaves it obvious to anyone checking the record of the user what happened, while a log entry might more easily be missed.
    3. If the two drafts are on the aME TOPIC BUT ARE NOT IDENTICAL, A redieect leaves the content available in the history, where it can be merged into the remaining draft.
    4. R3 applies only to "typos" or in general errors of naming. "John Smith (Printer)"is not an error for "John Smith (Publisher)", particularly if the subject was both. "Jane Roe (Singing)" is not an error for "Jane Roe (musician)".
    5. G6 should not be needed unless such a redir is obstructing a move, or perhaps if an editor is tendentiously reverting the redir to a competing draft without discussion. And then I think an MfD would be better than a G6, or perhaps protection of the redir.
    6. A redir can be created by any user, there is no need to involve an admin. It is more transparent. It has no real downside.
    7. Redirection is out standard response to separate pages on teh same topic.
    In short I see no value in speedy deletion for such cases, and significant downsides. Indeed I might be tempted to bring such a deletion to DRV. DES (talk)DESiegel Contribs 22:06, 30 August 2020 (UTC)[reply]
  • Oppose G6 creep. G6 should not cover unimportant unnecessary deletions like draft duplicates. There is no need to delete, WP:ATD-R applies. Knee jerk deletions are likely to confuse newcomers when they can't find their contribution history, and there is zero explained benefit. Duplicates should be fixed by redirection as a normal edit. If more is required, write a better edit summary. More generally, G6 should not apply to anything with a non-trivial edit history. Does it? --SmokeyJoe (talk) 23:22, 30 August 2020 (UTC)[reply]
    • SmokeyJoe G6 should not apply to anything with a non-trivial edit history. Does it? Yes. If an article is merged into another, and a redirect is left that has a non-trivial edit history, and a new draft of an article that properly belongs at that name is created and approved, a G6 will be needed to clear the name for the draft to move to mainspace. But clearing the way for proper page moves is the only case I can think of where G6 should apply to a page with a non-trivial edit history. DES (talk)DESiegel Contribs 04:08, 31 August 2020 (UTC)[reply]
      • I don't think that's right. G6 for page moves is used for deleting recently auto-made trailing redirects, and temporary third pages for title swaps. If the redirect has a non-trivial page history, it should be moved to a disambiguated title and redirected, not deleted. --SmokeyJoe (talk) 05:07, 31 August 2020 (UTC)[reply]
  • I generally think that admins should have a fairly strong mop when it comes to deleting cross-namespace redirects that are likely to be of questionable utility and are potentially of negative utility. We don't have a PROD for redirects, so what is the alternative? Sinking time at RfD, perhaps MFD? BD2412 T 04:58, 31 August 2020 (UTC)[reply]
    • The only cross-namespace redirs which there is general consensus should not exist are ones out of the main article space to somewhere else, I think. Any other sort would need a deletion discussion IMO, unl;ess they clearly fit one of the other CSDs which would not normally be the case. G6 is not "I think it is unbhelpful". Obtaining consensus where there is no pre-existing consensus is not a waste of time IMO. DES (talk)DESiegel Contribs 23:05, 31 August 2020 (UTC)[reply]
  • Oppose per DES and Smokeyjoe. This fails the uncontestable requirement that almost pages that could be deleted using it should be. Thryduulf (talk) 10:24, 2 September 2020 (UTC)[reply]
  • Most of these will be eventually G13/G8-deleted (like many other drafts), or can be deleted after mainspacing the draft. Speeding up these deletions seems busywork without much benefit. —Kusma (t·c) 16:34, 2 September 2020 (UTC)[reply]

Possible exception to applicable criterion involving "File:" namespace redirects

As I was reviewing some of my old edits, a thought came to me: If one of the reasons why WP:FILEREDIRECT exists is to prevent external linkrot, then I suppose by default, in most cases, that means any redirects that are {{R from move}}s from the "File:" namespace should not be eligible for speedy deletion if they have been around for a long period of time. So ... with that being said, it seems there should probably be a few criterion that should not apply to redirects in the "File:" namespace.

From what I'm seeing per my aforementioned comment, the criterion which should probably not apply to redirects in the "File:" namespace where either the redirect has existed for a "long period of time" or the target "File:" page had been at the redirect's title "for a long period of time" are G6 and G7. (Note: Criterion R3 already covers some cases of {{R from move}} redirects in the "File:" namespace since it relies on the age of the redirect or target page, and thus will not be mentioned any further here.) Here are some example scenarios on why these three criteria (not in conjunction with any unmentioned criteria) seem to cause issues if "File:" namespace redirects are deleted due to them:

  • G6: An editor notices that an image of a dog chasing a ball had the name "File:Usnjestybxsthb.jpg", and thus renamed it "File:Dog chasing ball.jpg" per reason "2" for renaming a file. However, the file had been sitting at "File:Usnjestybxsthb.jpg" for about 5 years, so even though the title makes no sense, that does not necessarily mean there are no external links to the title.
  • G7: An editor uploads a file in 2010 at "File:Abc.jpg", and no one else edits it. About 10 years later, the file uploader moves the file to "File:Xyz.jpg". Since the file had been sitting at "File:Abc.jpg" for 10 years, the file could have external links to that title.

...So, I'm proposing that the G6 and G7 criteria have exceptions added for redirects in the "File:" namespace where the redirect is a {{R from move}} and either:

  1. The redirect has existed for a "long period of time", or
  2. The target "File:" page had been at the redirect's title for a "long period of time"

Steel1943 (talk) 20:21, 25 August 2020 (UTC)[reply]

Is "unsalted" necessary in G8?

G8 currently includes: "Unused editnotices of non-existent or unsalted deleted pages"

This would seem to imply that we do allow editnotices to be retained for titles that are protected against recreation. Does that describe current practice? This seems a bit strange to me, given that it is somewhat redundant to protection-reason summaries.

For sake of due diligence, I searched the archives and found all mentions of the exact word "unsalted" to concern other criteria. I glanced briefly at some revision history. --SoledadKabocha (talk) 04:04, 26 August 2020 (UTC)[reply]

I can see having an edit notice for a salted page explaining why the page has been salted and what the user interested in writing about that subject should do. It might not be done often, but it does make sense. Primefac (talk) 09:42, 26 August 2020 (UTC)[reply]
It was added 28 June 2016 here by User:Andy M. Wang. —SmokeyJoe (talk) 10:03, 26 August 2020 (UTC)[reply]
So it looks like the BOLD addition was basically intended to allow non-controversial deletion of edit-notices, previously unmentioned by G8, by pre-excluding any even slightly contentious cases. The whole thing seems sensible to me, while I'm not sure if there are many examples of salted pages with editnotices, it seems like a reasonable possibility, and hence worth it to avoid making it an unambiguous speedy. ~ mazca talk 22:32, 26 August 2020 (UTC)[reply]

R3 and malformed parenthetical qualifiers

Is R3 intended to cover cases where a parenthetical disambiguation qualifier is missing its closing parenthesis? If so, is the (vague) recency requirement waived as long as the redirect has no incoming links? Otherwise, has the vagueness already been discussed somewhere?

I have a specific example at hand, but to avoid any appearance of impropriety (i.e., an end run around the normal deletion process) I won't mention it here. I did verify that no move is involved. --SoledadKabocha (talk) 18:21, 31 August 2020 (UTC)[reply]

Practical question: How can you be sure that it has no incoming external links? Regards SoWhy 18:30, 31 August 2020 (UTC)[reply]
I recognize that such external links are frequently generated by various forum software that doesn't recognize certain punctuation as being a normal part of an URL, but I didn't think that was relevant - where the problem really is just an omission of a closing parenthesis, the reader should be able to fix it manually. I admit this was sloppy logic, and I am willing to drop the issue, even though there are some parts of my original question(s) that this doesn't cover. --SoledadKabocha (talk) 20:09, 31 August 2020 (UTC) (+ 21:50, 31 August 2020 (UTC))[reply]
I am not clkear. If this isn't a redir from a move, how did it occur if that is known? Is this Example (type points to Example (type)? Or Example (type points to Example (kind)? Or Example (type points to Example? Or what? DES (talk)DESiegel Contribs 22:57, 31 August 2020 (UTC)[reply]
It's the first one - the specific redirect I had in mind is Punch-Out!! (NES, for which it is trivial to check Special:WhatLinksHere and Special:Log to verify that it has no incoming wikilinks and is not a move. I eventually decided against nominating it for deletion, precisely due to the concern of external links as I described above. --SoledadKabocha (talk) 23:55, 31 August 2020 (UTC) (+ 23:58, 31 August 2020 (UTC))[reply]
SoledadKabocha, if such a redirect gets brought up to WP:RFD, then barring exceptional circumstances it will almost certainly result in unanimous deletion (examples: 1, 2, 3). R3 wouldn't apply unless the redirect was recently created, and I'm not aware of any exceptions to this recency requirement. – Uanfala (talk) 22:17, 15 September 2020 (UTC)[reply]
Is there a bright-line quantitative rule for R3's recency requirement, or does it require checking other things such as the creating user's contributions in combination with common sense? --SoledadKabocha (talk) 23:55, 15 September 2020 (UTC)[reply]

RfC: Clarification for G5

I want to ask what is the minimum limit for the substantial edits criteria, because a bad faith editor can add some minor edits, so it does not meet G5. e.g: A banned editor A created a page, and another B added a null edit by appending <!----> to the end. Should this page still meet G5? This RfC is for reaching consensus or uniamity about this problem. -- PythonSwarm Talk | Contribs | Global 10:01, 6 September 2020 (UTC)[reply]

  • Unless I'm mistaken, substantial edits means additions of content or changes in content. More than copy editing, minor edits, and application of maintenance tags, etc.. A null edit as described is certainly not substantial. --Deepfriedokra (talk) 10:17, 6 September 2020 (UTC)[reply]
  • A substantial edit is a bit vague, but how would one draw a line? I would expect it to at least visibly change the content of the article, but a large removal of content could be a substantial edit, as could a large addition, but how large? Adding a reference? If it contributes to verifiability, generally yes, if it establishes general notability, yes, if it merely duplicates a dubious source, no. · · · Peter Southwood (talk): 11:40, 6 September 2020 (UTC)[reply]
  • I have always applied it as 'no addition of content', excluding typo fixing, categorisations, fact-tagging, bot-edits, addition of maintenance templates, infobox inclusions (where all info is taken from the article), moving parts around (copy-edit), spelling/grammar corrections, wikilinking, disambiguations, additions of 'short description', stub-tagging, and format fixes(, etc. etc). I really expect that there is at least a good part of a sentence of new facts being added (so I still regard something like 'she was born in Moscow' to 'she was born in Moscow, Russia' as non-substantial). In case I doubt I will tag only and have a second pair of eyes on it. Note that I have deleted pages that have sometimes up to 10-15 'maintenance' edits after the creation by the sock under G5, as there were no edits that actually changed content. --Dirk Beetstra T C 12:11, 6 September 2020 (UTC)[reply]
  • This doesn't have to be an RFC; there's no dispute here. The idea that some admin somewhere would decline a G5 because someone added an html comment is facetious. —Cryptic 13:03, 6 September 2020 (UTC)[reply]
  • Per Cryptic's comment: PythonSwarm, can you point to a specific time you believe G5 was applied incorrectly that this RfC would address? Otherwise, this is just hypothesizing about a situation that I don't think exists. GeneralNotability (talk) 14:20, 6 September 2020 (UTC)[reply]
    @GeneralNotability: I asked PythonSwarm this very question, but at the time of this writing, have not received an answer. --Deepfriedokra (talk) 23:11, 6 September 2020 (UTC)[reply]
    @GeneralNotability and Deepfriedokra: For example the Template:Technical Non redirect page, it has been edited by people while changing content, but nominated for G5 after, although this should be nominated for redundancy and G3. Plus, CSD should not contain anything vague. I was sleeping while you guys asked this question. sry. -- PythonSwarm Talk | Contribs | Global 23:20, 6 September 2020 (UTC)[reply]
    Template:Technical non-redirect has not been deleted. It has no substantial edits. It was tagged for WP:MFD and WP:G5, and then test and WP:G3 tags were added by OP. Those two were removed by Pppery --Deepfriedokra (talk) 23:31, 6 September 2020 (UTC)[reply]
    Just looking at that template specifically, there were zero substantial edits made after the creator saved the page. A TFD and three different people warring over which CSD tags to use do not negate a G5 nomination. Primefac (talk) 23:54, 6 September 2020 (UTC)[reply]
    Of course, if WP:G5 were incorrectly applied, it would be addressable by contacting deleting admin and then WP:DRV --Deepfriedokra (talk) 23:13, 6 September 2020 (UTC)[reply]
  • Why has this gone straight to a full-blown thirty-day formal RfC? I can't find any evidence that the suggestions at WP:RFCBEFORE have been tried, let alone exhausted. That aside, "substantial" is subjective, we cannot define a "minimum limit". --Redrose64 🌹 (talk) 21:09, 6 September 2020 (UTC)[reply]
  • I would agree that a "substantial" change must involve some displayed semantic change in content. A mere change in form (copyediting, and the other things mentioned by Beetstra above) would not be substantial, much less a cosmetic change that has no effect on the rendered article would not be substantial. However, a talk-page not or even an HTML comment to the effect 'I take full responsibility for this article" by an editor in good standing who is not a puppet of the sock should probably stop a G5. I agree with those who question why this went right to a formal RfC. DES (talk)DESiegel Contribs 21:42, 6 September 2020 (UTC)[reply]

Clarified that page-authors can remove their own speedy tags - common sense applies

Changed

The creator of a page may not remove a speedy deletion tag from it. Only an editor who is not the creator of a page may do so.

to

The creator of a page may not remove a speedy deletion tag from it unless he placed it there himself. Otherwise, only an editor who is not the creator of a page may do so..

This is just clarifying some common-sense situations that the previous text seemed to prohibit, namely, editors reverting db- tags they mistakenly placed on pages they authored and editors changing their minds after placing a db-author or db-user tag on a page they created.

If anyone objects, feel free to revert and ping me to discuss. davidwr/(talk)/(contribs) 20:20, 6 September 2020 (UTC)[reply]

No objections here. GeneralNotability (talk) 23:35, 6 September 2020 (UTC)[reply]
No objection to the intent, but I have reworded it to avoid the needlessly gendered language. Thryduulf (talk) 23:46, 6 September 2020 (UTC)[reply]
Thank you. davidwr/(talk)/(contribs) 19:12, 7 September 2020 (UTC)[reply]
Reasonable. · · · Peter Southwood (talk): 03:21, 7 September 2020 (UTC)[reply]
I agree. This is silly. Obviously someone is not going to think it refers to reverting their own mistaken tag. Natureium (talk) 21:45, 15 September 2020 (UTC)[reply]
@Uanfala: I appreciate your point. You've swayed me a little. I'm still in favor of the change, but not as strongly as before. Survey for seasoned administrators: Has this ever been an issue? If not, perhaps this change can be held back until/unless it becomes one, provided there is a general, not necessarily written-down, understanding among administrators that editors can, in fact, remove speedy deletion templates they have placed on pages, even if it was on a page they created. davidwr/(talk)/(contribs) 21:50, 15 September 2020 (UTC)[reply]
Well, the understanding certainly is there for some less obvious cases where creators can remove speedy tags. There was a discussion from a few months ago, and I was thinking of implementing the draft text I proposed there, with the obvious additions of anything that gets decided here. – Uanfala (talk) 22:11, 15 September 2020 (UTC)[reply]
Not greatly concerned either way, but not all of our editors are equally endowed with common sense. · · · Peter Southwood (talk): 06:42, 16 September 2020 (UTC)[reply]

New section - Modules

Since it takes some extra work to ask that a module be speedy-deleted, I drafted a new section called "Modules" then self-reverted. Here is the proposed change. Here is the comment by Primefac on WT:Lua which prompted the change. davidwr/(talk)/(contribs) 23:15, 6 September 2020 (UTC)[reply]

Modules fall under WP:TFD (as far as XFDs go) and by that logic Modules also fall under the Template CSD criteria (which I believe at the moment is only WP:T3). Primefac (talk) 23:55, 6 September 2020 (UTC)[reply]
@Primefac: from memory, applying T3 to modules was discussed and rejected previously although I can't remember why. Thryduulf (talk) 00:02, 7 September 2020 (UTC)[reply]
The first four discussions I found (Archive 51, Archive 70, Archive 72, Archive 73) mostly seem to be concerned about whether it's worth folding them in. In 2019 two discussions basically concluded that Modules were just fancy Templates and could (in theory) be tagged with T3, but since it's a seven-day hold on deletions they might as well go to TFD. In other words, "you can do it but why bother?" Primefac (talk) 00:08, 7 September 2020 (UTC)[reply]
No immediate objections to that, but the comment makes me wonder whether the U set of criteria should also apply to modules in the Module:Sandbox/your userid/ hierarchy since (from my limited understanding) that's treated as a user sandbox space? While a U3 eligible page would be pretty unlikely (if even technically possible) there, U1, U2 and U5 are not implausible. Thryduulf (talk) 23:59, 6 September 2020 (UTC)[reply]
I think the pertinent statement is more about putting the nomination on the documentation subpage; at the moment U, G, and T all qualify for use, which is pretty much all of the relevant criteria (since obviously A/R/F/C/P are namespace-specific). Primefac (talk) 00:04, 7 September 2020 (UTC)[reply]
@Thryduulf: I agree that the "U" criteria could apply to the Module:Sandbox/your userid/ hierarchy with the caveat that the page should not have any significant history of being outside that user's sandbox area. Otherwise, I could take any arbitrary module, move it to my "user sandbox", change the content so it looks like it's not worth keeping, and tag it for speedy deletion. For that matter, ALL module speedy-deletions should have their "move history" and "edit history" checked to make sure the requesting editor isn't trying to "game" the system. Note that normal editors can move modules without leaving a redirect so tracking the move history may take some extra effort. davidwr/(talk)/(contribs) 00:41, 7 September 2020 (UTC)[reply]
But as you state in your penultimate statement, that has nothing to do with the page or the criteria but with the deleting admin actually checking the history. It's the same as when someone moves a page to a new name and then puts it up for "G7". No, you cannot do that and say it's "your page", you moved it and therefore (unless it's an R-eligible move) the redirect needs to stay. I've seen just about every CSD criteria manhandled at some point or another, but that doesn't invalidate its potential usage. Primefac (talk) 01:32, 7 September 2020 (UTC)[reply]
Instead of writing in prose whether you want just the module itself, just the doc page, or both to be deleted, why not recommend using <includeonly> or <noinclude> so that the template and categorization only happen on the page where you want them to? Also, template editors have the option of changing the page's content model and then applying a CSD tag like on any other wikitext page. Do you think that's worth mentioning too? Jackmcbarn (talk) 03:22, 7 September 2020 (UTC)[reply]
Actually, thinking about this some more, I think I have an even better idea, that will allow CSD tagging straight from modules, without needing to change their content model (it will leverage Module:Documentation). I'll try to code that up tonight or tomorrow. Jackmcbarn (talk) 03:27, 7 September 2020 (UTC)[reply]
@Jackmcbarn: If it's practical, can you make this work on .css, .js, and other "code" pages in user-space? If I want to delete the page history of my .css page, there's no easy way to slap a speedy-deletion template on it right now. For that matter, it would be nice if .css and .js pages had a "doc" option so I could write documentation if I'm going to share the script with others or encourage others to import it. davidwr/(talk)/(contribs) 13:18, 7 September 2020 (UTC)[reply]
For what it's worth, I vaguely recall deleting a .css or something similar that had the {{db-userreq}} commented out, but it still "transcluded" (or at least, showed up in the category). That was a few years ago though, so they might have changed how those page classes handle the code. Primefac (talk) 13:22, 7 September 2020 (UTC)[reply]
Templates on CSS/JS pages do populate the categories, but don't have any visual appearance on the script page of course. For sanitized-css (the contentmodel used for TemplateStyles), the template will need to be commented out (otherwise the page can't be saved due to the resulting syntax error). JSON is the only content model which currently is impossible to tag, because once again the page can't be saved with a tag due to the syntax error and unlike sanitized-css, no forms of comments are allowed in JSON, and unlike modules there are no documentation pages also.
For the record, Twinkle can be used for CSD tagging modules (it will put the tag on the /doc page) and for CSS/JS pages (but not for sanitized-css or json pages). – SD0001 (talk) 13:29, 7 September 2020 (UTC)[reply]
JSON does allow comments, if you disguise them as data within an object - see for instance Wikipedia:Geonotice/list.json where the UK20200809 object includes a name/value pair named "comments", which is ignored by the bot that processes the page. --Redrose64 🌹 (talk) 15:58, 7 September 2020 (UTC)[reply]
@Redrose64: Yes, but they don't get parsed as wikitext, so can't be used to add categories. For example, Category:X1 does not list User:Jackmcbarn/sandbox.json as a member. Jackmcbarn (talk) 18:23, 7 September 2020 (UTC)[reply]
My solution for tagging modules without needing to mess with their doc page or content model is now live. You can see a demo at Module:Sandbox/Jackmcbarn/csd. I also submitted https://github.com/azatoth/twinkle/pull/1121 that will make Twinkle start doing this. Jackmcbarn (talk) 18:20, 7 September 2020 (UTC)[reply]
Is this really a good idea? It appears to me to make the process more complicated, in addition to having the unintended consequences of causing every page in module namespace to transclude itself. * Pppery * it has begun... 18:53, 7 September 2020 (UTC)[reply]
@Pppery: Don't most pages these days transclude themselves for one reason or another? And for modules in particular, most of them will anyway because their doc page will contain an example of their usage. And as for complexity, is that a big deal given that most CSD's are done with Twinkle? Jackmcbarn (talk) 19:38, 7 September 2020 (UTC)[reply]
Most article pages transclude themselves via Module:Citation/CS1/Configuration. Most non-article pages don't transclude themselves. Either way, this change still appears to lack a purpose. most CSD's are done with Twinkle is irrelevant, since this change means nothing for CSDs done with Twinkle. For CSDs not done with Twinkle, modules need to be treated differently regardless, and I think using Module:Module wikitext is actually more confusing than adding the deletion tag to the doc page.
The only actual problem presented with adding the deletion tag to the doc page is that some admins are careless, which should not be worked around by the addition of more module creep. * Pppery * it has begun... 19:54, 7 September 2020 (UTC)[reply]
@Pppery: How is this any worse than putting the tag on a different page though? Either way, it's a nonstandard way of doing speedy deletion. (By the way, I like your clever usage of package.loaded in it.) Jackmcbarn (talk) 22:24, 9 September 2020 (UTC)[reply]
It's not really much worse, but it's not really any better either, and this it is not worth the increase in complexity of Module:Documentation in my opinion, especially since the code you added has nothing to do with documentation. As I said above, there was no actual problem with putting CSD tags on the doc page, other than admins occasionally acting carelessly. * Pppery * it has begun... 22:37, 9 September 2020 (UTC)[reply]
👍 Like Great work! – SD0001 (talk) 14:10, 8 September 2020 (UTC)[reply]
This is a conversation for a different place, Jackmcbarn, but I wonder how receptive WP:TFD would be to this as a potential nominating process. ~ Amory (u • t • c) 01:49, 15 September 2020 (UTC)[reply]
@Amorymeltzer: Part of me wants to just WP:BOLDly do it. Jackmcbarn (talk) 02:44, 15 September 2020 (UTC)[reply]
And I'd revert. There's absolutely no problem with the current system of nominating modules for deletion, and this no need for any of this. (and I'm responsible for a large fraction of module nominations at TfD) * Pppery * it has begun... 02:53, 15 September 2020 (UTC)[reply]

"or pages that perform a disambiguation-like function (such as set index articles or lists)."

WP:G14 mentions "or pages that perform a disambiguation-like function (such as set index articles or lists).". Set index articles and lists are Wikipedia articles, and serve as much disambiguation-like function as any other Wikipedia article with wikilinks. They are intentionally not disambiguation-like navigation pages, because the consensus was to add encyclopedic content to them. List articles are valid link targets, and "(disambiguation)" redirects to them should be speedy-able. If editors need links to indicate that the list is intended, the set index article should be moved to the usual "List of " titling, or some correct redirect like "X (list)" or "X (set index article)" should be used instead. I propose striking that phrase from the criterion. -- JHunterJ (talk) 12:09, 16 September 2020 (UTC)[reply]

  • The context is Wikipedia:Redirects for discussion/Log/2020 September 15#Tphoon Mujigae (disambiguation). The page now at List of storms named Mujigae is very similar to a disambiguation page in that it lists all items with the same name. Storm pages are categorized as a "set index article" in Wikipedia, but that's just a technical phrase that non-dab editors aren't aware of that allows these disambiguation-like pages to have a bit more information (such as when the storm name was retired in this case). In cases where we expect there to be a disambiguation, like this one, a "FOO (disambiguation)" redirect is able to point searchers who may be looking for such a page to the correct location. It also has the advantage of preventing a duplicate disambiguation from being created if for some reason, an editor cannot find that page. In the case before us, Typhoon Mujigae (disambiguation) was the name of the page for several years, so the redirect is also a {{R from move}}, which is useful to prevent linkrot, etc. I disagree with the claim that they serve as much disambiguation-like function as any other Wikipedia article with wikilinks. There are cases, such as the one above, where the index or list is clearly disambiguation-like and there are articles where the content is clearly not serving as a tool to distinguish multiple things with the same name. However, where there may be gray area, I think it is best to have it addressed at RfD so I would not be in favor of having this exception removed. -- Tavix (talk) 14:05, 16 September 2020 (UTC)[reply]
  • I agree with Tavix. The line between what is a disambiguation page and what is a set index or a list is one that is entirely arbitrary and completely unknown to most editors, let alone the majority of our readers. Indeed set indexes as a concept independent from disambiguation pages only exist as a compromise between those editors interested in serving the best interests of readers and those editors interested in rigidly enforcing style guidelines about what can appear on disambiguation pages. If someone is searching for "Foo (disambiguation)" they want to be taken to a page that lists encyclopaedic topics that could reasonably be titled "Foo", reasonably be referred to as "Foo" and/or reasonably be found on a list of "Foo", in >99% of cases they don't care whether they arrive at a disambiguation page, a set index or a list, as long as the page they arrive at lists the things they are looking for (it could be they are looking for the list of things, or it could be that they are looking for a specific thing that is unlikely to be the primary topic but they don't know the article title for). This all means that the majority of redirects ending in "(disambiguation)" pointing to set indexes or lists should not be deleted, let alone speedily deleted and so I very strongly oppose removing the exemption from G14. Thryduulf (talk) 15:26, 16 September 2020 (UTC)[reply]
    • I'd agree too, and would suggest that they be styled like navigation pages instead of articles, but I'm in the minority there. On Wikipedia, they're lists with encyclopedic content, and the arbitrariness of the line would be rendered moot by the use of redirects that match the target. If SIAs somehow "need" a redirect that indicates that the incoming wikilink is intentional (even though they are valid wikilink targets, just like any other article), then the "X (set index article)" or "X (list)" wording would solve that. Or they can be better titled as "List of Xs named Y" rather than "Y (X)". -- JHunterJ (talk) 13:19, 17 September 2020 (UTC)[reply]
      • The point is that distinguishing intentional links isn't the only reason these redirects have value - people also navigate directly to them in (at least) the two scenarios I outlined previously: People wanting a list of things with the name, and people wanting to read about something which is not (or they think might not be) the primary topic but which they don't know the title used. This means that even if the target is renamed "X (set index article)", "X (list)" or "List of Xs named Y" people will continue to use the "X (disambiguation)" title to look for it and so the redirect will still be needed. Thryduulf (talk) 01:39, 18 September 2020 (UTC)[reply]

de-PRODded pages still eligible for CSD?

Can CSD still apply to pages whose PRODs were contested? Id est are previously PRODded (or de-PRODded) pages still eligible for CSD? I initially thought about discussing {{dfu}} as opposed to File PROD. However, reading both policies, neither CSD nor PROD seems to address implementing CSD on de-PRODded pages. For instance, an orphaned non-free file is PRODded but then de-PRODded, but then the B-bot automatically tags the file as "orphaned" to be deleted for more than seven days. If the "orphaned" tag is uncontested, either the "PROD only one" is weakly enforceable, or there may be a loophole between CSD and PROD. In another case, what can an admin do to a de-PRODded file currently tagged with "dfu"? Not only files, I have wondered also whether de-PRODded articles are still eligible for CSD. --George Ho (talk) 09:19, 19 September 2020 (UTC)[reply]

I don't believe a PROD precludes a CSD, but usually if an editor feels one of the CSD criteria apply, they would have used it instead of a PROD(as well as a reviewing admin). 331dot (talk) 09:29, 19 September 2020 (UTC)[reply]
I guess it would depend on the criterion, but generally yes. Copyvios, for example. G5 too, especially if the creator was a sock of a banned user that was detected only after the deprod. Reyk YO! 09:33, 19 September 2020 (UTC)[reply]
All right. What about WP:F7 (including dfu), WP:F5, and WP:F11? George Ho (talk) 09:36, 19 September 2020 (UTC)[reply]
I'm not exactly an expert on files, but I would say all of those are still valid even after a deprod. My general feeling is that, because PRODs can be removed for bad reasons or no reason at all, a deprod can't be used to veto a legitimate reason for deletion. This include speedies. Reyk YO! 09:43, 19 September 2020 (UTC)[reply]

Wouldn't any criterion using the seven-day deletion period (like "dfu" and "orphaned non-free") conflict with PROD if de-PRODded files are still eligible for those criteria? Is this conflict (or some sort of loophole?) something to worry about? George Ho (talk) 09:48, 19 September 2020 (UTC)[reply]

  • When I returned from my hiatus, I declined a couple of speedies that had been ProDed based on the assumption that they needed AfD and sent them to AfD where the consensus was that I was an idiotwrong. I've seen no policy or guideline anywhere that says I was right in thinking ProD precludes CSD if CSD is applicable on it's own merits. --Deepfriedokra (talk) 13:49, 19 September 2020 (UTC)[reply]
  • There are so many possible scenarios that it's difficult to see how a set of explicit rules can be codified. On one end of the spectrum there are copyright violations that should obviously get deleted regardless of previous prods, and on the other – speedies using "weak" criteria (like A7 or G6) when the previous deprod was well explained. As a general principle, I would think that "quick" processes that receive little scrutiny should not normally be able to override "deeper" ones that have engaged the community at a larger scale (as prods do). But in most cases, why should we resort to speedy deletion in the first place? If there are concerns that the de-prod was iffy, then just prod the page again: it's better to break the minor technical rule against repeat prodding, than to work in a way that technically isn't prohibited but that goes against the general principles of the project. – Uanfala (talk) 14:18, 19 September 2020 (UTC)[reply]

Can T3 deletions be refunded?

Can deletions per WP:T3 be undeleted via WP:REFUND? Or must they go via WP:DRV? ProcrastinatingReader (talk) 16:43, 19 September 2020 (UTC)[reply]

Explicitly recommending that page movers to do some types of "deletion via move" to avoid delays

SOME DB-G6 "make way for a move" deletion requests can be "split" so the move doesn't have to wait for an administrator.

How?

I have a page ready to be moved from OLDPAGE to NEWPAGE.

NEWPAGE exists and is not a single-edit redirect. I slap a {{db-g6}} on it asking it to be deleted to make way for a move.

A "page mover" verifies the db-g6 is reasonable, moves it to a temporary location e.g. NEWPAGE-ToBeDeleted, updates the rationale of the db-g6, then moves OLDPAGE to NEWPAGE, leaving a redirect or not depending on the circumstances.

I continue working on NEWPAGE, without having had to wait for an administrator.

Later, an administrator deletes the temporary page.

The only reasonable objections I can think of are:

  • There aren't enough page movers to really make this worthwhile (less than 400 vs. thousands of administrators)
  • It makes the page log and deletion log history messier vs. a straight-up "delete and move." Since I'm not an administrator I don't know how "messy" this makes things, so this may be a non-issue or it may be a serious objection.

Thoughts? Did I miss anything? davidwr/(talk)/(contribs) 16:52, 19 September 2020 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Criteria_for_speedy_deletion&oldid=979241839"