. This is my story.
The day after the announcement, I was pretty much dead to the world. The stress and lack of sleep and excitement prevented me from getting anything done. My family was kind enough to take me out to dinner, though.
The new student mailing list already has over 500 messages in 45 threads, most of it drivel (which, I confess, I helped to instigate).
I'm trying to balance SoC and school (which ends June 15th), so no code yet. Hopefully I'll have something neat for you to look at by Monday. At present I'm working out the database schema and figuring out the best way to integrate the code -- MediaWiki's API is, shall we say, multifaceted.
Suggestions on the URL scheme would be most welcome.
LIQUID THREADS: Improving the Talk Page in MediaWiki.
davemccabe you-know-what gmail.com
(my phone number)
Improve MediaWiki talk pages by decoupling them from articles; by making the comment a distinct database entity; and by providing a user interface that makes it easy to write, edit, rearrange, and archive comments, and that makes it impossible to get the formatting wrong for threading. Make the transition to the new system as easy as possible for users and site administrators.
The current talk page system, while simple, has some major usability problems. First, people often forget to indent their comments correctly, to sign them, and to add headings for new threads. Second, it is difficult to tell what order comments were posted in, or whether a comment has been edited by someone other than its author. Third, old, inactive threads must be manually cleaned up, and then they must be dug up out of the history if anyone wants them again.
Liquid Threads will solve all of these problems, while retaining Wiki sensibilities. Here's how:
DESCRIPTION OF THE SYSTEM
This project is based on the ideas described here:
A Liquid Threads talk page is called a *channel*. Each article can have any number of channels attached to it, and each channel can be attached to any number of articles. This way, discussion from all over the wiki can be easily accessed from the articles that it is relevant to.
Instead of free-form wikitext, channels are populated with *comments*. Each comment is shown with a 'reply' link. Comments are automatically signed. They can be moved around within a thread, within a channel, or between channels. When a comment is moved, its replies move with it. If a thread is moved to another channel, a notice remains pointing to its new location. When someone other than the original author has edited a comment, it is clearly marked, to avoid vandalism.
Instead of watching an entire channel, users can choose to watch only replies and edits to specific threads, or to automatically watch everything that they write. Comments have individual histories, so it is easy to see the edits that have been made to a specific comment, without wading through the history of the entire channel. Threads can be folded up hierarchically.
After a thread has been inactive for a certain time, users may write a summary for it. Once a summary is written, the thread is archived.
The proposed system would make MediaWiki more complex. While one of the best parts of wiki is its simplicity and transparency, sometimes a little more complexity results in a lot less headache. After all, Wikipedia doesn't use UserModWiki, and I am not typing this proposal into ed(1). The added complexity of Liquid Threads lowers the barrier to wiki collaboration. For while a new user cannot use talk pages correctly without first reading the documentation, basic usage of Liquid Threads is readily discoverable.
Some have proposed that we improve talk pages by adding 'Reply' links while keeping the flat wikitext implementation. This may seem more conceptually compact than Liquid Threads. Quite the opposite: Hacking an understanding of thread structure into the wikitext parser would be far messier than keeping comments separate in the database. It would be easy for users to accidentally confuse the system while editing talk pages. This idea falls into the same trap of manualarity, ad-hocery, and exposure of implementation that plagues the current system.
I have written a prototype which demonstrates just a few of the features of Liquid Threads. You can see it running here:
And the source code is here:
* An implementation of Liquid Threads in MediaWiki, ready for deployment, featuring channels; nested, foldable threads; comments that can be edited and rearranged with individual histories; watches; summaries; and archiving.
* Internal documentation on par with the existing MediaWiki code.
* An implementation that is as separate and non-invasive as is practical, probably as an extension.
* The ability for site administrators to choose between conventional talk pages and Liquid Threads, and to switch easily from one to the other.
* A usage guide similar to those that exist for current MediaWiki features.
* A test wiki.
* A development blog or summary, if desired.
* Publicity for the project.
I am in school until June 15th, so progress for the first three weeks will be slower, although by no means trifling. After the 15th, I will have no other obligations, and will be able to work on MediaWiki full-time.
Here's my plan:
* Set up a test wiki.
* Work with my mentor to figure out the best database schema to minimize database queries. Devise caching mechanisms and the semantics of thread and channel history.
* If anyone does the 'IM presence', 'Offline reader', or 'Traffic optimization' projects, contact them to make sure that these can be integrated with Liquid Threads in the future. Also make sure that Liquid Threads will work with the Client API that is under development.
* Add the new tables to the database, and write classes for accessing them. Write a page that displays the new tables for debugging, and that shows up as a tab in the MediaWiki user interface.
* Implement the functions currently present in the prototype. June 18.
* Add the remaining features, such as rearranging threads, adding and removing channels, archival, diffs, and composite history. June 30.
* Test the system under heavy loads and optimize as needed. Also correct any design decisions that turn out to be mistakes. July 15.
* Find users to test the system. Use their feedback to fix bugs and improve the user interface. Write documentation and publicity material for site admins. Prepare for release. August 5.
* If time allows, I will work with a site administrator to deploy Liquid Threads on at least one live wiki.
I am eighteen years old and a second-year student at Clark College in Vancouver, WA. I have been a self-taught programmer for many years, and have contributed to open-source software, especially with the GNOME project, starting about two years ago. I worked for six months at CGI Pro Inc., where my job was to integrate new features into existing applications whose authors were no longer available. Most of the projects used PHP and SQL, and I often worked from home using AIM, SSH, and a VCS. This experience is highly applicable to the Liquid Threads project. I left the company last year to be a full-time student.
I am a long-time Wikipedia zealot, and talk pages have always seemed awkward to me. Therefore, I am eager to improve Wikipedia and other wikis with this new system. Although it never occurred to me before to hack MediaWiki, I'm already looking forward to getting started. This project may turn out to be the first of many.