The Desire To Delete

Ignoring the problem of spammers (most of whom are drive-by attacks, rather than persistent pests), most if not all of the problems found on Wiki recently can be traced to TheDesireToDelete material that one party finds objectionable or unwarranted (but another considers essential). Neither is willing to yield or obey DeleteOnceRestoreOnce, and EditWars ensue (and escalate).

For example:

Fluff pages like BoogerClub
Content that is considered (by someone) to be Noise or NoContent? (Or is it this category, that is meant by 'fluff'?) An example seems to be DeleteAngel.
Content that is considered (by someone) to be OffTopic
Content that is considered (by someone) to be ill-informed
Content that is considered (by someone) to be offensive or inflammatory
Content that is considered (by someone) to be un-wiki
Content that is deleted for spite or just for purposes of causing damage.
Spam.

In some cases (such as spam or vandalism), the "correct" resolution is generally agreed upon by WikiZens; these don't cause the current problem.

Part of the problem may stem from the tradition of the WikiReductionists (not blaming them per se) that in order to improve Wiki, stuff (ostensibly chaff and other noise) must continually be pruned; so all that remains is signal. Which is good when we all agree what is noise and what is signal. But when there is widespread disagreement as to what constitutes noise and what constitutes signal, what to do? DeleteOnceRestoreOnce was a good idea, but only so long as people are willing to honor it.

It takes two to tango, though. The desire to delete interacts with the desire to restore. DeleteOnceRestoreOnce needs to be coupled with RestoreThoughtfully?: When you restore a deletion, what can you do to address the issues implied by the deletion? In other words, resist the temptation simply to restore to the status quo ante. To aid this, the deleter should indicate as clearly and succinctly as possible what a would-be restorer might do to address the concerns.

It could be argued, however, that deletion is a more severe action than restoration. It is far easier to ignore a page which is present, than it is to read a page which is absent. When a page is restored, nobody is forced to read it if they don't like it. But when a page is deleted, everyone is prevented from reading it even if they do like it.

The two actions are not symmetrical. Perhaps DeleteOnceRestoreOnce should be replaced with DeleteOnceRestoreThrice? - indicating a supermajority ought be the appropriate threshold for axing a page.

It depends on how focused you want the Wiki to be. Think of the set of everyone's interests as a big Venn diagram. If anyone can delete anything and nobody can restore, then the content of the Wiki is the intersection of all those sets, which is normally miniscule. Under DeleteOnceRestoreOnce, the content of the Wiki is the union of all subsets that are shared by 50% of members, which is probably enough to keep Wiki focused on programming. Under DeleteOnceRestoreThrice?, the content is the union of all subsets that are shared by 25% of members, which is basically everything except a few fringe beliefs. Under edit-scripts, the content is that of DeleteOnceRestoreOnce unioned with the views of those members who're willing to build a script.

Also, the utility of having an extra page is far from a linear increase. It's really more akin the user-interface design. Each additional page (feature) by itself adds value. Together, they're unusable beyond a certain threshold. You get a sort of BoiledFrogs effect, where you never even realize that the temperature is rising until everyone has left. -- JonathanTang

Why? Because people rely on AllPages as their entry point to Wiki? What you're saying doesn't make any sense. No, more than that, it's ludicrous. -- AnonymousDonor

People often rely on either Google, FrontPage, or RecentChanges as their entry to Wiki. In the Google case, extra pages cost nothing because they're never seen by the person. FrontPage makes a tough entry point anyway, because it's several clickthroughs before the user gets to anything of interest (conventional web design wisdom states that all content should be accessible within 2 clicks; Wiki takes well more than that). RecentChanges is the return point for most repeat visitors, and its utility drops dramatically with the number of pages. People have to wade through 90% junk to find 10% worthwhile stuff. FilteredRecentChanges would help with this, but there are other issues with that. -- JonathanTang

What is known, is that as the information content of a system (whether it be a Wiki or anything else) increases, generally by orders of magnitude, the way that information is organized and cataloged needs to change to be useful. In short, the UserInterface presented by Wiki probably doesn't scale. Currently, the number of pages on Wiki is in the 25k-30k range; Wiki could probably tolerate some number above that. Could Wiki support a million pages in the current paradigm? Probably not. 100k? Probably, though it would get ugly. 100 million? No way in hell. (Fortunately, in a forum where humans author the pages, 100 million pages is probably not reachable. Were pages to be created automatically, that's another story).

There are three possible solutions to this scalability problem proposed by such growth:

Do nothing; usability of Wiki suffers as a result.
Change the interface to Wiki. Some changes have been suggested in CrazyThingsThatMightSaveWiki and elsewhere (such as FilteredRecentChanges) to something that scales higher. Invariably, scaling above a certain threshold (I don't know what it is) will require some more formal categorization and/or better search capability.
Continually prune pages to keep the total page count within reason, to avoid having to change the interface. This is the raison d'etre for WikiReductionism?; the fundamental justification for TheDesireToDelete in many cases - the fear that too many pages (OffTopic or otherwise) will cause Wiki to become unusable; and that changing Wiki to scale up will make Wiki no longer Wiki. Of course, the fly in this last ointment is how to select pages for deletion; controversies over this matter are the leading cause of EditWars.

There is a slow delete mechanism called IsThisPageOk? that deal with slow delete of OnTopic pages. Can be used in conjunction with DeletedUnlessDefended.

There may be better ways but none has come out as yet. -- dl

DeletedButKeptHistory? ?

I would be less resistant to DeleteAngels if after a delete, another person can go retrieve the history, in manners similar to accessing contents of a page that only exist on sister sites.

That way, all searches will still exclude the deleted page. And people who disagree with the delete has a chance to offsite the information to another wiki, desktop, etc.

Strawman from DavidLiu -- PleaseComment

I'd rather have a good versioning history too, both because then I'd feel much less afraid of pruning pages and because it'll make refactoring easier (and more rewarding) if you can see previous versions of the pages. But it's WardsWiki; we aren't going to get one until he (or someone else) implements it. -- JonathanTang

For what it's worth, I actually prefer the lack of versioning we have here. Somehow it feels more in the WikiNow to not easily look back at previous versions. -- RonJandrasi

CategoryWikiProgress