When To Delete Pages Discussion
When To Delete Pages DiscussionThis page is mostly discussion about deleting pages. See DeletionConventions for more about when and how to delete pages.
Don't delete something if it is on topic and unique. Even the same thing said in a different way can be valuable. Use your judgment.
I emphatically disagree. If RavioliCode is bad, RavioliWiki is worse. I refactored some pages together to form SingletonPattern, but someone restored SingletonsAreGood after I deleted it. If SingletonPattern is hard to read, fix that, don't leave a bunch of garbage ThreadModes lying around. That only lowers the quality of the entire wiki. (Think about it: http://c2.com/cgi/wiki?search=Singleton) The goal of a spring cleaning should be to improve the utility of RandomPages. -- SunirShah
Sunir, I normally agree with you, but I don't understand your point of view here. Both the RavioliCode page and RavioliWiki page are contentious, so I don't see that as convincing evidence. What's wrong with a SingletonsAreGood page? It contrasts SingletonsAreEvil. I think the reason it was restored is because it wasn't clear in the first place why it was deleted. And finally, I seriously disagree with the purpose of spring cleaning being to improve the utility of RandomPages. RandomPages has marginal utility as it is, and I don't think it could ever possibly have much more utility (regardless of how many pages were deleted). The purpose of spring cleaning should be to increase signal and reduce noise. This would have the side effect of improving the utility of RandomPages, but that's about the only connection I can see to RandomPages. -- RobHarwood
I would have deleted SingletonsAreEvil if I had time to refactor it. You suggest that someone restored SingletonsAreGood based on its name alone - did someone restore it without reading it and SingletonPattern? Certainly it was clear what was happening from RecentChanges, when a dozen or so singleton-related pages were listed as being moved to SingletonPattern.
As for RandomPages, I chose the meekest example (a hypobole, if hypobole really meant the opposite of hyperbole). Deleting cruft is always good; RandomPages was the least important thing that would benefit. There are many others. That should be evident to all programmers, especially those attracted to the principles taught in this place. -- SunirShah
I tried to be very clear, but I cannot be a judge of how successful I was. I wonder if you really would react as reflexively as you claim; I'll give you more credit. Still, I've often looked at new pages and said to myself there are older pages that say it better. If it's impossible to collate them, because the CommunityDoesNotAgree, then I'm not going to bother refactoring any more. Admittedly, I had already given up after the last time I got flamed for trying. -- SunirShah
I have restored SmalltalkGroup, which was nominated for deletion with the comment "delete orphan". I restored it because (1) I think it's a no-brainer that a page by RalphJohnson pointing to a Smalltalk group is OnTopic for a forum about PeopleProjectsAndPatterns, and (2) no page is truly "orphaned" as long as the FindPage searches are still working. If someone goes to the FindPage and enters "Smalltalk" in the "search titles" box, SmalltalkGroup is absolutely one of the pages I want to have come up.
Let's not go crazy about this deletion thing, OK? Solidly OnTopic material should almost never be deleted. FindPage and RandomPages can cause presently unlinked material to resurface at any time. Suggestion: if a page is "orphaned" (i.e. not linked to by any other page) but obviously OnTopic, then instead of deleting it, go to other, related pages and link them to the orphaned page. (If it's really OnTopic, and wasn't just created this morning, there will almost certainly be other related pages.) Remember that LinksAreContent, and creating appropriate links adds at least as much value as deleting (I would say more).
While I'm on the subject of when not to delete: the mere fact that a page hasn't changed in a while is not a reason to whack it. In GoodStyle, WardCunningham urges us to "edit pages to emphasize the flow of ideas, not the chronology of contribution." As we refactor a page to ConvertThreadModeToDocumentMode, the idea is that a definitive consensus on that page's topic will emerge, and this is considered a GoodThing. It is only natural that after this has happened, the page will not change much. (Once the discussion is over and the dust has settled, anything good that remained is captured in the DocumentMode page - that's the theory anyway.)
My point is: if you accept this idea of how Wiki pages should evolve toward maximum usefulness, then the best pages will be stable. So to adopt a policy that "this page hasn't changed in a year, so it's toast" is harmful to the goal of raising the quality of Wiki.
I mention this because I have seen "venerable" pages disappear for no other reason than that they haven't been churned lately. For a site that aspires to assemble an InformalHistoryOfProgrammingIdeas, it doesn't make sense to erase the historical pages once the history has been written.
-- CameronSmith
I have restored DmozSorryForIntrusion? and OpenDirFaq?. These pages told a story, they had content. Whether this content is valuable is up to subjective assessment. But Wiki has a tradition that questionable content is not thrown away without reflection but either refactored away or refactored to perfection, preferably in small steps.
Accordingly, in the interest of averting eventual DeletionFlameWar?s and hopefully eliciting a discussion of WhenToDeletePages, I'd like to formulate my policy in page deletion, as follows.
When a deleted page shows up on RecentChanges, I will second the deletion if the deleted page was semantically empty before the deletion, i.e., it contained gibberish, or stuff more suited to the SandBox.
If the page had any content before the deletion, however out of place on the Wiki, I will restore the previous copy, unless there is some indication that the deletion is voluntary and effected by a major contributor to the page.
In all borderline cases, I will do nothing. (The pair programming testimonial "stub" pages are an example.)
Perhaps it would be good if the first delete (the motion) included a word or two of explanation. Here are phrases that one might use ...
Someone objected to deleting pages that have active BackLinks. I say don't foul the waters with a BigWikiProject? just delete the page and get on with life. If people (including you) care about the backlinked pages then they'll fix the links as they come up. The natural consequence is that nobody will bother to fix those pages that nobody cares about. That's a good thing because then those people will be spending their limited supply of time on things that people actually do care about. -- PhilGoodwin
You have to be more careful (or at least more patient). If you want to take the effort to delete a page, why wouldn't you take the time to fix its BackLinks first? If I were as eager to delete as you, I would probably use the following pattern:
I saw Phil's deletion of ScRum on RecentChanges, and noticed it wasn't actually empty. When I went to it, I saw "Deleted, fix broken links later", and in the previous version, RobertDiFalco's complaint that pages shouldn't be deleted until their BackLinks are fixed.
Initially, this [the insistence on fixing the links -- GP] seemed picky, but when I searched for BackLinks, there were only a couple (not counting Changes pages). (So, of course, I fixed them.) In the case of ScRum, there was an obvious replacement destination page: ScrumMethodology; all the Sc'Rum content was replicated there, plus a lot more. And now, I'm trying to move all of that content to ScrumProcess, a more appropriate name
But it's not always clear where a link to a deleted page should point; in that case, either: 1) fix all the BackLinks (if practical) or 2) set up a forwarding message at the page which also asks readers to update the link that sent them there. After a while, when the page is no longer linked to, go ahead and delete it. -- GeorgePaci
I think the bigger question is why is a page with active references being deleted? I kind of get the feeling that people are starting to delete just because they can. However, if you don't feel strongly enough about a page to deal with its references, then you probably shouldn't be deleting it. I fear Wiki Spaghetti. Remember, it was easy to fix the BackLinks for ScRum because the page wasn't deleted yet. Once it is deleted, it never existed. After a couple of days, and unless you had special knowledge, you wouldn't even know to search for it. Another example is inconsistently changing references to a deleted page. I don't mean to pick on Phil, but consider CountedPtrImplementation (an implementation of the counted_ptr specification in the standard library proposals for CeePlusPlus). Phil deleted this page after moving its contents to a new page called CppCountedPointerImplementation, which is fine. However, he only fixed one of its references, leaving another document that pointed to CountedPtrImplementation with a DanglingLink. Fortunately, I was able to click the original's title before it was deleted all the way to repair this.
Basically, if you don't take care of references first, you are not doing Wiki any good. Either (a) someone will click the question mark of the broken link, creating a brand new page with the same title again or (b) created confused and conflicted links.
One has to remember to ask themselves, why do I feel compelled to delete this page before fixing its references?
Just my two cents...
What's the big deal with DanglingLinks? Wiki has lots of those. Deleting a page just turns all WikiNames which point to it back into unlinked, question-mark WikiPrompt?s. This might be the right thing to do. When would it not be the right thing to do? -- [SignMe?]
Read what Robert wrote above. If someone moves a page's content to another page (e.g. to one with a correctly-spelled title, or to consolidate needlessly split content), and leaves a link to the original page somewhere, and deletes the original page, you get a couple problems:
LinksAreContent. Breaking links destroys content.
I'm still not sure what is gained by deleting any pages at all. Is the c2 harddrive getting full? -- AndyPierce
Before deleting pages you disagree with, even though they aren't semantically empty, think about what Wiki would look like if people you disagree with adopted that behavior. Semantic emptiness should be the OneTrueTestForDeletion?. -- GeorgePaci
Consider what Wiki would look like if all sorts of invective were deleted. If all the angry words written here became slowly more civil. If all the emotional points made became lucid and clear. Anything worth saying can be said civilly. There are ways to say "I don't like MFC" without saying MfcMustDie. I deleted that page not because of its message, but because of its tone. I'll defend peoples right of expression vigorously (and have done so on this forum more than once), but not their right to express themselves publicly in any vile way that they choose. Anything anyone writes here on Wiki represents all of us. If you want to complain about MFC then MfcProblems? or PitfallsOfMfc? would be much more appropriate and effective place to do so in the long run than MfcMustDie. I would have moved the discussion to a more appropriate page except that it seemed pretty much content free anyway. -- PhilGoodwin
Sorry, Phil, I shouldn't have said "must die." I apologize. I forgot that even anonymous people are people.
On to much less important points: I honestly don't think MfcMustDie was "vile" when it was deleted. Saying a software library must die doesn't hurt anyone's feelings any more than saying it's mostly broken does. In fact, because it's comically hyperbolic (software never dies, especially COBOL), it probably hurts the author's feelings less.
That said, I'm glad your motive was civility rather than disagreement, even though I still disagree with your action. I guess I was afraid people were going to go hog-wild deleting pages they disagree with. -- GeorgePaci
Oh, MfcMustDie ranks fairly low on my "vile" scale - we've had much worse than that. It's just that its heat/light ratio didn't meet my exacting standards. One of the things that makes me feel free to do a deletion like that is knowing that there are people like you who'll put things back if they think I've been too hasty. Actually, it's usually me who's doing the restoring and someone else who's done the deletion, come to think of it. Well it's nice to change roles now and then. Mind if I condense this down a bit? It's gotten a bit chatty. -- PhilGoodwin Refactor away. -- GeorgePaci
Relying upon other people to restore a deletion you do, if you did it too hasty, makes the whole thing quite arbitrary, or what do you think? On the other hand, I may be too sheepish if it comes to deleting pages. -- MarkoSchulz
It relies on the theory that none of us is as smart as all of us. I won't delete a page unless I really think that Wiki will be better off without it. There is no excuse for acting without thought. But there is always a chance that I'll get it wrong. The fact that two people have to agree in order for the deletion to go through, and only one person to reverse it, makes it a lot less likely that something of value will be destroyed. In the future, though, I think that I'll try to move things and clean them up rather than deleting them outright, even if there is very little to salvage. That's closer to my past policy and seems to work better. -- PhilGoodwin
Those references don't show that at all: http://www.usemod.com/cgi-bin/mb.pl?StanfordPoynterProject just shows that users reading news (a specialized task) tend to read shallow and wide. And http://www.usemod.com/cgi-bin/mb.pl?HubAndSpoke seems to be saying that people tend to follow links to a certain depth, then back up. Neither deals with density and whether it's liked, as opposed to somehow being fully used. Given that Wiki works, why mess with its intentionally dense linking?
Be aware that the database used by the links search is updated only weekly. A page may wrongly show as having no backlinks because it is too new for them to be included in the search.
If you care about backlinks, it may be best not to delete pages until they are at least a week old.
But will that pick up links that have been added in the past week? Maybe we should have a policy of dating the initial delete and we don't do final deletes until at least a week later. That would also allow more time for peer review of the delete.
If we wanted creeping featurism, we could have the actual delete take place a week after the second user OKs it, to allow more time for it to be reversed.
I restored the Gary Young HomePage. The notion of deleting people's home pages, even in the name of good housekeeping, makes me uneasy.
Some abandoned (short) home pages are being deleted - a little longer should be allowed between 'proposing' and 'seconding' the deletion, rather than both occurring on the same day.
I've noticed that there are a lot of deletions going on at the moment. Often, looking at RecentChanges, it seems people are deleting pages when the best action would be to add content to them, or link better them into the rest of the Wiki.
An example is ExceptionHandlingRoadmap?. I remember when there was a lot of activity in the area of exception handling: good/bad practices, exception handling patterns, how to design exception class hierarchies, etc. I can imagine that the ExceptionHandlingRoadmap? page was created to give an overview of the whole topic, somewhat like the ExtremeProgrammingRoadmap page. Perhaps it never got finished. That does not mean that it is would not be a useful page if someone took the time to write it.
Therefore: please try to add content to pages or link pages into the Wiki rather than deleting them.
If you don't know how to add content to a page, perhaps you don't have the background to decide whether it should be deleted.
Deleting a page means that nobody knows will ever write it. Leaving a sparse page will inspire somebody to add content to it eventually.
Linking pages into other parts of the Wiki helps people find pages that need some more work. I've noticed that there are a lot of deletions going on at the moment. Often, looking at RecentChanges, it seems people are deleting pages when the best action would be to add content to them, or better link them into the rest of the Wiki.
I was the one who initiated the delete, because the content had been moved to another page, and ExceptionHandlingRoadmap? had no backlinks. -- FrancisHwang
I seconded the deletion. It looked to me like the page had been refactored into the page that it referenced, and replaced with a 'see otherpage' link - a quite reasonable refactoring. Any links to ExceptionHandlingRoadmap? that had existed no longer did (presumably replaced by links to the referenced page), so the final stage in the refactoring is to delete the original page, which Francis did. I agree with your point, but unreferenced content-free pages are a special case, surely - nobody is likely to add content to them because they're unreferenced and hence will not be found, and there's no point in linking them into the other parts of Wiki because they contain no content. The only solution I can see is deletion. -- TorneWuff
Fair enough. I agree with that. It's just worrying to see big blocks of deletions, especially when the page names do not look content-free. Unfortunately, by the time I see many of the deletions on RecentChanges, the reason for deletion is no longer apparent.
Ok, a solution might be to log the first line of the last content of the deleted page on RecentChanges. I know that would introduce another feature, but a solution it might be.
EditText of this page
(last edited October 5, 2004)
or FindPage with title or text search