This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
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)
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)
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)
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:
Any thoughts on what to do with this one? → Ξxtreme Unction { yakł blah} 11:40, 13 December 2005 (UTC)
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)
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 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)
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)
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)
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)
Copied from Wikipedia:Deletion Review (in "SPUI v. SFD"), with emphasis added:
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)
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. R adiant _>|< 22:49, 26 December 2005 (UTC)
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)
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)
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...
Renata 13:14, 15 January 2006 (UTC)
I'm concerned about these two keeps:
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.
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
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)
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)
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)
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:
Any thoughts on what to do with this one? → Ξxtreme Unction { yakł blah} 11:40, 13 December 2005 (UTC)
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)
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 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)
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)
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)
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)
Copied from Wikipedia:Deletion Review (in "SPUI v. SFD"), with emphasis added:
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)
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. R adiant _>|< 22:49, 26 December 2005 (UTC)
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)
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)
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...
Renata 13:14, 15 January 2006 (UTC)
I'm concerned about these two keeps:
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.