Wikipedia talk:Redirects for discussion/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Stub-redirects for deletion?

I wanted to check by here that WP:SFD isn't treading on any toes by considering the deletion of redirects to stub templates. I'd think clearly not, but we're being roundly abused for it at present. If anything, the more likely overlap is surely with WP:TFD, since ordinarily they consider the whole namespace, redirects included, stubs templates being an exception in that sense. Alai 15:30, 22 October 2005 (UTC)

Massive backlog

We have a massive backlog here. Everything that has no vote and has been here for 2+ weeks will be closed as no consensus. Just letting everyone know. --Woohookitty^{(cat scratches)} 09:25, 3 December 2005 (UTC)

Actually, I'd think that if no objections are raised after two weeks, then they should be deleted rather than assume no consensus. older≠wiser 00:36, 4 December 2005 (UTC)

Second that. Many entries here are really trivial cases like "foo" → foo that we obviously don't need to keep (unless valid objections can be found, of course, but for that purpose we have the lag time). jni 15:40, 8 December 2005 (UTC)

I processed eight listings in the period 21–25 Nov, choosing to ignore the line "If a request is already somewhat older than a week, it has almost certainly been left for a reason (usually to try and spur further debate, or to try and reach rough consensus), so be cautious about deleting such entries." I flagged anything I was unsure of. If an admin with experience of taking care of RfD (or anybody, really) could please comment on the four remaining entries, under 21 November, 23 November, and 25 November, I'd soon get the hang of it. -- Jitse Niesen (talk) 01:20, 11 December 2005 (UTC)

I hope you don't mind but my boldness got the better of me and I resolved these discussions as well. Basically I think out-of-process entries should get a "no consensus"--without the rfd tag in the right place, for the proper period of time, a consensus isn't really possible. One thing I have been taking into consideration is the history--if a redirect has content in its history it probably shouldn't be deleted. In the case of "Uranium-lead dating" the nominator didn't really specify a valid reason ("making links red so people create an article" isn't really a reason to delete, at least according to this page) and so I did the same for it. I've been archiving the RFD discussions on the talk page of the redirect. I hope this explanation of what I've been up to helps. Demi ^T/_C 07:42, 12 December 2005 (UTC)

Hello. I nominated uranium-lead dating for deletion because it makes it look like we have an article on it, but we don't. I don't know about other people, but most of the articles I write are found through red links. If people don't realize that it's missing, we will never have an article on it. Every other method of radiometric dating has an article or is a red link. Uranium lead just redirects to the radiometric dating article. The problem is illustrated by the radiometric dating article, which has a link to uranium-lead dating that leads right back to itself. Also, it has no history of other than being a redirect. I don't know if these are valid reasons to delete a redirect according to this page, though. We should follow procedure. I guess I could write a stub in place of the redirect. Thanks, Kjkolb 15:08, 12 December 2005 (UTC)

Well, I hope I haven't queered anything but I've been bold and resolved several old redirects. I will probably be working on clearing the backlog, back to front (because I'm of linear mind). Unless there's some reason to think otherwise, I'm resolving a suggested deletion (implicitly a vote for deletion from the nominator) with no objection as 'delete'. Demi ^T/_C 06:58, 12 December 2005 (UTC)

There is an astonishing paucity of official information on how to process RFD. I recently asked Cryptic for information on how to best process the RFD backlog, as well as what procedures and policies were involved. He provided some very useful information, which I have archived at User:Extreme Unction/redirects. In the absense of any suggestions to the contrary, I will be following the guidelines he cited, and will join you folks in clearing out the RFD backlog. → Ξxtreme Unction {^yakł_blah} 13:55, 12 December 2005 (UTC)

I found that information really helpful, thanks for pointing to it. As we work on RFD, we should probably incorporate some of it into the page or an admin's subpage for RFD. I've basically followed those guidelines... except I'm not sure we need to purposely orphan links; or at least, I've been doing those on a case-by-case basis. Some redirects we delete because there's nowhere good for them to point, yet that doesn't mean they shouldn't be redlinks elsewhere. Demi ^T/_C 01:07, 13 December 2005 (UTC)

Wikipedia:Redirects for deletion/Old

Looking in Wikipedia:Redirects for deletion/Old, there appears to be only one outstanding issue, and it's over a year old. The issue is the Infatuation → Limerence redirect.

Relevant facts:

• [1] Redirect was deleted once.
• [2] Redirect was originally added on May 4, 2005, and re-added on June 16, 2005.
• [3] The contents of the RFD discussion has mostly been transplated to Talk:Limerence. The last line of the RFD discussion is different from the last line on Talk:Limerence, but otherwise the discussion is the same.

Any thoughts on what to do with this one? → Ξxtreme Unction {^yakł_blah} 11:40, 13 December 2005 (UTC)

It's not clear whether limerance and infatuation are the same or not. Joy says in the RfD discussion that they're not, but does not say why, and the article implies that they are synonyms, though they have different connotation. PubMed gives 22 hits for "infatuation" and 1 for "limerence" (though I'm not sure how complete this database is in psychology). This suggests that the redirect should stay, or perhaps that the article should be moved to "infatuation".

I think it would be best to close the discussion as no consensus. AfD discussions are also closed at some point, aren't they?

By the way, would it be useful to archive closed discussions somewhere or would that be instruction creep? -- Jitse Niesen (talk) 12:38, 13 December 2005 (UTC)

If we're careful about labeling the edit where we remove the discussion, we probably don't have to. However, I have been archiving discussions on the talk page of the redirect where I haven't deleted it. It seems like it would be useful to prevent spurious renominations, or document that it could be renominated for "no consensus" closes. Demi ^T/_C 18:37, 13 December 2005 (UTC)

Rewriting WP:RFD; creating a logging scheme.

I'm in the process of trying to reorganize Wikipedia:Redirects for deletion/Header so that it:

A) Flows in a more natural fashion.
B) Is more newbie-friendly.
C) Explains the RFD "mission statement" in a more obvious manner.

Lakewood Colorado → Lakewood, Colorado and Steel Detailer → Steel detailer have both been nominated recently. I have speedy kept the Steel Detailer redirect, and have toyed with doing the same for Lakewood Colorado. These are redirects that shouldn't be nominated. The redirects are perfectly in accordance with the purpose of redirects, as well as the stated guidelines on WP:RFD. Nominating them only invites mischief.

Thus, I will attempt to re-organize and re-write the page in the hopes that some of these issues can be avoided. This is not meant to be a unilateral action on my part, but rather a good faith effort to clear up these problems as I perceive them. I welcome considered discussion on the subject, and will be happy to revert some (or even all) of my changes, should it come to light that I have acted against the will of consensus.

I will also be implementing a logging process. As things currently stand, RFD is the least transparent of the various xFDs. When we delete a redirect, the discussion (if any) surrounding that deletion goes *poof*. The only way to access it is to dig through the history of RFD itself, which seems suboptimal. And even if we don't delete the redirect, the discussion is placed on the talk page of the redirect target. This is also suboptimal, because the redirect can be changed later to point at another target, thus orphanning the archived discussion. A collective repository of RFD decisions would be preferable.

Again, this is not meant to be a unilateral action, but merely a starting point. Again, considered discussion is cordially invited. The system I implement may be too unwieldy, and may need to be scrapped in order to implement something more streamlined. But I believe quite strongly that there needs to be some sort of archival process in place.

So that's what I'll be doing for the next hour or so. Hopefully I'll produce something out of the gate that everyone will love, but if not, at least we'll have a place to start.
→ Ξxtreme Unction|_{yakkity yak} 01:56, 20 December 2005 (UTC)

The Logging Scheme(tm) (aka "I'm a Lumberjack...")

Okay, I was not able to get as much done tonight as I'd hoped, but I did manage to cobble together the initial framework of a logging scheme. It's based on the logging scheme used by the WP:SFD folks. It will add a small amount of overhead to each nomination, but (A) the benefits of increased transparency outweigh the few extra seconds per nomination this will require; and (B) there just aren't that many RFD nominations in any case.

You can preview what I've got so far at User:Extreme Unction/Deletion Log. The archive links on those pages have been seeded with examples. Comments and critiques are welcomed.
→ Ξxtreme Unction|_{yakkity yak} 06:11, 20 December 2005 (UTC)

I support the creation of a logging scheme. However, I don't like that it will add overhead to the nominators. It's more than a few seconds, because the nominators have to read and understand the instructions first. What about the following scheme: Nomination stays the same, and at the end, the closing admin moves the discussion to, say, Wikipedia:Redirects for deletion/Archive/December 2005 and adds a remark like

Result. Deleted (with reasons if necessary). ~~~~

Look at my edits for closing Wikipedia racing: [4] and [5]. I think this is the simplest scheme which achieves the needed transparency. It also puts all the complexity on the closing admin, which is good because there will probably only a few admins doing the closings and they can remember the procedure. On the other hand, nominations will probably be spread around many edits.

By the way, rewriting the intro is another good idea. It also needs to be updated, at least in regards to CSD. -- Jitse Niesen (talk) 16:41, 20 December 2005 (UTC)

Thanks for the feedback. Just to be clear, this is not a process that will be undertaken by the nominators. They will not have any extra overhead compared to their current state (and, in fact, I'm taking steps to make it even easier on the nominators, similar to how the AFD and MFD banner templates work). The above logging scheme will be (if there is agreement) something undertaken by the closing admins. We will do all the heavy lifting of moving closed discussions to the appropriate archive file, not the people making the nominations.

Does this clarification alter your opinion in any way? → Ξxtreme Unction|_{yakkity yak} 17:02, 20 December 2005 (UTC)

Yes, that makes a difference. I'm not sure that something "similar to how the AFD and MFD banner templates" will improve things (the current procedure for adding a nomination to the page is pretty simple), but let's see.

Now that that has been cleared up (and I apologize for assuming things without reason), let me address the details. I'm wondering why you want to sort the closed discussions according to the result (delete, keep, etc.). Furthermore, adding a box around closed discussions clutters the archive, in my opinion, and is not really necessary because the fact that it's archived already indicates that the discussion has been closed, in contrast to AfD where closed and non-closed discussions are on the same page.

But yes, my greatest concern has been taken away. In the end, you closed most of the discussion lately, so it's mostly up to you. I hope you don't mind my criticism; in Dutch, we have an expression "the best steermen stand on the shore", meaning that it's easier to criticize somebody than to do the work yourself :) -- Jitse Niesen (talk) 18:05, 20 December 2005 (UTC)

All good points, and I hope I can address them usefully.

The "something similar to how the AFD and MFD banner templates work" bit has, as it turns out, already been done by someone else. If you have Javascript enabled, a "[Show]" link appears at the bottom left-hand corner of the RFD banner. Clicking that link reveals a two-step process that provides for an easy way to go through the RFD nomination process. I am, however, working on adding the standardized "How to list stuff for deletion on this page" color table format, similar in form to the "How to list pages for deletion" section of MFD.

The reason for having the different archives is greater transparency. If you want to find a particular debate that you know was kept, you can just sift through the "Kept" archive. However, I'm not particularly tied to the multitude of archives currently in place, and would be happy to simply have archives for "Deleted (No Objections)" and "Everything Else".

I do think it's useful to keep at least these two divisions. Stuff placed in the "Deleted (No Objections)" archive will not require any explanatory text from the closing admin, nor will it require archiving a lengthy discussion. It will just be a list of nominations. The "Everything Else" file will cover those instances where there is discussion, or where the closing admin needs to provide some explanatory text, or both.

As for the colored closure boxes, I like those because (A) The colored closure boxes provide for explanatory text from the closing admin that is clearly seperate from any discussion that may have taken place as a consequence of the nomination; and (B) I'm anal-retentive, and find the aesthetic consistency with the other xFD closing processes soothing to my psyche. ;-)

Thanks again for the feedback and the questions.

→ Ξxtreme Unction|_{yakkity yak} 18:43, 20 December 2005 (UTC)

I completely misunderstood the "something similar to how the AFD and MFD banner templates work" bit. I thought it referred to something like {{afd2}} and {{afd3}}. I never noticed the new thingy on the bottom of {{afd}}.

The problem with divisions is that you might have to sift through a couple of archives. For instance, if something is deleted, you must look through "Deleted (no objections)" and "Deleted (by consensus)". But it's not a big point to me.

Whether to use coloured boxed or not is truly a minor thing for me. I understand the reason to attempt to standardize between ?fD, and indeed, most use them (except IfD, TfD and CP).

In conclusion, I'm happy to let you proceed with it. Thanks for your answers. -- Jitse Niesen (talk) 19:33, 20 December 2005 (UTC)

I like this scheme. If I don't like it, I might adjust it when I have a bunch of RFDs to close. But it seems to address the most common case (basically just a paste) while preserving salient discussions. Demi ^T/_C 22:45, 20 December 2005 (UTC)

Look upon my works, ye mighty, and despair

Okay, I have finally managed to get the RFD page (or a mockup of it, at least) to conform to my subtle whims.

Please take a gander at User:Extreme Unction/Header. If no one objects, I would like to replace the current text at Wikipedia:Redirects for deletion/Header with the text at User:Extreme Unction/Header. I would also like to put the text at User:Extreme Unction/Header on the same page as the RFD nominations, rather than having that text transcluded as the current Wikipedia:Redirects for deletion/Header is now.

Additionally, I have substantially revised and streamlined the proposed archival process based on Jitse Niesen's comments above. Rather than having multiple archives, I think Jitse is right -- a single archive would be better. So please also check out the newly revised User:Extreme Unction/Redirect Archives.

Let me know what you think.
→ Ξxtreme Unction|_{yakkity yak} 22:27, 20 December 2005 (UTC)

It's good. The one thing I would change is to shift the "How to list" instructions much higher--"above the fold" in a typical browser. Or at least have a prominent internal link there. Demi ^T/_C 22:49, 20 December 2005 (UTC)

Eh. I'm of the mind that people should see the reasons why they should and shouldn't list a redirect before they see the instructions on how to do so. May save a headache or two down the road. → Ξxtreme Unction|_{yakkity yak} 18:33, 21 December 2005 (UTC)

Another thing that would be useful to have above the fold if possible, even if just one sentence, is that a redirect should be harmful to be nominated. -- Jitse Niesen (talk) 06:50, 21 December 2005 (UTC)

Stub-redirects for deletion, redux.

On October 22nd, a representative from the stub-sorting project posted a message here which asked if WP:SFD would be stepping on any toes by subsuming the task of dealing with stub redirects under the aegis of SFD. After several days here without objection (or any other comment), SFD began handling stub redirects.

It is worth noting — and I say this without any trace of accusation or recrimination, as there is no reason why any of this would have been obvious to the casual observer — that RFD was mostly inactive at the time that notification in question was posted here. The last edit to the RFD talk page prior to October 22nd was September 15. The next edit following October 22nd was November 21. During this time, RFD accumulated a rather substantial backlog.

On December 1st, Woohookitty started working on clearing out the backlog. If you look at the state of the page on December 1st, you will see that the backlog dates to October 20th, two days prior to the SFD notification being placed on the RFD talk page. Which meant that RFD hadn't been under any sort of regular admin scrutiny since before the SFD notification was posted to the RFD talk page.

My understanding is that the RFD process was administered for a long time largely by one person, User:Jnc. And then he left sometime in early October, leaving RFD without a hand upon the tiller. The SFD notification was posted sometime after he left. Since RFD was generally ignored at this point in time, the SFD notification received no response.

However, a few admins (myself included) have taken RFD under our wing and have attempted to revive it back into full health and bring it into some sort of cohesion. It is no longer languishing in a state of disrepair. Admins are once again paying active attention to it, and had the SFD notification been posted today, rather than two months ago, I suspect the notification would have generated some actual discussion as to the pros and cons of moving stub redirects out of RFD and into SFD.

I would like to suggest that this issue needs to be revisited. I understand that the stub-sorting folks have very valid concerns about the proliferation of stub names and the difficulty this brings to the task of sorting stubs. But I also see many stub redirects that are 100% in accordance with the redirect policy at Wikipedia:Redirect (particularly in the "Other spellings, other punctuation" category) being deleted or otherwise deprecated.

I do think that, given the circumstances under which stub redirects were subsumed under the aegis of SFD rather than RFD, that the process of handling stub redirects should revert back to RFD until such time as a decision has been made to do otherwise.

All the best.
Ξxtreme Unction|_{yakkity yak} 14:45, 24 December 2005 (UTC)

On the matter of putting stub redirects here, I think that is reasonable; I would suggest that there be a suggestion to contributors that the status as a stub template be made clear in the description accompanying the nomination for deletion.

Also, thanks for the historical context. I think that the observation that the request was largely missed is a valid one from my point of view and the matter should be revisited on those grounds. You will find, though, that there are lots of hardliners here who will say "too bad for you ... you should have been looking", which is what happens at TFD and CFD and AFD when someone complains "I didn't know this was happening!". The redress there is an onerous trip to the undeletion mines. I hold out hope that your call will be answered with a hopeful and conciliatory tone rather than a spiteful one. User:Ceyockey 15:58, 24 December 2005 (UTC)

    First, a small correction on the timeline given. SFD has been handling stub redirects since it went live back in mid-June. What happened in mid-October was that complaints were raised that stub redirects should be handled by RFD and not SFD, and it was at the that time that the non-discussion above took place. (I can't speak on whether any discussion took place in mid-June about this.)

    That said, what is going on here is a dispute over whether template redirects should be less favored than article redirects. many of the arguments put forth in favor of being less permissive by the the stub sorting project would seem to me to largely apply to all template redirects and not just stub template redirects, and so perhaps this discussion should be broadened to include all template redirects, tho I will not do that at this time, instead I wil speak only on the issues that arise out of trying to maintain the family of interrelated templates and categories known as stubs.

    Redirects from alternate template names are almost always kept, such as {{author-stub}} which started off as a unproposed duplicate of {{writer-stub}} that was quickly adopted as a recognized redirect from an alternate name. In my experience, the only time such redirects are brought to SFD for deletion is when they are potentially ambiguous and end up being deleted for that reason rather than being a redirect. Rather, the issue which has raised the greatest degree of controversy is the deletion of redirects that do not follow the naming conventions for stub templates.

    Frankly, if such redirects are not deleted, then stub templates will effectively have no naming conventions because they will be unmaintainable. As for the naming conventions themselves, they are effectively of two parts, the common sense (avoid abbreviations, follow the same capitalization rules as the original, etc.) and the arbitrary (no spaces, US-geo-stub prefered over geo-US-stub, etc.). It's the second part that is generating the dispute. The enforcement of a consistent set of rules of formation of stub template names so as to avoid people having to wonder which one of any number of admitted equally valid methods is being used here.

    Take for example a hypothetical stub for North Carolina botanists. Should it be {{NorthCarolina-botanist-stub}} or {{North Carolina-botanist-stub}} or {{NorthCarolinabotaniststub}} or {{NorthCarolina botanist stub}} or {{North Carolina botanist-stub}} or {{NorthCarolinabotanist-stub}} or {{North Carolina botanist stub}}? That's seven different forms, just from considering reasonable variations of the hyphen and spacing rules and not even considering alternate capitalizations or misspellings. Now suppose, someone tries to use one of these and notes during the preview that it doesn't exist. Without a naming guideline, he has no way to know if it's because the stub exists somewhere, but the redirect doesn't, or if the stub doesn't exist. It is clear to me that naming guidelines for stub templates are desirable as they enable this confusion to be avoided and that pruning stub template redirects that don't follow the naming guidelines is necessary to enable the naming guidelines to work. Caerwine Caerwhine 18:01, 24 December 2005 (UTC)

Thanks for the correction on the timeline. I misunderstood a comment made by one of the stub-sorting folks on WP:VPP. My apologies. Obviously, in light of this info, I withdraw my request to have the responsibility of dealing with stub redirects handed "back" to RFD.

I will comment later on the meat of your post, but I at least wanted to apologize for my error.

Ξxtreme Unction|_{yakkity yak} 18:14, 24 December 2005 (UTC)

This still raises the question of when/where it was decided that redirects would be handled at SFD. Who decided? Where was the consensus? Was this put to any kind of vote/poll? Was there a reasonable showing of votes by the community? If not, why wasn't this persued prior to SFD taking over stub redirects? For me, I definitely think it's improper to have two systems for redirect deletion (each with their own standards for deletion, at that)! —Locke Cole 01:45, 26 December 2005 (UTC)

I do not believe that anyone is advocating "keep all variants as redirects" as a matter of formal guideline. This is more a matter of whether the same guidelines should apply to stub-template redirects as other template redirects. Concerns have been raised that the guidelines have diverged, apparently as a result of an "out of sight - out of mind" effect of the stub-template redirects being considered at a different place than other template redirects. I believe you've suggested that it is reasonable that both types adhere to the same guidelines, which I agree with as well; one way to ensure that the same guidelines are adhered to is to consider both types together in the same place so that an effective synchronization of behavior can be achieved. Once such synchronization has occurred then the matter of formally ceding stub-template redirect deletions to WP:SFD would likely occur with little friction because it would be an adminstrative boon to do so. In other words, I believe it is desirable to ensure that the "when" and "why" of stub template redirect deletion be synchronized with that of other template redirect deletions before formally splitting the "how" between two places. User:Ceyockey 18:21, 24 December 2005 (UTC)

Please be aware that policy is very rarely instated through a poll. People objecting to deleting redirects at SFD are generally missing the point that templates and categories also have two spots to delete them (one for stub tl/cat and one for regular ones). It seems practical to handle all stub-related matters on SFD. It seems also logical to kindly ask some people from RFD to take a look at it to ensure we don't get a doulb estandard. Radiant_>|< 10:36, 26 December 2005 (UTC)

That I've seen, few people (if any) are missing the point you claim they are missing. Most folks involved in this discussion seem to be perfectly aware that stubs combine category and template into a single entity, and that there are clear problems for resolving half of an entity's delete discussion in one forum while resolving the other half in another forum. But the issue of redirects does not have that same problem. A stub redirect is pretty independent of the actual stub, unlike the stub template and the stub category. Ξxtreme Unction|_{yakkity yak} 13:06, 26 December 2005 (UTC)

Post-Christmas Refactoring

    Frankly, if such redirects are not deleted, then stub templates will effectively have no naming conventions because they will be unmaintainable. As for the naming conventions themselves, they are effectively of two parts, the common sense (avoid abbreviations, follow the same capitalization rules as the original, etc.) and the arbitrary (no spaces, US-geo-stub prefered over geo-US-stub, etc.). It's the second part that is generating the dispute. The enforcement of a consistent set of rules of formation of stub template names so as to avoid people having to wonder which one of any number of admitted equally valid methods is being used here.
    Take for example a hypothetical stub for North Carolina botanists. Should it be {{NorthCarolina-botanist-stub}} or {{North Carolina-botanist-stub}} or {{NorthCarolinabotaniststub}} or {{NorthCarolina botanist stub}} or {{North Carolina botanist-stub}} or {{NorthCarolinabotanist-stub}} or {{North Carolina botanist stub}}? That's seven different forms, just from considering reasonable variations of the hyphen and spacing rules and not even considering alternate capitalizations or misspellings. Now suppose, someone tries to use one of these and notes during the preview that it doesn't exist. Without a naming guideline, he has no way to know if it's because the stub exists somewhere, but the redirect doesn't, or if the stub doesn't exist. It is clear to me that naming guidelines for stub templates are desirable as they enable this confusion to be avoided and that pruning stub template redirects that don't follow the naming guidelines is necessary to enable the naming guidelines to work. Caerwine Caerwhine 18:01, 24 December 2005 (UTC)

Sorry for the delayed response. Christmas was a smidge busy here at Stately Unction Manor. I hope you don't mind that I've refactored your comments for ease of response.

I understand, and agree with, the reasoning behind not wanting a multitude of actual stubs with variant names. If {{NorthCarolina-botanist-stub}} is an actual stub, and if {{North Carolina-botanist-stub}} is a completely seperate and distinct stub, that's bad.

The primary purpose behind differentiated stubs is, as I understand it from reading Wikipedia:Stub, to allow greater "ease of access" for interested parties. Rather than forcing a brewer or beer enthusiast to sort through an undifferentiated mass of articles listed under the {{stub}} category searching for beer- and brewing-related articles, they can just look through the category generated by {{beer-stub}}. Allowing {{NorthCarolina-botanist-stub}} and {{North Carolina-botanist-stub}} to each exist as an actual stub, independent from each other, runs counter to the reason why stubs are differentiated in the first place, and is obviously a bad thing.

What I don't understand is why stub redirects are bad, assuming they otherwise meet the criteria for redirects as stated on Wikipedia:Redirect. As near as I can determine, they do not run counter to the primary purpose of differentiating stubs in the first place.

Consider {{California State Highway Stub}}. At the present time, this stub redirects to {{California-State-Highway-stub}}, from which it differs only by some hyphens and one capitalized word.

The California State Route 237 article is currently flagged with {{California State Highway Stub}}. But since {{California State Highway Stub}} is a redirect to {{California-State-Highway-stub}}, the California State Route 237 article behaves as though it were flagged directly with {{California-State-Highway-stub}}. The article has the same stub template graphic at the bottom as it would if it were flagged directly with the approved hyphenated version of the stub, and is added to Category:California State Highway stubs just as it would be if it were flagged with the approved hyphenated version of the stub. Any interested California road enthusiasts can click on the link to Category:California State Highway stubs and find the entry for California State Route 237 there, as well as every other article flagged with the now-deprecated {{California State Highway Stub}}.

Leaving {{California State Highway Stub}} as a valid redirect appears to serve the needs of why stubs are differentiated in the first place (ease of finding similar articles within one's area of interest that require expansion). It also serves the need of why redirects exist, which is to make things easier for editors and readers alike. And it doesn't really seem to inconvenience anyone or bring any direct harm to Wikipedia.

So why are stub redirects that are otherwise 100% in compliance with Wikipedia:Redirect a bad thing, such that they must be vigorously expunged when they arise?

All the best.

Ξxtreme Unction|_{yakkity yak} 14:33, 26 December 2005 (UTC)

Copied from Wikipedia:Deletion Review (in "SPUI v. SFD"), with emphasis added:

• ...speedy-keep stub template redirects that differ only in capitalization, spacing, or hyphenation, and anything else that might help non-experts sort stubs. Too many times I've inadvertantly left a red link at the bottom of a stub page due to unexpected and/or inconsistant naming conventions. I typically give up after clicking the preview button 3 times and not finding a valid stub type. Shouldn't the stub folks want it to be easier for others to help them? — FREAK OF NUR_xTURE (TALK) 15:47, Dec. 26, 2005

We have naming conventions for articles as well, and for reasons that reach beyond mere consistency. Redirects from titles that "violate" naming conventions are often useful, because where users are served by a redirect, it makes sense to have it. Where they are not--well, we prune the thicket of redirects here at RFD. Now that RFD is being maintatined, I don't see much of a benefit to having stub template redirects considered at the WikiProject. Having it here makes it a little easier to follow the guiding principles of redirects, which is that they are cheap, and when useful, should stay. Demi ^T/_C 16:11, 26 December 2005 (UTC)

I don't think that one can or should automatically assume that the rules for article redirects should be the same as template redirects. Article redirects provide feedback that they are being used while template redirects don't, thereby causing them to be left in articles. Article redirects are also useful to readers as they provide an entry when will be followed when the errant or variant form is sought via the Go button. Template redirects are useful only to the smaller set of editors.

Unlike redirects to articles or even individual templates, stubs are an interrelated family of templates and and categories. If a little used redirect is used for an article or a non-family template, it's small waste of disk space, but it's not likely cause others to make similar redirects, articles or templates that don't follow the naming conventions. The simple fact of stub creation tho is that most new stubtypes are not created from scratch. Rather, they are created by someone taking an existing stub and duplicating it and then making some minor changes to generate the desired text. Some of these efforts at duplication turn out better than others. At their simplest, someone will type in "{{brand new stub}}" in the article text and then click on the resulting redlink to enter the stub text they want. It's these simplest efforts that are most likely to not follow the naming conventions and thus cause problems of not only badly named stubs, but also duplicate stubs.

That said, perhaps rather than human engineering, we should be focussing our efforts on software engineering, since the later is usually easier to accomplish. It shouldn't be that difficult to have the software be able to automatically substitute in the reference from a redirect instead of keeping it when saving an edit. That would have the benefit of reducing both server load when the template or article link is refered to in the future and in the case of stub templates, reduce the number of undesirable examples followed by novice stub creators. In cases where it is desirable to retain the redirects as redirects because they are redirects with possibilities, it wouldn't be difficult to have it differentiate this based on something such as having #REDIRECT [[Y]] and #REDIRECT [[Template:Y]] be links that do get auto-dereferenced while #REDIRECT [[:Y]] and #REDIRECT [[:Template:Y]] don't get auto-dereferenced, as currently the syntax allows for either form and they seem to be treated the same, so I don't think the change wouldn't break anything. Caerwine Caerwhine 22:02, 26 December 2005 (UTC)

But if {{brand new stub}} redirected to {{brandnew-stub}}, that person would see the correct message and not create a duplicate. Your argument seems to be in favour of keeping redirects. Conscious 08:24, 27 December 2005 (UTC)

• You seem to be suggesting that we are going to proactively create tens of redirects for each and every stub template so as to prevent duplicate stub templates. Not gonna happen. No my argument is that there are better thing to be arguing about, especially if the problem can be largely solved via software engineering. I'm not in favor of keeping what I consider useless redirects at all, but there are better uses of my time than fighting this battle in my opinion. Caerwine Caerwhine 01:18, 4 January 2006 (UTC)

I think Caerwine's technical solution is an excellent one that would resolve most, if not all of this drama. Posted to bugzilla (bugzilla:4410). -- grm_wnr Esc 17:26, 28 December 2005 (UTC)

Stub redirects

Okay, it would help if people weren't overly verbose here. Personally, I think that it shouldn't particularly matter which process dels with stub redirects. The most important thing is that we have a consistent guideline for when to keep or when to delete them. In particular, the argument and counter-argument seem to be that (1) they can be useful, but (2) template redirects cause unnecessary server load. I don't believe that (1) requires any explanation, and it seems to be the credo for RFD. Regarding (2), maybe somebody could spot Jamesday or Brion and IRC and ask them to comment? Simply put, if (2) is true then it trumps whatever convenience issues we have, because the server is simply more important. If (2) is untrue, then there's hardly an argument against keeping stub redirects. Radiant_>|< 22:49, 26 December 2005 (UTC)

User_talk:Jamesday#Template_redirects makes it look like (2) is right. which is what weve been saying all along at WP:SFD and WP:WSS. BL kiss the lizard 01:38, 7 January 2006 (UTC)

I believe this is a rather one-sided summary of the situation, actually. Jamesday has proposed a solution which suggests implementing the proliferation of stubs the stub-sorting folks have heretofore attempted to avoid. Ξxtreme Unction|_{yakkity yak} 12:43, 7 January 2006 (UTC)

It's one-sided, yes, and Jamesday does offer a solution. But reading all of what Jamesday says he makes it very clear that it's not unfairly one-sided. template redirects are generally harmful to the servers, and his solution is only a stop-gap measure. He advocates replacing redirects with a message which will get a bot to change the template to the real one. In other words, if a template redirect exists, it should not be used. So why have them in the first place? If what happens when they're used is that a flag comes up saying "this shouldn't have been used", then surely it would be far simpler not to have the redirects in the first place. That way, they won't be used, a bot could be used for other things or kept idle (bot use also slows down the servers, does it not?), and the articles will be correctly templated the first time. Grutness...wha? 23:59, 7 January 2006 (UTC)

But he also does not say that template "quasi-stubs" should be avoided. So to the extent that many people find alternate names for stubs useful, they should be implemented as quasi-stubs. Ξxtreme Unction|_{yakkity yak} 12:38, 8 January 2006 (UTC)

No, he simply makes it clear that they should be bot-emptied regularly - in other words, he suggests that they should never become regularly filled with articles. So, to repeat what I said above, why have them in the first place? We'd have to run a bot (slowing the servers) and we'd have a lot of articles temporarily using redirects (also causing trouble for the servers). Grutness...wha? 12:55, 8 January 2006 (UTC)

For the same reason that the entire stub-redirect issue became thorny in the first place: Some people find it difficult to remember the names preferred by the stub-sorting project, and easier to use alternative formulations. And if the server load caused by a bot emptying the categories would be equally as problematic as the template redirects themselves, Jamesday wouldn't have opened that door himself in the first place. Ξxtreme Unction|_{yakkity yak} 13:35, 8 January 2006 (UTC)

The stub redirect issue only became thorny in the first place for one reason. One user was pissed off because a redirect he made was deleted at SFD (by a margin of about 8-1). He then decided to kick up as much dust as he could - which included mass-producing stub redirects in batches of a dozen or so per template (for which he was blocked on at least two occasions), deleting other people's comments at SFD and removing entire deletion processes, repeatedly re-creating deleted templates, and generally making a pest of himself. Up until that time, the issue had not been at all thorny, and had been operating extremely smoothly. Grutness...wha? 23:38, 8 January 2006 (UTC)

I do not consider this summary to be wholly accurate. It is difficult to find diffs that are relevant specifically to this issue, and to naught else, but while SPUI was indeed the agitator that brought the issue to light, many people have expressed opinions which can be reasonably interpreted as being in favor of a less restrictive naming policy with respect to stubs and stub redirects.

From the recent discussion at WP:DRV (complete discussion can be found here, at the bottom of the page):

• I see no reason why useful redirects should be deleted. Demi ^T/_C 01:39, 24 December 2005 (UTC)
• It's just plain nonsensical to make it harder to find the correct stub template. Logical redirects should stand to make stub sorting easier. - Mgm|^(talk) 12:00, 24 December 2005 (UTC)
• I can't see why anyone could be bothered by variations with and without a hyphen. It doesn't have to be just one and only one version. -- Eddie
• harmless redirects should not be deleted. Christopher Parham (talk) 02:52, 25 December 2005 (UTC)
• And speedy-keep stub template redirects that differ only in capitalization, spacing, or hyphenation, and anything else that might help non-experts sort stubs. Too many times I've inadvertantly left a red link at the bottom of a stub page due to unexpected and/or inconsistant naming conventions. I typically give up after clicking the preview button 3 times and not finding a valid stub type. Shouldn't the stub folks want it to be easier for others to help them? — FREAK OF NUR_xTURE (TALK) 11:14, Dec. 26, 2005
• As for the issue of common sense, I can't imagine why anyone would want to eliminate these harmless/useful redirects. Just last week, I couldn't remember what the naming convention was, and I didn't guess the correct spelling of a stub template ({{music-stub}}) until my third try. At the time, it occurred to me that redirects from the other obvious names ({{musicstub}} and {{music stub}}) would have been handy. I find it very difficult to believe that the regular stub-sorters would actually want to make it more difficult for "outsiders" to help, but I'm struggling to find another explanation for these deletions. —David Levy 16:13, 26 December 2005 (UTC)
• I must say I'm surprised that the Depredations of the Evil Stub Cabal are finally starting to generate some real backlash, even though I'm sure these would all just be deleted again if relisted at WP:SFD. Regardless, I know I'm through with jumping through arbitrary hoops and will still just be using plain {{stub}}...—Cryptic (talk) 18:39, 26 December 2005 (UTC)

From the recent discussion at WP:VPP (complete discussion can be found here, about 2/3rds of the way down the page):

• I must say, I don't see and have never seen the point of deleting slightly-misnamed - or better still, merely miscapitalised - redirects as happens on SFD all the time. In the articlespace, creating slightly-misnamed redirects to avoid confusion is encouraged fer crying out loud! - SoM 04:02, 24 December 2005 (UTC)

From the recent discussion at WP:MFD (complete discussion can be found here, approximately 1/4th of the way down the page):

• This entire process needs throwing out and starting from scratch. It is the one place on Wikipedia where systemic bias is not a problem, but a mantra. Ambi 02:54, 23 December 2005 (UTC)

As the above should illustrate, the view that some form of stub redirecting would be useful and beneficial is not limited to one lone crank. Ξxtreme Unction|_{yakkity yak} 14:27, 12 January 2006 (UTC)

• It is my view that stub redirects are better handled at SfD, becausew the issues are basically the same as for stub types in general. Jamesday's comments, cited above, certianly sugest that template redericts in general are significantly more costly than articel redirects, adn should be avoided if possible. Given that, I find Grutness's comemtns above that such rederects should usually not exist persuasive. DES ^(talk) 07:46, 8 January 2006 (UTC)
  • I second DES's opinion. Radiant_>|< 22:45, 15 January 2006 (UTC)

Speedy keeps

I have no idea how long it's been one of the Guiding Principles here, but speedy-keeping redirects that contravene Wikipedia:Redirect strikes me as a very poor idea. Elsewhere in the deletion process, speedy keeps have been reserved only to bad-faith nominations, and almost never happen except on afd. (I'm not sure how one could show that an rfd nomination was in bad faith, anyway.) A revert essentially says that "nothing you wrote is worth salvaging, I'm removing it all", which is bad enough; speedily ending a deletion debate instead says that "not only is your opinion wrong, but you're not even allowed to discuss it." There's nothing wrong with simply adding your own "Keep, complies with WP:R" and letting it sit for the normal week before closing. —Cryptic (talk) 18:16, 3 January 2006 (UTC)

One thing to consider about RFD is that nominations in contravention of Wikipedia:Redirect usually don't have much room for interpretive nuance. That is, if someone were to nominate A Series Of Unfortunate Events → A Series of Unfortunate Events, there's not a whole lot that can be said about that nomination. There are no subtle distinctions of notability/non-notability to be made. No points about how it's not REALLY an alternative capitalization of the target article, or how it is, but redirect policy should be ignored in this instance because... It's a pretty cut-and-dried situation.

I just don't see much benefit to giving 100% valid redirects even a small chance at either being deleted or (worse) being kept in contravention of a consensus delete. If newbie-biting is the chief concern, I have in the past written conciliatory messages to redirect nominators on their talk page, explaining why a redirect was kept. I would be happy to resume that practice if others feel it would be necessary.

All the best.

Ξxtreme Unction|_{yakkity yak} 19:19, 3 January 2006 (UTC)

Uncertain whether to list

A new user has created [[Wikipedia:Text of the gnu Free Documentation License]] which REDIRECTs to [[Wikipedia:Text of the GNU Free Documentation License]] as you might expect. I can see no reason for this REDIRECT to exist other than as one of this user's more interesting test edits. Should this be listed for deletion, speedied, or simply left alonoe? HTH HAND —Phil | Talk 09:17, 12 January 2006 (UTC)

Seems like a reasonable use of {{R for alternate capitalisation}}. I know a lot of unix geeks who think in all lowercase when it comes to things unix-y, so I think it's perfectly plausible that someone might type "gnu" instead of "GNU". Ξxtreme Unction|_{yakkity yak} 12:50, 12 January 2006 (UTC)

Please clean up after yourselves!

These are the goodies for your attention from the category:redirects for deletion. Keep in mind, that at that time, the whole category was 121 entries... So 25% of all entries were messed up...

1. ArrayTag tagged since Sept. 25
2. Acrylic Compound tagged on Oct. 22, keep votes pasted on talk page on Nov. 28
3. Blogorrhea tagged for RfD since Sept. 26
4. Broadcast magazine, which is not a redirect, tagged since Dec. 2
5. Cdpedia - Nov. 7
6. Charver - Sept. 22 after a bizarre VfD, RfD, etc. sequesnce
7. China for Christ Church - Sept. 4, was relisted by myself
8. Cyr - Oct. 26, rfd place corrected on Dec. 1
9. Dvdpedia tagged - Nov. 7
10. Enterprise management - Nov. 15, resolved as no consensus on Dec. 12 on talk page
11. Infobox episode list - Oct. 22
12. International Gareth Day - Nov. 6
13. Korean churches in China - Sept. 3 (winner), was re-listed by myself
14. Ladislaus the Bold - Dec. 14, misformatted by an anon
15. List of automobile models by size - Aug. 28
16. Lyotrophic - Nov. 29
17. MiniCode - Sept. 25
18. MoD Trains - Dec. 2
19. Motorola v600 - Dec. 16
20. Nori (LAY) - Oct. 29
21. Oak Elementary School - Dec. 4
22. RUBBER MATCH, not a redirect, - Oct. 1
23. Wikipedia:Reqeusts for whores - Dec. 9
24. Template:Requests for arbitration/Coolcat vs. Fadix - Dec. 9
25. Russell J. Rowlett, to a deleted article, Dec. 23
26. SIDO - Oct. 13
27. Sound (computer) - Oct. 20
28. Temporally - Dec. 16
29. The College of the Holy and Undivided Trinity in the University of Oxford, of the foundation of Thomas Pope - Dec. 29
30. The Earth, A Small Man, His Dog and a Chicken - Oct. 13
31. University of Notre Dame Head Football Coach - Dec. 21
32. University of Notre Dame Head Football Coaches - Dec. 21
33. Vazul - Dec. 14
34. Template:Wikiportal:Doctor Who/Categories - Nov. 3

Renata 13:14, 15 January 2006 (UTC)

Huh?

I'm concerned about these two keeps:

• Neither recieved a single keep vote.
• The first recieved 2 delete votes,( including my nomination).
• The second was closed prematurely after only a few days.
  

Is it really acceptable for the admin to make a unilateral decision that goes against all the votes?
I personally don't think so, but I want to know what others think.

Postscript: I know Wikipedia is not a democracy, but it seems to me that there is nothing remotely like concensus in such a decision. Ξxtreme Unction should have made his/her comments in a keep vote or a comment for others to consider. -- WikidSmaht (talk) 00:09, 20 January 2006 (UTC)

These discussions are not votes. They are discussions. The closing admin has broad leeway to weigh the comments provided by participants in the discussion, in conjunction with his/her knowledge of Wikipedia policy, and make the judgement he/she feels is the right one, all factors taken into consideration. The two relevant policies here are "Plausible redirects should not be deleted" and "Redirects should not engender confusion."

Sleeping curse → Sleeping Beauty and Sleeping spell → Sleeping Beauty are, in the absence of suitable alternatives, plausible redirects, and therefore should not be deleted.

Redirects are governed by the Principle of Least Astonishment. If someone types in a redirect in the search box, and find themselves at the target page going "Huh? Why am I here?", it's a confusing redirect. Retargeting these two redirects at Spell (paranormal) or Curse would, in my opinion, engender such confusion.

However, it is important to understand that RFD decisions are not binding. The fact that these redirects have been kept is not an indication that they must now and forevermore remain redirects pointing at Sleeping Beauty. I can think of at least two alternative methods of dealing with them.

• Disambiguating one and retargeting the other to the resulting disambiguation page.
• Expanding one into a full article about sleeping spells in fiction, and then retargeting the other to the expanded article.

Either of these alternatives would, in my opinion, be superior to the current circumstance. And neither action requires any sort of admin action from RFD. If you have the knowledge to expand Sleeping curse into an article (even a stub article), and then edit Sleeping spell to redirect to Sleeping curse (or vice versa, if that's your bag), that's exactly the sort of thing we encourage.

All the best.

Ξxtreme Unction|_{yakkity yak} 13:29, 20 January 2006 (UTC)