Deletion In Wiki

Deleting should not be used as a means of disagreement and control. This is a community wiki and should reflect its commonly acceptable practices and should accurately and sensibly present its concerns.

This page provides a guide for deletion. -- DonaldNoyes

The following was written before the deletion taboo was broken. I've kept it because there are some safeguards here and to emphasize that I was arguing that everyone should delete more, not that a few should delete everything!

-- RichardDrake

I believe that we need to break the taboo about deletion, in every Wiki reader's mind, not just a few. Deleting a person's signed contribution that has clearly been made redundant by other contributions, for example, is trivial and fine. It's the risk any of us run when we put something up on Wiki. No offence should be taken.

Deleters: This should not be abused. Work in a pair if you can - see PairRefactoring.

Deletees: It will be abused at times. Complain only when you think that a significant abuse has occurred. I'm suggesting RefactoringNotes for such complaints, if not the page itself.

Everyone: We must reduce the crud on Wiki. Be bold but compassionate at the same time. May the forceps be with you.

(Technical note: I was a ForcepsBaby?. They told my mother that the deletion (or crushing) of what seemed a large part of my brain at the time she first looked at me might sadly have a permanent effect. She has always argued privately that it did. This may or may not have something to do with my views on this or any other subject. But at least I survived to the extent that my sanity can be debated. See WikiIsDead and get the forceps out. We don't have much time.)

-- RichardDrake

I put some infrastructure in place last week so that I could delete stuff and still feel comfortable. I've also been doing a bit of housecleaning and the thing that I'm finding is that I don't see much deleting to do! Eventually, when I've dumped enough stuff into CategoryWikiMaintenance or CategoryException I might end up refactoring some whole categories and then I might do some actual page deletions and other larger scale changes but I don't really see that as what's needed right now. In fact, the stuff that I'm most tempted to delete is all of our rambling about how to refactor and edit and delete stuff. The rest of Wiki seems to have gone back to producing actual content. -- PhilGoodwin

But there is a tremendous amount of repetition here - on refactoring for sure but also on ExtremeProgramming say. I believe that it's very hard to see how this could have been improved without more deletion or at least what DavidHooker more politely calls distilling. In practice, it's now almost certainly too late for most of the old XP pages. So my only answer (and I accept it's only a partial one at best) is to encourage much more radical refactoring while threads are active. The main barrier I've found personally is the DeletionTaboo?, on signed contributions especially. -- RichardDrake

Example where deletion is needed: ChanningWalton created StringBufferExample at the same time as WayneConrad added an almost identical example to StringBuffer. (Yes, they were surprised by this concurrence of such a large amount of work). There are minor differences in the examples, but they are pretty much redundant. Merging the two examples would require deletion, not just of material that is the same, but of material that is slightly different but not significant.

I'd like us to consider a different model - why are we so averse to having multiple perspectives of the same issue? Disk space is surely not an issue, when I can buy 33G for $200.

A reading of the Hebrew Scriptures, informed by good scholarship, offers an illustrative example. The compilers were redacters and editors, through and through. We have therefore inherited a rich fabric that contains the same stories and themes, retold over and over - but with each retelling reflecting a different perspective. I suggest that the willingness of the editors/redactors to merge multiple tellings, without editing them to conform to a common viewpoint, is a deeply fundamental aspect of the value of this text as literature, history, and culture (regardless of our spiritual perspectives).

By preserving the integrity of each source's material, the redactors give us readers, thousands of years later, a much greater ability to come to our own understandings of the similarities and differences, and thus come to our sense of the importance of each source's viewpoint. It also allows us to come to know, in a much more intimate way, the personality - the humanness - of each source.

While I don't suggest that we are writing scripture here, I do think that this medium (and Wiki is surely a medium) greatly encourages this style of "literature": summary pages, consensus testing, attempts to state common grounds - these can all happen without deleting the source material that leads to it.

It seems to me that very fact that ChanningWalton and WayneConrad contributed nearly identical examples is itself significant, interesting, and important. It is a phenomenon that will, in my view, be essentially obscured and lost forever if the two examples are "edited" together into one. I would prefer to see these two contributions left as-is, so that their simultaneity can be rediscovered and explored by those who come later.

In my view, none of us has enough foresight to understand what will become important to those who come after us. Suppose one of our younger participants blossoms into world-famous SoftwareWizard? - and suppose that wizard offers a unique and compelling written voice. Is it unreasonable to fantasize that Wiki might be the arena in which that voice is developed? Wouldn't it be a shame if our redactors and editors removed that material because it was viewed as "redundant", or "refactored" into the other pages so that the author's identity was lost?

Surely this community has already significantly influenced our industry and therefore our culture, the GangOfFour book, KentBeck's books, MartinFowler's books, and I think we therefore have an obligation to ourselves and to those who will someday study us to intentionally, if we can, leave behind our source material.

In the early years of the recording industry, studios routinely erased and reused spools of studio magtape, thus destroying priceless recordings of artists who later became recognized for their unique talent. Imagine the value of an undiscovered trove of Ellington tapes, or Louis Armstrong, or John Lennon, or whoever your favorite artist is.

I hope that nobody reads this as negative, derogatory, or attacking. I am attempting to remind us, again, that we are significant, that we are making a difference, and that we will therefore be studied, written about, and learned from.

-- TomStambaugh

I am a very new member here so forgive me for making some errors. I agree that very similar entries, particularly regarding coding should be retained. One reason for this is that seeing the same technique multiple times lends credibility to all of them. One possible improvement in this case would be to edit each page with a 'see also' link to the other page(s). -- RichardEllis

Thank you for improving the quality of a page I started Tom and of our overall discussion of the "redaction" issue. Nobody in their right mind should take that as derogatory. I and I hope others will think seriously about what you've said here. -- RichardDrake

Although I strongly agree with the sentiment, I don't think Wiki is really a suitable technology to be used as Tom suggests. I'd like to see a fullish audit trail and archiving of content so we can drill down and find out what happened long after the event. But I also think there should be a more-or-less definitive "current state of the Wiki" which has all the dross eliminated. History, though sometimes important, is often just distracting and confusing and so should be hidden. Wiki's mechanism for hiding - i.e., letting pages fade from RecentChanges - just isn't always good enough.

I agree, and have long felt, that an unintrusive Envy-style write-once repository would be an ideal backing-store for Wiki. -- TomStambaugh

Until it gets better, I think deletion is sometimes best. I have just argued on MeatballWiki that part of Wiki's value is the way it forces consensus and synthesis. StringBuffer would benefit from synthesis. Our concern for history should not prevent us from making that synthesis. -- DaveHarris

Dave, my view is that the "force" towards "consensus and synthesis" is coming from the community that desires it, not from wiki itself. This doesn't make it a bad thing, I only mention this because I view it as a community norm that is separable from the medium. I don't understand how deleting source material for examples that lead to a consensus about StringBuffer is forced in any way. I don't see how the presence of the multiple examples detracts from the value of the StringBuffer discussion. Thus, I don't see how the presence of this source material in any way "prevent[s] us from making that synthesis". I simply don't understand the "need" for deleting old pages. At worst, they use a WikiName, so why not just rename them and leave them there? -- TomStambaugh

The force comes from community as well, of course. I think the Wiki form encourages consensus because pages don't have alternate views. At most they have alternate pages. And each page represents a consensus in that if somebody disagrees with it sufficiently they will change it. A Wiki which kept all edits and allowed us to hide edits by people we didn't like, and so presented each of us with our own view of each page, would not encourage consensus so much.

I should say that by "consensus" I don't necessarily mean a DocumentMode summary that only states the answer. I would also like to see DialecticMode summaries, abstract dialogues which include all points of view stated as succinctly and elequently as the assembled masses can manage. I am not trying to remove diversity. I want diversity to be expressed in the strongest possible form. Consensus can mean everyone agrees that all important arguments are represented, even if they don't agree on a conclusion.

I agree about not deleting old pages. However, there is a granularity issue here. I felt part of the problem with StringBuffer is that one of the examples was not on its own page, but an integral part of a larger text. I'm happy to leave the StringBufferExample page more or less as-is, but I feel the example on the StringBuffer page should be "upgraded" to the best example we can manage. And that means the old example on that page should be replaced on that page. Now, if you want to move it to some other place before deleting it, eg StringBufferArchive?, then I would be fairly happy with that. Except that for every page to have its XXX_Archive page seems like overkill. As WayneConrad said, it is turning humans into versioning tools. Wiki isn't meant for it.

This granularity issue is probably the crux of our disagreement. -- DaveHarris

If you want Wiki to be a historical archive, you must add versioning. To try to create a historical archive without versioning is to try to force all Wiki editors to be versioning tools. -- WayneConrad

I agree that a versioning Wiki would be better (as I said above). I recognize that without such a tool, some material will unavoidably be lost. I view that as a necessary part of the current state of the world. We don't need to "force all Wiki editors to be versioning tools" in order to avoid the intentional deletion of pages, however.

The pages will sit there indefinitely, not harming anyone. No one seems to dispute my observation about storage space, so the deletions don't appear to motivated by a desire to save space. I simply don't understand *why* some of us feel so driven to remove this material. For me, it leaves too strong a taste in my mouth of a desire to purge the environment of ideas or thoughts that some deem undesirable. It is that unwillingness to simply leave diversity alone that I think lies at the heart of my discomfort. I don't care that strongly, by the way, I just think that it *does* need to be said. -- TomStambaugh

Tom, thanks for a viewpoint arguing for non deletion that I can understand, and somewhat sympathize with. Perhaps there is a further nuance involved. I agree that removing differing ideas is bad, and thus even if consensus is reached and placed at the top of the page as DocumentMode, keeping disenting ideas is a good idea. It tells us how we got to the consensus. What I question, though, is the idea that any word typed in has enough value to stay on Wiki forever. Usually in ThreadMode, several people make the same arguments, sometimes repeatedly. What is lost by removing the redundant arguments? The analogy that I keep thinking of is editing a book. An author writes stuff down, and then clarifies, trim, focuses, etc, so that the reader does not have to wade through every thought he had on the topic. What is left is far more useful to the reader than a collection of every delevoping idea the author had on the way. Using the example cited above, combining StringBuffer into one example saves me (the reader) time. I would prefer a combined page which contains the best points of the two contributors, and not have to read so much stuff twice. Otherwise, I fear Wiki will get so big, and have the nature of an unreadable lab notebook, that it won't be very valuable to very many people. Lab notebooks have their place (protecting a patent, for example), but are not intended to be very useful to the common audience. (This paragraph itself could probably be pruned to remove redundant arguments, so I'll stop. :-) --

Richard, I wasn't thinking of comments in ThreadMode so much as stand-alone pages. I'm surely not arguing that "any word typed in has enough value to stay on Wiki forever" - this is all soft and subject to discernment. I certainly agree that in a long ThreadMode page, no harm is done by combining redundant arguments. To use your analogy, I'm suggesting that the interim drafts that an author creates have great value as interim drafts - the very unfinished-ness of them is what makes them valuable. Of course these drafts are then edited into final form, usually multiple times. I'm asking that we not delete those interim drafts after the edit is done (onto a new page). Many authors keep such material themselves, for similar reasons.

I wonder if perhaps your fear that "Wiki will get so big, and have the nature of an unreadable lab notebook, that it won't be very valuable to very many people" misses a distinction between Wiki and other kinds of material. Unlike a linear text like a notebook, the usability of Wiki is not harmed by having lots of pages - if anything, it is enhanced. The chance collision of WikiNames, when an author of a new page happens to stumble on an existing, even very old, page is one of its magically wonderful aspects, something very much like learning itself.

I agree that is helpful when someone puts up a combined page in situations like the StringBuffer example, so that you don't have to read the same stuff twice. I simply don't understand the desire to then, after the combined page has been created, come back and delete the source pages. It is that second step that I have a problem with. If nothing else, leaving the original material lets each of us explore whether we share the redactor's view of what is important and common. We can then redact the redaction - something that, in my experience, happens all the time during consensus-building.

I guess that the bottom line, for me, is that I think the risk of deleting information that later proves valuable outweighs, for me, the benefit of having fewer pages in Wiki.

-- TomStambaugh

Tom, let me say I very much appreciate your comment in your first paragraph. I am ever so glad that you see no need to preserve all the redundant arguments in a given ThreadMode page. The rest of your post raises this question for me: If Wiki had some mechanism to sort pages by "edited-ness" I would agree. But, I am unaware of this facility. The two tools I am aware of (RecentChanges and FindPage) are both unable to do any ranking for me, so I am forced to read all of the historical stuff, just to get at the best knowledge attained to date. This is the problem I am seeking to avoid by reducing Wiki. I would appreciate any insights about doing this short of using reductionsists methods. Respectfully, --

I put a bunch of stuff in HowToWriteAndEditThreadMode that was supposed to address this issue. Does any of that seem appealing to you? I think that Extract inline responses, Organize threads, Group threads by subject and Label threads should all do something to alieviate the problem. I'm not saying that redundancy should never be deleted, but these techniques should go a long way toward making pages readable and maintainable without resorting to deletion. -- PhilGoodwin

HowToWriteAndEditThreadMode has good ideas, and I would think anyone attempting to edit ThreadMode would do well to read it. I somewhat disagree with taking it offline, as the rest of the community would miss the "work in progress", and would not have input.

But, I guess my larger point is that I fundamentally think Wiki would be improved by more deletion. Not malicious deletion, by any means, but deletion of that which is not needed. Of course this is subjective, so some deletions will have to be undone. Also, please note that I am arguing for an ideal, not a particular instance. To the best of my recollection, I have never deleted any but the most trivial of words from Wiki, apart from my own. According to the current WikiSocialNorms, I have not felt free to do so.

Any large collection becomes increasingly useless without proper tools to access the collection. For libraries, we have index systems. For code, we have grep. I don't see any such tools for Wiki, and hence I feel the need to make what is here more useful, by refactoring. (So there is less to find and read.) Refactoring cannot work if the only possible action is addition; subtraction is the balancing tool needed. Using the word refactoring, though, is appropriate, as I do not seek to change the message of a given page, but merely make it more clear what the message is.

Richard, thanks for clarifying your perspective on this. In my view, because Wiki is a hypermedia, the links in Wiki *are* the analog to the index system of a library. Thus, from my viewpoint, wiki offers an implicit index system that is softer, more pervasive, and more powerful than any explicit system I've used. Part of its appeal, to me, is that its index system overlaps with its content - an "index" is itself just another page. I'd like to offer an organic metaphor: to me, Wiki is more like an alpine meadow than a carefully-tended lawn. Yes, there *is* enough content that some of us lack sufficient time to find and aread all of it. I've therefore learned to rely on the community to abstract it for me. When I poke at a particular area that has become more lush since I last visited, I would like the original "growth" to still be present (in some form) so that I might expore it myself. -- TomStambaugh

: Tom, perhaps I just don't get it, but I'm not sure what to make of the "the links are the index" view. How do the links help me personalize what I see and read on Wiki? --

The flip side of the coin is this: with better filtering tools, I would agree that nothing should ever be deleted. As it is, when I scan RecentChanges or use FindPage, there is no tools that tell me what the page is about. Three that would be nice for starters are category, length, and contributors. As it is now, I have to go to the page and read it to get that type of information. Thus, I would prefer that the overall number of pages be reduced, and that the pages that remain be shorter and more clear.)

Aren't facilities similar to this already in place? Suppose each page could be tagged with a category, a length, and a contributor - and suppose there was a RecentChanges-style index page to reference them from - then why would you "prefer that the overall number of pages be reduced"? If a subset of the Wiki pages *were* shorter and more clear, and were readily accessible to you through a self-contained (even transitively closed) set of links, I simply don't understand why it seems to bother you that the other material is still preset. -- TomStambaugh

: The "suppose" is my only sticking point. Such facilities are not available. If it is not provided automatically by the Wiki, it is not real, and thus not useful. If category, length, and contributors were listed for each page, both on RecentChanges, and on pages found by doing a Find, then I would be delighted, and would not care how much other stuff was on Wiki. (Those are somewhat arbitrary, but would be nice. There may be other siftable criteria that would be even better.) --

Back to the question of whether HowToWriteAndEditThreadMode would prevent the need for deletion; Not really, for two reasons. First, I wonder why more people don't do it. Are they afraid of offending the community by removing stuff (boiling down), or is it for some other reason? I know that given the current WikiSocialNorms, I do not feel able to "improve" pages by attempting the last suggestion, which is create dialectic. Second, all of the other suggestions (extract, organize, label, extract to other page) address organizing existing text, not removing it. --

But Richard, isn't this the point? A gentle and discreet use of HowToWriteAndEditThreadMode is intended to obviate the need to delete stuff, by providing a different mechanism to supply the same benefits. If you don't wish to view it, nobody forces you to. So why isn't that good enough? -- TomStambaugh

: There are two parts to my response. First, as I have mentioned already, I only care about reducing Wiki because it is not currently siftable enough. Second, assuming it remains unsiftable, HowToWriteAndEditThreadMode is somewhat at odds with your view, in that both its suggestions to ConvertThreadModeToDocumentMode and Create dialectic encourage deletion. I am not sure if the community secretly embraces these suggestions, but in practice they are rarely seen. I wonder if they are not done because they break the taboo against deletion, or for some other reason. (It would be a lot of work to follow them.) --

I'd still prefer deletion of flamebait. We're supposed to be adults here which means it's up to us to say, "That kind of behaviour is unacceptable here." I'm not sure why people are so allergic to that.

I'm not either. People occasionally put up grafitti, obscenities, and flamebait. I see it as their way of asking whether anyone cares about this place. I remove it as promptly as I can as a way of assuring them that someone does. If we were to behave differently, we'd get a lot more junk here - and I'm not talking about redundant points made in a discussion I'm talking junk. -- PhilGoodwin

I enthusiastically agree that it is up to us to say "That kind of behaviour is unacceptable here." I will certainly delete any obvious obscenity, hate speech, and so on. I think "flamebait" is a little more difficult, because pages that are flamebait to some are simply expressions of frustrations to others. Some of us might read some of the material that has been posted here on "SmallTalk" (I intentionally miss-spelled it) and some of the pointed criticism of Microsoft, IBM, and other major companies as "flamebait". So I'm less inclined to delete that. I view all of these as soft, however; I see them as guidelines, not rules. -- TomStambaugh

I would like to offer an alternative mechanism to DeletionInWiki, one that I've found helpful in my code.

Suppose I could somehow say "ForgetPage?" to myself (for example, on my one personal page). This operation would act as something like a spam-filter, so that I wouldn't have to keep wading through pages that are "forgotten", but so that the page is still accessible to everyone else. Another analog is marking a message or news article as "Read".

Presumably, if I trusted a redactor or group of redactors, I could then somehow use their "ForgottenPages?" list as my own. Meanwhile, the original material is still around for anyone who wants it.

-- TomStambaugh

Tom, see my comment on "suppose", above. Most of my argument for reducing Wiki goes away if we are provided better tools to sift Wiki. My preference would be to keep everything on Wiki but make it more siftable. I see that as unlikely, and hence I am arguing (along with the reductionists) to make all that is here more useful and clear. I realize that may never happen as well. It almost certainly won't if the community percieves that deletion is taboo on Wiki. Whatever ends up happening, I find Wiki interesting (even addicting), but think that it would be more useful if it were either more siftable or more to the point. --

Richard, I would encourage you to clone your own Wiki and try some of these ideas in a real community, where you can tailor the engine to do these things and then see what happens. I think we simply have different viewpoints about the kind of Wiki we like. I think that's great - that's one of the things I like about Wiki. -- TomStambaugh

Tom, I am in fact using a Wiki at work, but it has none of these problems, as we use it for a specific purpose. I agree that it is a good thing to have different opinions about Wiki. I really like the C2 wiki, and was just sharing my thoughts on making it more useful. Of course I realize that it is the larger community that shapes the norms on any wiki. It is worth expressing a desire, though, because if enough other people share that desire, the norm may end up changing. If others don't share the desire, there is no harm done by expressing it. I am really not sure what the current norm regarding deletion is, even after reading this page, but I don't see much deletion on this wiki. --

CategoryDelete