Refer Dont Delete

Why delete a page if you can repoint the reader to the content they wanted when they got there? A good example of this is "TruckFactor" vs "TruckNumber". Both page names are valid enough, so put the content on one and put the "See: OtherPage" reference on the other.

Benefits:

Avoids rework. If I expect a page to exist, but find that it doesn't, I'll create the page. I might spend time researching the topic, thinking about it, etc. Now, I've created duplicate information. All because someone couldn't tolerate a "See: TruckNumber" link?
Searchability. You can't search the titles of deleted pages.

Costs:

A nominal amount of disk space.
That icky feeling that refactorers get when they don't completely, thoroughly destroy duplicated information.

Maybe something like DeletedAndRefactored (in the same vein as DeleteTestAndWelcome) would be OK? That way the original person is responsible for cleaning up after themselves but if they don't, then the page will still get cleaned eventually...

Well, that's not what I was intending. The whole idea is to keep the suboptimally named page. This way avoids allowing someone who doesn't know about the better name to write up new content under the old name. If the old name has a "See BetterName", they'll update their links and not waste time re-creating obsolete pages.

(Personally, I don't like "TruckFactor" -- I'd delete it. But I think "ReferDontDelete" does make sense on some other pages. -- jtg)

The problem with that is that someone else does like "TruckFactor", and being ignorant of TruckNumber will create the page for this important concept ... only now it won't have a handy reference to TruckNumber, being a brand new page. Consequently content (possibly redundant) gets added the TruckFactor page, which creates a refactoring problem for those that do know of TruckNumber.

But then you end up with a bunch of pages, half of which refer to TruckNumber and half of which refer to TruckFactor. 100% of the pages mean to refer to the same page but they don't because they weren't refactored. I don't have a problem leaving pages that are often misspelled (like YouArentGoingToNeedIt vs. YouArentGonnaNeedIt) but referring pages should be refactored to point to the canonical page as soon as possible so that the content is in one place and it doesn't take four clicks to get to it... just my $0.02 CDN

If you find a link which points at a reference, then fix the link. Simple. Ask yourself, which is easier for the WikiGnomes to clean up:

a link which points at a reference, or
a blossoming page with extra content to be either merged with the canonical page or deleted because it's redundant, and then also going back and fixing the link which points at the page you are about to delete?

One problem though -- if the links are getting fixed, you wouldn't be able to tell if that wrong name page is something really obscure and no one ever linked to it ever (in which case the page should actually be deleted), or alternatively its a common mistake to use that wikiname but the evidence keeps getting cleaned up. Suggestion: if a WikiGnome does fix a double-reference link they could also add a "fixed [offending page]" to that referring page. Over time there will accumulate the history of mistakes, making it plain it's a common mistake.

I'm refactoring UnitTesting -> UnitTesting (and may do UnitTests -> UnitTests, if I'm really bored). I rewrote UnitTests to say "see UnitTest", followed by a suggestion to the reader to fix the UnitTests link on the referring page. Also, I've kept a count of decreasing numbers of backlinks as I've refactored. I was planning to remove the countdown when refactoring was done, but I may leave it to indicate how many links there used to be.

Examples:

TruckFactor -> TruckNumber [Maybe we should RefactorDontRefer on this one.]
RefactoryBrowser -> RefactoringBrowser [A really good example of ReferDontDelete.]
YouArentGoingToNeedIt -> YouArentGonnaNeedIt [A keeper: I thought "YouArentGoingToNeedIt" was the correct term. -- JeffGrigg]
AgileSoftwareDevelopment <-> TheBookAgileSoftwareDevelopment [I'd rather refactor these into one page, but doing so would interfere with AlistairCockburn's contribution. (He's the author of the book, so I should defer to him on the page(s) about his book.) -- JeffGrigg]
OnceAndOnceOnly -> OnceAndOnlyOnce
ReFactoring -> WhatIsRefactoring
MercilessRefactoring -> RefactorMercilessly
PervasiveDevelopmentDisorder -> PervasiveDevelopmentalDisorder
UnitTests, UnitTesting -> UnitTest

I call the list above "the good, the bad, and the ugly." ;->

The objective of giving lots of examples of usage is to help us see which usage is helpful and appropriate, and which useful is harmful/wasteful/bad. -- JeffGrigg