User:Dcoetzee/Why wikithreads are bad

On Wikipedia, we use the same system to collaboratively edit articles and policies as we do to carry on discussions on talk pages and project pages. We habitually simulate the kind of discussion threads found on newsgroups or message boards, by creating a section at the bottom of the page for each new thread, indenting replies with the colon (:) syntax, and signing each comment with the token ~~~~ to indicate the author and time. If the page becomes too large, either old content is removed (preserved only in the history) or copied to an "archive page" containing the old content. I argue that this ad hoc system, which I refer to as "wikithreads", is inadequate for a number of reasons.

Archiving

Archiving is the most obvious failing of wikithreads. Most obviously, the actual act of archiving wastes time and effort. Some attempt to address this by using bots to perform archiving automatically on a regular basis, but this raises questions such as how often to archive. The changes performing the archiving clog watchlists. The archive pages are usually not on anyone's watchlist, so the discussions in the archive become effectively impossible to continue except by creating a new thread, particularly when archive pages are protected.

Archiving gets worse when we talk about second-order effects. Wikipedia:Village pump used to be a single page, which was split up primarily due to the technical justification that frequent archiving became a hassle and inhibited recent discussion. While the categorisation of this page has benefits, frequently very similar - or identical - threads are posted to different sections at the same time, resulting in fragmented discussion and duplicated effort.

Another problem with archiving is that it causes the page size to fluctuate drastically and repeatedly. This causes download times to fluctuate accordingly, making it impossible to predict or become accustomed to how long the page will take to load. Also, when the page is small, a lot of relatively recent discussion is hidden away in archives.

Additionally, archiving makes linking to individual posts problematic, because although section links to archived threads are permanent and reliable, links to threads on the "active page" are broken by archiving and have to be repaired — typically, the archiver fails to do so.

Finally, many people with broadband connections don't mind larger pages than people on slower connections, but archiving forces a one-size-fits-all policy.

Now imagine we had a software solution that simply showed the most recent k threads all the time, and let you page through older threads, where the threads per page is a user preference which the user chooses based on their connection speed. This very simple system already solves all of the problems discussed above.

Usability issues and indention

How often have you seen a new user post a comment at the top of a talk page instead of the bottom, or forget to sign their comments with ~~~~? A mistake made once indicates a stupid user — a mistake made hundreds of times indicates a stupid interface. We continually waste effort training new users to do this "right". And what if you prefer to read recent comments at the top of the page instead of the bottom? What if you want recently updated threads to appear near the top or bottom of the page, instead of threads being sorted by the time they were created? A more full-featured discussion system could allow this and many other properties of how discussions are displayed to be placed in user preferences.

Also, changes to signatures are not reflected in signatures already written, which means a user's signatures are confusingly inconsistent over time. If someone changes their signature, such as to remove personal information such as their real name, the only alternative is to update all pre-existing signatures — which unless they're an admin, is impossible due to protected archives, and even if they are an admin has led to indiscriminate blocking in the past (ref User:White Cat).

New users — and sometimes more experienced users — also struggle with indenting responses, particularly multi-paragraph responses or responses including lists. We can't indent responses too many times or the result becomes illegible, limiting the depth of threads and necessitating "resetting" of the indention. But after resetting, it's impossible to tell if the new post is a reply to the original or to one of the later posts. It's also not possible to hide or show replies to a particular post in the thread, which is handy in other forums for removing noisy subdiscussions.

Watching: All or nothing

Particularly in general forums such as the Village Pump, but also in ordinary article talk pages, users are often interested in some discussion threads but not others. The watchlist mechanism can only watch the entire page for changes, and is often flooded with noise from other discussions or trolling users in which the watcher has no interest. Comments may end up being missed altogether, damaging the continued life of the thread.

A better solution would allow the user to watch particular threads or subthreads, to hide and ignore posts by particular users, and so on, focusing their attention only where they want to put it.

Editing of comments

Users often edit or delete their own comments. Users sometimes - very infrequently - edit other's comments, to correct minor errors or (controversially) remove personal attacks. Our talk page policy, and strong tradition, discourages editing or deletion of others' comments, and these actions frequently further inflame edit wars. Also discouraged is editing of comments that someone has already replied to, which can make the reply look stupid (for example, if it was pointing out an error later corrected). A better system would allow each post to be individually edited or deleted and software-enforced permissions to be set regarding who can edit or delete a post based on the author.

What about copying to and from articles?

Some say that wikithreads present the advantage that they allow wiki syntax to be copied to and from articles, and so discussion pages should remain in a wiki format. This is a red herring - a more organised system could still allow individual posts to be written in a wiki format and include any portions of articles. Larger-scale page-level formatting such as categories or infoboxes could be linked on separate temporary pages. There's no reason to structure our entire discussion using wiki formatting just because we want to include wiki formatting inside it.

In fact, attempting to discuss the article using wiki formatting on a page constructed using wiki formatting can lead to ambiguities; for example, when attempting to copy sections to or from an article, it's necessary to modify their level because sections are already used to divide up threads.

LiquidThreads

So far, the best solution proposed and implemented for this problem is LiquidThreads, a MediaWiki extension that allows paging through heads, allows watching of individual threads, allows linking to individual threads which get automatic subpages, and has many other useful features. The deployment of this extension on major WMF projects will be a difficult but valuable step forward in improving the quality of our discussions. There is a live beta at a test wiki.