This 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 ThreadMode''''''s 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 : Aside: [''Webster's gives - Hypobole, n. (Rhet.) A figure in which several things are mentioned that seem to make against the argument, or in favor of the opposite side, each of them being refuted in order.'' : Neat, eh? I was thinking of the SelfDocumentingCode pages when I looked that up. Maybe it would be fun to describe hypobole ala SummaWay.] I remember when all those singleton pages got spawned, and most of them clearly didn't need to exist on their own. I must first admit that I haven't really read SingletonsAreGood or SingletonsAreEvil, just glanced through them to see what they're about. I must also admit that I wasn't paying attention the first time you tried to delete SingletonsAreGood. I am therefore hereby ''speculating'' that maybe the reason it was undeleted is because it wasn't clearly explained why it was deleted. Did you leave a note explaining the deletion? Was there any sort of discussion leading up to it? I don't see any remnants of that, just a note at the top of the page mentioning that it was deleted then undeleted, but with no explanation as to why. To be honest, I don't even care about those particular pages, but if I saw them deleted without explanation, I just might restore them out of reflex (not in this case, but hypothetically). -- rh (correct me if I'm wrong) 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.) -- LaurentBossavit ----- 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 ... * delete experiment * delete misspelling of ... * delete, refactored to ... ---- Someone objected to deleting pages that have active BackLink''''''s. 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 BackLink''''''s first? If I were as eager to delete as you, I would probably use the following pattern: 1. Click the Title 1. If links are found, either: * Un-wikify the name, or * Refer to another page that describes the same material 1. Once links are removed, delete the page. This shouldn't be too much trouble. Basically, it's probably best to take the position that if someone is too lazy to fix references to a page, then they shouldn't be taking the time to delete that page. -- RobertDiFalco I saw Phil's deletion of Sc''''''Rum 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 BackLink''''''s are fixed. Initially, this ''[the insistence on fixing the links -- GP]'' seemed picky, but when I searched for BackLink'''''s, there were only a couple (not counting Changes pages). (So, of course, I fixed them.) In the case of Sc''''''Rum, there was an obvious replacement destination page: Scrum''''''Methodology; 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 BackLink''''''s (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 BackLink''''''s for S''''''cRum 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 C''''''ountedPtrImplementation (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 ''C''''''ountedPtrImplementation'' 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... -- RobertDiFalco What's the big deal with DanglingLink''''''s? Wiki has lots of those. Deleting a page just turns all WikiName''''''s 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: * a link that should go somewhere (the new page) doesn't - functionality that could easily be there isn't * someone might come along and decide to create a page for the DanglingLink, unaware that such a page already exists (in the new place) - now the original problem is back (incorrectly-spelled title, split content, etc.) I basically agree with Robert: don't delete a page until all references to it have been fixed. But I also have some sympathy with Phil, even though I think he's being too aggressive with the actual deletion. So I reiterate my suggestion, which amounts to refactoring by increments: 1 Move the page's content to the appropriate place 2 Put a "Content moved to X; please link to there" message on the original page 3 Fix links until you're sick of fixing links 4 When ''all'' the links are fixed (by you or someone else), go ahead and delete the page I can see why Phil would disagree with this, but I think it should satisfy Robert's (good, I think) principle: '''Don't delete pages with active links to them'''. -- GeorgePaci ''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 * Just an experiment, maybe? * ''It would help RandomPages if it ever got run again.'' * It allows us to delete pages with indecent names. * It makes searches go faster * It makes http:wikiList more interesting * There is no reason to keep the 'I can really create a page on Wiki?' pages. * Some pages (especially typo-titled ones) are effectively traps * We should practice what we preach - if it's good to FixBrokenWindows in your code, then why not in wiki as well? * Occasionally someone will add a page that is extremely redundant with a previously created page. We don't want people to be unwittingly conducting parallel discussions/syntheses about the same concept on two different pages. So it's legitimate to delete the newer page. It's even more helpful to find the newer page's backlinks and point them to the older page. (If changing backlinks doesn't seem right, maybe the new page isn't so redundant after all.) ''Or: OnceAndOnlyOnce.'' ---- 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. ---- CategoryDelete