Wikipedia:Deletion reform/Proposals/Speedy redirect

This is a proposed rule to added to Votes for Deletion. This is not a solution for VfD's problems, but it will lessen the load:

Speedy redirects
Any editor may close a VfD discussion by replacing the deprecated article by a redirect to a named article. There are three steps to this proceedure:
 * Replacing the article by #REDIRECT Articlename.
 * Adding Template:speedy redirected to the new redirect's talk page.
 * Adding a link to the previous edit of the article to the its vfd page. Suggested form for this is:


 * Speedy redirected to Articlename . Previous text: [link]

The editor may choose to add content to Articlename, so the redirection is more intelligible. This is a normal edit, done at his discretion.

The present policy, that any editor may close a consensus to keep, will remain in effect. If both apply, the VfD should be closed: keep. Once closed, the difference between keep as is and keep as redirect should be resolved like any other editing dispute.

Abuses and suggested rules
Like anything this can be abused. The following abuses and fixes occur to me.


 * 1) Some articles should not be redirected. I do not mean vanity pages, but things like Dumbledore kills Hermione. I doubt anyone would speedy redirect that piece of vandalism, but just in case
 * 2) *Any article on which VfD has a considerable minority opinion giving reasons that it is unsuitable for redirection should not be speedy redirected.
 * 3) If the editor who wrote the non-notable article is really determined, he can take out the redirect, and replace it with the same non-notable content.
 * 4) * If an article has been speedily redirected, and had no notable content, and the redirect is replaced by content substantially identical to what was there before the redirect, it may be speedily deleted
 * 5) Speedy redirection can be used as a merry-go-round to delay deletion indefinitely:
 * 6) *No article which is VfD'd, speedy redirected, rewritten, and returns to VfD, may be speedy redirected again. (within some time limit)
 * 7) A and B dislike an article. A lists it on VfD; B speedy redirects it. What is C, who liked it as it was, supposed to do?
 * 8) *WP:VfU is authorized to review speedy redirects.

If your good article has been VfD'd and speedy redirected, you have three options:
 * go to VfU and explain.
 * take out the redirect and add to the article.
 * show a consensus on the talk page of the redirect to keep the article.

The change to CSD has been deleted by present consensus, but I would be tempted to consider straight unilateral reversion of a speedy redirect to a text with no notable content to be vandalism.

Comments
I would be content to see this approved without the safeguards; but better to disucss them now than after abuse.

Much of the good of this proposal would be accomplished by simply removing "merge" from Template:vfd; or even by making clear that it does not prohibit conversion to redirects. The rest is just recordkeeping. Septentrionalis 19:39, 15 August 2005 (UTC)


 * I like the principle, but I think it could lead to content warring over whether to accept the preemptive redirect or let the VfD continue. I'd really like to see such a decision made by consensus, otherwise people who think Wikipedia would be improved by deleting the article would feel that this was just a way of thwarting this aim.  There would be the suspicion that once the VfD was closed the article could be reverted--that is, the pre-emptive revert may be seen as a tactic to avoid deletion. If we did something like this it would have to satisfy us all that such abuses would be unlikely. --Tony Sidaway Talk  19:25, 15 August 2005 (UTC)
 * I've added Safeguard 3, which may alleviate both of these: One speedy redirect per article.Septentrionalis 19:39, 15 August 2005 (UTC)
 * I agree with Tony's opinion. I don't see how a limit of one speedy redirect solves the problem.  Only a consensus would keep every speedy redirect from returning to VfD.  And speedy deletion would only result in another immediate discussion on VfU possibly resulting in it being moved again to VfD. -  T&#949;x  &#964;  ur&#949;  20:05, 15 August 2005 (UTC)
 * It could also be gamed to force deletion, or used to thwart thsoe who want to keep and expand the articel, it seems to me. See my comments on the talk page for more. I think that in general closing VfDs without a consensus, perhaps even egaisnt an incipient consensus, is probably a bad idea. Why won't this proposal lead to such outcomes? DES (talk) 20:10, 15 August 2005 (UTC)
 * Anyone who wants to use this to thwart the growth of an article on VfD can now wait until the VfD is over and then redirect. If the keep voters have stopped watching, he will succeed. I think this is much the same ploy, to be dealt with the same way; it merely encourages a visible consensus to take out the redirect.
 * I was writing when reverting such a redir was to be grounds for speedy deletion. without that, this proposal is little more than permission to do redirs during a VfD (which I have seen doen anyway, under current policy), and doesn't seem to do much harm (nor all that much good). DES (talk) 20:00, 16 August 2005 (UTC)
 * I thought Safeguard 2 would be the most popular; the deletionists would insist on it. I will wait a little before declaring consensus, but I'm perfectly happy to take it out. Septentrionalis 20:40, 15 August 2005 (UTC)
 * If an article is deserving of deletion, it should be deleted, text, talk and history. For those articles that should have been redirected, this saves five or fewer) days.  For those articles that should be deleted, this makes it harder to see why the article should be deleted.  Small gain, substantial loss.  208.20.251.27 21:04, 17 August 2005 (UTC)  Got logged off again -- that was my comment.  Robert A West 21:05, 17 August 2005 (UTC)
 * If a page should clearly be replaced by a redirect, and redirecting it should only take one user, why list it on AfD? Why not just be bold and do it? The previous text is still there in the history. RSpeer 14:50, September 8, 2005 (UTC)