Wikipedia:Redirects for discussion/Log/2006 December 21

From Wikipedia, the free encyclopedia

December 21[edit]

RFC 1Request for Comments[edit]

The result of the debate was Deleted except for RFC 1. Also, Rfc 2397 & RFC 2397 have been deleted in accordance with rationale established here (i.e. precedence for Wikipedia's autolinking feature for RFC numbers). -- JLaTondre 01:32, 12 January 2007 (UTC)[reply]

First off, I'm sorry for the length of this post, this really is a request for discussion, I'm not sure what the best course of action should be.

Note: I am using RFC 1 as an example to start with, there are actually about 100 similar articles. If I get even a luke warm response, I will list all of them here since they all have basically the same problem, but I don't want to go through all the effort if this is clearly a bad idea.

I'm going to take RockMFR response as being at least lukewarm support and start listing all 104 redirects Wrs1864 15:53, 22 December 2006 (UTC)[reply]

I suspect most people know that "RFC" stands for Request for comments and they are a key collection of Internet standards. They are so special that wikipedia now has builtin recognition of these RFCs so when you type, without any markup at all, "RFC 791" you will automatic get the external link "RFC 791".

The problem is that, long ago before the builtin RFC recognition support, a bunch of stubs for "important" RFCs were created. So, if someone is editing an article and types "[[RFC 791]]", they will get a link to the article RFC 791. Unfortunately, this stub is just a redirect to Request for comments, so if a user clicks on the RFC 791 link, they won't get much closer to actually seeing RFC 791.

  • I think these redirects are harmful because the they cause confusion (criteria 3. for reasons to delete a redirect.)

I have found that about 100 out of the ~4500 RFCs had either redirects or stub articles.

Of those, only as very small handful (5-10 IIRC) were linked from other articles. When I checked those links, all were better off using the builtin RFC external linker and created the kind of confusion I mentioned above. I have "fixed" these cases and now there are no internal links to these RFC stubs. (My point isn't that I expect redirects to be linked to, I know that no links is normal. Rather, that when these are linked to, they cause problems.)

Only about 20 of the 100 were articles rather than redirects Of those, only about 5 had content that was useful, most were just terse summaries of the RFC and external links to the actual text. I suspect these were created before the builtin RFC linking and they were once useful. I have merged all of the actual content into appropriate articles and have turned all of them into redirects.

Of the redirects, most just pointed to Request for comments, which I don't think is at all useful. *IF* we decide to keep these as redirects, I suggest linking to List of RFCs instead since that will at least get people to a more useful article.

All of the redirects that don't link to Request for comments link to the appropriate named article. For example, RFC 0959 is about the FTP protocol and therefore redirects to File Transfer Protocol.

It might be argued that these redirects are useful because people might type in "RFC 1234" to the wikipedia search and expect to get a useful answer. The problem here is that only ~100 out of ~4600 RFCs have redirects and a large chunk of the ones that do are for RFCs that are now obsolete. Wikipedia is not an indiscriminate collection of information and these 100 redirects are poorly chosen.

If we want to let people get useful information when they type an RFC into the wikipedia search box, maybe a special case could be made that directs users the the appropriate external link, kind of like wikipedia has a special case to recognize RFC numbers in articles. That is just a Small matter of programming.

Another thing that could make wikipedia *MUCH* more useful for dealing with RFCs typed in by the user would be to change the search system to actually find them. Right now, if you type "RFC 792" into the wikipedia search box, you get useless results, even though google shows that there are about 20 references to this RFC in the wikipedia. Again, just a SMOP.

The following 49 RFCs have redirects to Request for comments and, if not deleted, I think should be changed to redirect to List of RFCs: RFC 0823 RFC 0824 RFC 0825 RFC 0983 RFC 0985 RFC 0987 RFC 1 RFC 791 RFC 1006 RFC 1009 RFC 1066 RFC 1123 RFC 1144 RFC 1156 RFC 1394 RFC 1495 RFC 1632 RFC 1718 RFC 1776 RFC 1789 RFC 1792 RFC 1809 RFC 1812 RFC 1819 RFC 1876 RFC 1969 RFC 2026 RFC 2116 RFC 2119 RFC 2126 RFC 2156 RFC 2181 RFC 2183 RFC 2184 RFC 2223 RFC 2419 RFC 2535 RFC 2549 RFC 2644 RFC 2646 RFC 2747 RFC 3008 RFC 3021 RFC 3023 RFC 3094 RFC 3097 RFC 3098 RFC 3106 RFC 3115

The following 55 RFCs now redirect to the appropriate article, most of which have links to the actual RFCs: RFC 0822 RFC 0959 RFC 793 RFC 822 RFC1196 RFC1918 RFC2440 Rfc 869 Rfc2821 Rfc3501 RFC 1 RFC 1149 RFC 1459 RFC 1483 RFC 1521 RFC 1590 RFC 1652 RFC 1777 RFC 1778 RFC 1823 RFC 1867 RFC 1889 RFC 1918 RFC 1959 RFC 1960 RFC 1982 RFC 2045 RFC 2046 RFC 2047 RFC 2048 RFC 2049 RFC 2083 RFC 2182 RFC 2196 RFC 2231 RFC 2246 RFC 2326 RFC 2327 RFC 2401 RFC 2426 RFC 2440 RFC 2445 RFC 2543 RFC 2684 RFC 2781 RFC 2822 RFC 3066 RFC 3261 RFC 3339 RFC 3377 RFC 3514 RFC 3951 RFC 4234 RFC 4287 RFC 4350

The following 19 RFCs used to have an article, but I have since merged the appropriate content and created redirects. If I'm going down the wrong track with this idea, these are things that may need to be reverted: RFC 822 Rfc 869 RFC 1 RFC 1483 RFC 1777 RFC 1778 RFC 1867 RFC 1959 RFC 1960 RFC 1982 RFC 2083 RFC 2119 RFC 2182 RFC 2246 RFC 2684 RFC 2822 RFC 3339 RFC 3951 RFC 4350

As RockMFR points out below, the GFDL requires attributions so any merged articles can not be deleted. I have checked of the 19 redirects mentioned in the above paragraph, and only RFC 1 actually had any text merged into other articles, hence it being struck out. Both RFC 1982 and RFC 2684 had significant content, but I moved them to more appropriate names so the redirects can still be deleted. The other 16 articles had content that was either redundant with the main article that they were redirected to, or had content that was too trivial to merge. So, the remaining 18 articles beside RFC 1 can be deleted]]. Wrs1864 00:50, 12 January 2007 (UTC) [reply]

OK, I'm all ears to hear what people think. Thanks for your time and consideration. Wrs1864 03:01, 22 December 2006 (UTC)[reply]

  • Comment - The ones that are currently linking to Request for comments should definitely either point to List of RFCs or be deleted. I know redirects are cheap, but these aren't very helpful at all. The ones that are pointing to the appropriate related article should probably stay as they are. --- RockMFR 03:09, 22 December 2006 (UTC)[reply]
    • Again, I think that even the redirects to things other than "request for comments" causes confusion and should be deleted. When people type FTP and get redirected to File Transfer Protocol, that's good. When people type RFC 0959, in practice, they almost always mean the actual RFC and redirecting them to File Transfer Protocol just creates confusion. When I went through and checked all the links to the RFC articles, even ones that point to the actual protocols, I didn't find a single one that would have been better to link to a wikipedia article instead of to the actual RFC text. Wrs1864
  • Comment I disagree with this in principle, if not in practice. There is room on Wikipedia for an article such as RFC 959 which would be better than a redirect to either the File Transfer Protocol article, the RFC itself, or List of RFCs. That is, the article could be about the RFC standardization process itself for a specific protocol, the iterations it went through during the internet draft stage and similar information. It may very well be that no article on Wikipedia has encyclopedic information on the RFC separate from the protocol it defines, but the potential for such an article existing and being good is there. JRP 16:09, 22 December 2006 (UTC)[reply]
    • In theory, I agree. In practice, the closest thing to the situation you described was with RFC 1, which described some history of RFCs. However, I felt this was much more appropriate to being in the Request for comments#History section and amounted to only a few sentences. So, as to the actual redirects being discussed, I think they all cause confusion rather than help. If such an article as you described was created, I wouldn't object to it. Wrs1864 16:32, 22 December 2006 (UTC)[reply]
  • Comment One person did remove the RfD flag on RFC 1149 saying that since it had been around for over 4 years, it should stay. I mentioned that, since then, wikipedia has created the built-in RFC linking and I thought that changed the situation. I tried directing the person here to make more comments. RFC 1149 is one of the April Fools RFCs and I guess I can see some why some people might want to have obscure redirects in order to hide the fact that there is a joke involved. Wrs1864 21:26, 27 December 2006 (UTC)[reply]
  • Comment I went through and checked the RFCs that redirect to specific articles to see how useful they would be in finding the actual RFC. Of the 55 that do so, 31 do a good job of having an external link to the RFC near the top. Another 16 have a link, but you would probably have to search for it, they are often in paragraphs or near the bottom of the article. The final 8 do not mention the RFC at all. Usually this is because the RFC has been obsoleted by newer RFCs, and the references to newer RFCs use wikipedia's builtin external link system. Wrs1864 21:26, 27 December 2006 (UTC)[reply]
  • Comment I think entering "RFC ####" into a search box should help a Wikipedia reader find that RFC. Perhaps this could be done through improving the Wikimedia softwar4e. In the meantime I think the redirects are important. It would be best fo every RFC search to display a list of RFCs with links to the associated internet request for comment. Some more important RFCs should have redirects to stubs with reference to other relevant articles. Even more important RFCs should link to stubs that are eventually expanded to full-flegefd articles on the RFC. So in order of importance (least to most):
"RFC ###" Go returns
  1. List of all RFCs with external links to the text of the RFC
  2. A stub article with links to other relevant articles on the topic (e.g., RFC 0959 redirect to a stub with a description like "RFC 0959 established the File Transfer Protocol (also known as FTP).
  3. A full-fleged article that talks about the RFC itself in relation to the technologies it spawned

Until the wiki software is changed, I definitely think these RFC_#### redirects should exist and redirect to one of those places. --WallsComeTumblingDown 23:55, 29 December 2006 (UTC)[reply]

I agree that entering "RFC ####" into wikipedia should help a reader find that RFC. The problem is, that out of the 100+ redirects, the vast majority of them don't help. They lead off to things like the generic Request for comments article, or to articles where the RFC link is burried. More over, with only 100 out of ~4700 RFCs having any redirect at all, we aren't really covering that many. Wrs1864 06:42, 30 December 2006 (UTC)[reply]
  • Comment OK, I've done some more research into the RFCs. I ran google searches on all RFC numbers from 1 to 4700 and found the number of hits.[1] It appears that the list of redirects that we currently have is a fairly indiscriminate list. As I mentioned above, many of them are for RFCs that have been obsoleted, and several are for ones that almost irrelevant (823-825), while some of the most frequently reference RFCs don't have any redirects at all (2219, 2616, 1766, etc.) I could write a program to extract the RFC title, abstract, and other information and create wikipedia articles for each one, but that would just be duplicating the existing systems such as http://tools.ietf.org which is what the builtin RFC linking system uses. Wrs1864 06:42, 30 December 2006 (UTC)[reply]
  • Is anything happening with these? This RfD is keeping 21 December 2006 on the main RfD page for quite a while. BigNate37(T) 02:20, 11 January 2007 (UTC)[reply]
    • I'm surprised it this wasn't closed a while ago, but I have done a bunch more research into this. I need maybe an hour or so to pull all the research together, so if the admins could wait to close it for a bit, I would appreciate it. Wrs1864 03:03, 11 January 2007 (UTC)[reply]

As I mentioned above, I've been pondering this and doing more research. Here is what I've found:

  1. There is a similar special system, like the auto RFC linking and that is the ISBN linking. I did a search, and there are only three redirects for ISBN numbers. I guess that gives weak support for deleting these redirects.
  2. Neither the RFC number nor the ISBN are, in themselves, notable. It is the standards and books that they reference that are notable. I think this supports deleting them.
  3. Other standard organizations, such as ISO and IEEE generally have their own pages, such as IEEE 754, or ISO 9660. However, both of those organizations charge money for copies of their standards and you can't make external links to them like you can with RFCs. Also, IETF standards are generally know by their protocol name (FTP, SMTP, UDP, etc.) rather than their numbers but some numbers are well known (e.g. RFC 2822). I guess this gives weak support to keeping these redirects.
  4. Talk:RFC 3066 actually has a bunch of discussion on this subject, most of it very old (ca 2004). I think it gives weak support to deleting them.
  5. [2] had it's redirect changed from Request for Comments to the appropriate article.
  6. I've been going through and replacing most links to things like rfc.sunsite.dk and faqs.org to use the built in RFC linking. What I see confirms to me that things like these redirects and the old URLs are cruft that was left over from before there was built-in RFC linking. Most of the RFCs that are referenced are old.
  7. User:WallsComeTumblingDown who supported keeping these links is apparently a banned sock puppet.  :-<

In conclusion, I feel much more comfortable recommending that all these redirects be deleted. They are left over cruft that cause confusion when link to them in articles. The list of RFCs with redirects is an indiscriminate collection, they are not the most important or most popular ones.

Ok, that's my thoughts. I would appreciate hearing from others, but maybe this subject is to obscure and not very important. Wrs1864 03:49, 11 January 2007 (UTC)[reply]

  • Delete all that don't target an article about the individual RFC itself, delink incoming links, per Wrs1864. The automatic linking should provide information in these cases. If there is an article about an actual RFC, the redir to it should probably be kept, as long as the article is more informative than the external link would be. Note that RfD is not the place to decide whether an article about an RFC should be kept; that's AfD's job. --ais523 11:30, 11 January 2007 (UTC)
    • There are no RFC articles that talk about the RFC itself. As mentioned above, the closest was RFC 1, but I merged the history found there into Request for Comments#History where I thought it was more appropriate. Wrs1864 12:22, 11 January 2007 (UTC)[reply]
      • I'm being paranoid, wording my !vote in such a way that it still applies even if someone creates one before the end of the RfD... --ais523 13:16, 11 January 2007 (UTC)
      • Comment - any of the articles that have had content merged somewhere else need to remain as redirects per GFDL requirements. --- RockMFR 22:13, 11 January 2007 (UTC)[reply]
        • Comment - D'oh! Good point. I have removed the RfD from RFC 1. RFC 1 was the only article that I remember having significant content that had any real merging done, but I will now go through and check them to make sure. Thanks for reminding me. Wrs1864 00:01, 12 January 2007 (UTC)[reply]
        • Comment OK, I've gone through and checked. Only RFC 1 needs to be kept. See the inserted text in the leading paragraphs. Wrs1864 00:50, 12 January 2007 (UTC)[reply]
The above is preserved as the archive of an RfD nomination. Please do not modify it.

UserbaseUsers' group or Userland or Userspace[edit]

The result of the debate was Deleted. Installed base is not exactly the same as user base and that article doesn't address the differences. Therefore, a red link seems better. -- JLaTondre 01:06, 29 December 2006 (UTC)[reply]

Yet another malformed redirect; this one tries to point to three different articles at once. The term "userbase" doesn't appear (based on an admittedly quick look) to have any specialized technical meaning; it looks to me like a simple compound of user and base. So I can't tell whether any of these redirects are really appropriate. --Russ (talk) 23:28, 21 December 2006 (UTC)[reply]

  • Comment - none of these targets are correct. The usual definition of userbase (that I know of) means the audience or users of a specific website or piece of software. We should have this redirect, but I'm not sure where to point it to. --- RockMFR 02:49, 22 December 2006 (UTC)[reply]
The above is preserved as the archive of an RfD nomination. Please do not modify it.

1 Corinthians 9:22First Epistle to the Corinthians[edit]

The result of the debate was Kept. -- JLaTondre 00:58, 29 December 2006 (UTC)[reply]

I saw this redirect in Category:New Testament verses and was wondering why a redirect was being categorized. We do not need a redirect for every single bible verse to go to the parent chapter or book article. I see no reason for an acception here. Andrew c 01:19, 21 December 2006 (UTC)[reply]

The reason for this redirect is that 1 Corinthians 9:22 is specifically mentioned as a subarticle within the article First Epistle to the Corinthians. There is not a redirect "for every single bible verse", only those that are mentioned within the parent article. Keep the redirect and make an exception. --Rajah 19:45, 21 December 2006 (UTC)[reply]
I'd like point out that too that it doesn't meet any of the criteria for deletion, and does meet criteria for keeping. [3] --Rajah 19:48, 21 December 2006 (UTC)[reply]
Keep as per Rajah. Mathmo Talk 01:12, 22 December 2006 (UTC)[reply]
The above is preserved as the archive of an RfD nomination. Please do not modify it.

1 Corinthians 13:121 Corinthians 13[edit]

The result of the debate was Kept. -- JLaTondre 00:58, 29 December 2006 (UTC)[reply]

I saw this redirect in Category:New Testament verses and was wondering why a redirect was being categorized. We do not need a redirect for every single bible verse to go to the parent chapter or book article. I see no reason for an acception here. Andrew c 01:16, 21 December 2006 (UTC)[reply]

The reason for this redirect is that 1 Corinthians 13:12 is specifically mentioned and discussed within the article 1 Corinthians 13. There is not a redirect "for every single bible verse", only those that are mentioned within the parent article. Keep the redirect. --Rajah 19:46, 21 December 2006 (UTC)[reply]
I'd like point out that too that it doesn't meet any of the criteria for deletion, and does meet criteria for keeping. [4] --Rajah 19:48, 21 December 2006 (UTC)[reply]
Keep as per Rajah. Mathmo Talk 01:13, 22 December 2006 (UTC)[reply]
The above is preserved as the archive of an RfD nomination. Please do not modify it.

St. Thomas High School, QuebecPointe-Claire, Quebec[edit]

The result of the debate was Kept as it is mentioned at target. -- JLaTondre 00:56, 29 December 2006 (UTC)[reply]

Simply an incorrect pointer. Redirect title is a school, but Pointe-Claire is the borough of the city of Montreal where the school is located. PKT 14:44, 21 December 2006 (UTC)[reply]

  • Keep. I believe this is the usual procedure for articles which violate WP:LOCAL. --- RockMFR 02:49, 22 December 2006 (UTC)[reply]
The above is preserved as the archive of an RfD nomination. Please do not modify it.