This is not the place to contest a deletion or to request a history undeletion. Follow the instructions at Wikipedia:Deletion review. This page is for discussing maintenance issues, proper usage of deletion review, etc.
Just passing by due to a cross-post, but could a script be written to deal with this, similar to how Twinkle takes care of all of the XFD nomination steps? Primefac (talk) 19:50, 12 January 2024 (UTC)[reply]
Over half the time, even the first template ({{drv2}}, on the deletion review subpage (no, there's no {{drv1}})) gets filled out wrong. The deletion discussion isn't linked, or the wrong one's linked, a non-deletion-discussion is linked in the xfd field, or a full url is used for the deletion discussion or page name or both, or even the page name is wrong. Mostly it's me who ends up cleaning it up and placing {{delrevxfd}} and sometimes {{drvnote}}, and the problems aren't consistent enough that I've ever considered automating it. A bot that assumes the first step was done right is going to break at least two other pages and probably end up being a net increase in manual labor. —Cryptic20:42, 12 January 2024 (UTC)[reply]
If anything, it gives more reason to have a script, as there can be #ifexist checks and the like to make sure things are input properly. Primefac (talk) 07:28, 13 January 2024 (UTC)[reply]
Request for undeleting the article: Salman Farhan Sudi[edit]
The article Salman Farhan Sudi was deleted due to several points which should be corrected instead of deletion the whole article, Please I am requeating to undelete that article and return it to discussion.
Retrieval of Deleted Draft Content : YogiGuru Saugaato[edit]
Hi Team,
It is a humble request to help retrieve the content of the draft of YogiGuru Saugaato that was deleted. I require the latest version of the draft and have been unable to retrieve it from anywhere else. There is no copy, and was a dictation version. Kindly share the latest edited draft of the content. I assure it will not be used to published anything on any Wikipedia pages. Debottama23 (talk) 12:12, 20 February 2024 (UTC)[reply]
The draft was deleted because it was a blatant advertisement. Such content is not allowed on Wikipedia. However, if you truly have no intentions of publishing this content on Wikipedia again, it may be possible to ask one of the admins who deleted it, JimfbleakorSeraphimblade, to email its contents to you (note that they are not required to do this) Mach61 (talk) 14:14, 20 February 2024 (UTC)[reply]
Several months ago, I found the following note on my talk page:
An editor has asked for a deletion reviewofFile:The sun1.jpg. Because you closed the deletion discussion for this page, speedily deleted it, or otherwise were interested in the page, you might want to participate in the deletion review.
Would it be worth changing {{DRV notice}} so that - in the absence of the |days= parameter being specified - it assumes that the DRV has been filed on the current day? To my understanding, this is what currently happens with (e.g.) {{Rfd notice}} & {{Tfd notice}}. All the best, —a smart kitten[meow]20:21, 22 February 2024 (UTC)[reply]
I think it would be more harmful to point at the wrong log subpage than to point at DRV proper. If someone notifies late - either because someone yelled at the original requester for not notifying, or they're less of a jerk and are just doing it for them - and the template's not invoked until after midnight UTC, they're left pointing at the wrong page entirely with no hint of what went wrong.
I suspect most people besides me just paste the drv notice syntax from either the log page's commented text or from step II.2 of WP:DELREVD. (I don't, for example, ever recall seeing anything other than "An editor" at the start of the notice when I've checked to see if someone's been notified.) If {{DRV notice}} could accept an explicit date instead of the horrifically unfriendly days=0 syntax, we could make at least the commented text always be right ("<!--Please notify the administrator who performed the action that you wish to be reviewed by leaving {{subst:DRVNote|log=2024 February 22|page name}} on their talk page."...), and the instructions at DELREVD at least be obviously wrong if you're notifying for a previous date. —Cryptic21:13, 22 February 2024 (UTC)[reply]
I'm not seeing an interface for getting the current revision of a page in the Scribunto documentation (I'd expect it to be in the title object). I know it's not possible short of that. —Cryptic23:15, 22 February 2024 (UTC)[reply]
Anyway, the other issue with permalinks is that there's no section edit links unless you're still pointing at the current revision. If Fastily were only now seeing the notification for yesterday's review of File:Wadea al-Fayoume.jpg, the link would look like Special:Permalink/1209451477#File:Wadea al-Fayoume.jpg; that would let him see the discussion but have no way to edit it other than clicking on the only-barely-intuitively-linked date header. —Cryptic19:32, 23 February 2024 (UTC)[reply]
I am asking for a clarification about DEEPER. Within the past 36 hours there was a tendentious DRV request about an actress who had already been the subject of a DRV, in which the AFD was endorsed, and the title was listed at DEEPER. The DRV was speedy-endorsed because it was listed at DEEPER. I agree with the dismissal of the DRV, but would like to confirm that my understanding of DEEPER is correct, and that its purpose is to prevent frivolous DRV requests when there is a history of vexatious or frivolous requests. Is there agreement that DEEPER is meant to be a blacklist against DRV requests? Robert McClenon (talk) 05:19, 5 April 2024 (UTC)[reply]
I think the correct procedure is demanding a presentation of a draft that is prima facie worthy of a review, and if it seems that thre is no prospect for that submission to even be reviewed because it is obviously not worthy of a review, and a few participants have noted so, the DRV can be speedily closed as 'speedy endorse' due to no prospect of success. There must be a path to recreation. We can not know that BDFI will not be a notable topic in the future. If I start believing that BDFI has become a notable topic I will want to create an article, I will be able to draft something suitable for a quick review at DRV, and I will not be satisfied with my submission being dismissed on purely formal grounds (a fantasy scenario, don't take it at face value). —Alalch E.22:16, 7 April 2024 (UTC)[reply]
I proposed at Village pump (policy) that DRV should have, and state that it has, closures of Speedy Endorse for a Deletion Review when the appellant has failed to state a case. On further thinking, I think that what is needed is Speedy Close, similar to the administrative closes sometimes used at XFD, and that the instructions for DRV should list the reasons for Speedy Close. The reason for changing the phrase is that some of the Deletion Reviews to which this should apply are not really appeals of deletion decisions.
I suggest, in particular, that the instruction should say, below "Deletion review may be used" and "Deletion review may not be used", there should be a paragraph beginning "A Deletion Review request may be Speedily Closed if:" followed by:
1. The filing does not appear to involve a deletion action in the English Wikipedia.
3b. The filer does not have permission to edit in the area, e.g., not extended-confirmed when the area is subject to an extended-confirmed restriction.
4. The filing is completely erroneous, e.g., it misstates the number of !votes in the XFD.
We see such requests for Deletion Review from time to time, and they are often administratively closed, but it would be useful to list them as bases for speedy closes, similar to Speedy Keeps at XFD.
I would like to send this provision for Speedy Closes at DRV forward to an RFC to add it to the DRV instructions, after discussion and any changes to the rationales. Robert McClenon (talk) 02:44, 18 May 2024 (UTC)[reply]
Support. While I occasionally procedurally-close disruptive or pointless DRVs, I always feel like I'm treading the gray boundary of policy-sanctioned process. Clear wording will make this more consistent and save us all time. I do, however, have qualms about C#1, which seems to exclude appeals to turn a Keep into a No-consensus or vice versa. While some dismiss such appeals as pointless, they do impact renomination delays, and also act as important feedback, especially in cases of BADNAC. I believe we also need clearer language for a speedy overturn for out-of-process speedy deletions. If any editor in good standing contests a G6, it is no longer uncontroversial maintenance. Owen×☎10:34, 25 May 2024 (UTC)[reply]
You can already do that last bit if you feel strongly enough about it. From WP:Deletion policy#Deletion review: If a page was obviously deleted "out of process" (per this policy), an administrator may choose to undelete it immediately. In such a case, the administrator who deleted the page should be informed. However, such undeletions without gaining consensus may be viewed as disruptive, so they should be undertaken with care. —Cryptic13:24, 26 May 2024 (UTC)[reply]
Admins who routinely delete out of process are the worst ones with whom to get into a wheel war. While policy allows us to revert them, the caveat it spells out should be heeded. A speedy overturn supported by two or three participants is more effective and less prone to prompting a wheel war. This usually happens within a few hours of the DRV being listed, so I don't think we're adding unnecessary wonkery here. Owen×☎13:37, 26 May 2024 (UTC)[reply]
So wait until it racks up those two or three overturns. I don't think that "immediately" language means "only if you do it right after it happens" so much as "without further discussion". —Cryptic13:44, 26 May 2024 (UTC)[reply]
With this proposal, we need to be mindful of two things.
Firstly, DRV is a backstop against various kinds of abuse: things that don't usually happen on en.wiki, but theoretically could -- such as a bad faith user gaining control of a sysop account and using that account to delete inconvenient articles or speedy-keep inconvenient AfDs. As a guard against that, I'd suggest an explicit rule that any sysop can overturn or revert a speedy close of a DRV, on their own authority, with or without giving a reason. (Sysops can revert each other's administrative actions but are usually hesitant to do it. We want wording that empowers and encourages them to use that power here.)
Secondly, DRV has another purpose as well as reviewing decisions. We also explain decisions. An inexperienced user ought to be able to bring a DRV and come away with a clear understanding of all the reasons for a deletion decision, and that occasionally happens. So we want a rule that says that when speedy closing a DRV brought by an inexperienced user, the closer should pop over to their talk page and start a discussion explaining all the reasons why the deletion decision was correct.
Oppose codifying how to run this review process. It should be run by humans, not algorithms. The problem being fixed has not been explained. —SmokeyJoe (talk) 13:01, 26 May 2024 (UTC)[reply]
This is instruction creep, and the worst sort of instruction creep in that it's mostly redundant and the remainder is actively harmful.
#1 is already covered by the speedy close criteria we already have. #2 and #4 are frequently accompanied by the sort of accusations for which we could invoke the other speedy close criterion we have at WP:DRVPURPOSE NOT#8, but for reasons incomprehensible to me we usually don't. #3 is covered by the combination of WP:BANREVERT and WP:ARBECR, doesn't need repeating here, and is already the usual practice if nobody who's permitted to edit has agreed with them yet.
When somebody has agreed, and for the remaining, milder cases of #2 and #4, speedy closing is harmful because deletion reviews are essentially never reviewed or overturned - the buck stops here - and have zero effect on content namespaces while in progress. Even when it's a kept page that's being reviewed and {{delrev}} is supposed to be put on the mainspace page (or category or template or whatever), it's usually forgotten, even by the people who clean up broken and incomplete drv nominations. —Cryptic13:17, 26 May 2024 (UTC)[reply]
With the exception of 4, I IAR close all of these. I'm not sure I need a rule telling me I can't, as I don't think any have even been challenged, never mind overturned. Just my .02 StarMississippi14:30, 27 May 2024 (UTC)[reply]
Uncontroversial REFUNDS should be advised to go to REFUND to ask.
REFUNDS to draftspace are almost always uncontroversial.
REFUND should plainly distinguish between whether the REFUND is to draftspace or to mainspace, and give simple advice on both. REFUNDS to mainspace are rarely uncontroversial, except for late disputed PRODs. SmokeyJoe (talk) 22:53, 15 June 2024 (UTC)[reply]
Natural history - partially deleted category tree[edit]
As a result the category tree is partially deleted and partially extant. Would it be possible to revert the first deletion (as mentioned would be appropriate by a couple people in the second discussion)? I will note that the second nomination got more attention, I think because it included lower-level subcategories that get more "circulation".