Extension:LiquidThreads

First draft.

LiquidThreads is a proposed discussion system for MediaWiki 2.0. It is currently an underway project for Google's Summer of Code 2006. You can view the developmental process in the SVN repository, but actually using the code is strongly recommended against.

Rationale
Wiki discussion pages have some advantages over web and Usenet forums. They allow use of the entire wiki syntax - from images to wiki links to transclusion. It is possible to refactor entire discussion pages. This, however, happens relatively rarely as the software does not promote it specifically.

Web forums offer a number of advantages over the MediaWiki talk page model:
 * Threads can be displayed in different views: flat, nested, sorted by date, subject, etc.
 * The user only needs to click a "Reply" button or link in order to respond to a comment. Manual indentation is not required. Quotations from the source comment can be inserted automatically.
 * Comments are automatically signed and dated, avatars are possible.
 * The user can watch individual threads or be notified about responses in threads.
 * Comments and threads can be displayed individually, without the surrounding page.
 * Old comments are archived automatically and invisibly, with permanent links easily available.
 * Search for author, subject, date, etc. is possible
 * It is relatively easy to manage related discussions in a subject-specific forum, whereas MediaWiki talk pages always follow the "one discussion page per content page" model.

LiquidThreads aims to unite the advantages of both forum types, and to add some unique discussion features to boot.

Core model
The LiquidThreads core model consists of four components:
 * Channels. Every article can have one or multiple subject-specific channels in which issues can be discussed. A channel can also be attached to multiple articles to which it is relevant.
 * Threads. A thread is a collection of comments about a specific subject. It can be attached to multiple channels at the same time, moved, renamed, deleted and combined with other threads.
 * Comments. The author of a comment can determine if other users may edit it. (disputed, see Talk:LiquidThreads) Each comment has its own version history. A comment can only belong to a single thread, but it can be moved within the thread, to another thread, or even to another channel. Each comment has its own entry in the database, and its own version history. This allows for the display/reply features mentioned above.
 * Summaries. Each thread and each channel has its own associated summary page. When editing such a summary page, a user can request the whole wikitext of a discussion to be inserted for easy refactoring.

Schrödinger's thread
When a thread is moved, it can exist for a limited time in two positions so that users can follow the discussion more easily.

Editing comments
LiquidThreads accounts for the fact that not every user wants to have their comments edited by others. It allows users to determine in the preferences whether this should be permitted and if so, under which conditions (only spelling corrections, removal of personal attacks, improvement of arguments etc.). These edit conditions could be shown as icons below each comment.

Smart archiving
Threads are archived after a defined number of days, but only if a summary exists for the thread. This way, channel and thread summaries are to be encouraged.

Addressing
Comments, threads and channels must have unique link addresses. For threads and channels the human-readable title can be used, e.g. Talk:Article name/Channel name/Thread name. For comments, a unique ID number could be assigned.

Gateways
In the long term, LiquidThreads could offer interfaces for external access - by e-mail, using a newsreader, or even using real-time chat like IRC. Even the web interface could allow real-time chat: Using a link "Change to real-time mode", users could open a chat room for a specific thread and invite others to join.

Typically, real-time comments are rather short, and it is not as clear as in a forum who has written what. It may therefore be desirable to collect real-time chat protocols in a single, openly editable comment so that other users can edit and summarize them.