WikiEducator, a wiki-based education community with a strong focus on developing countries, is the first production wiki to use LiquidThreads, a MediaWiki extension for threaded discussions. The project has a long and interesting history: three years ago, I reached the conclusion that regular wiki discussion pages were inadequate as a communication tool for many reasons, and wrote very basic specifications and created a mock-up for an alternative discussion system called LiquidThreads.
The core idea was to replace talk pages with discussion threads, which could be flexibly attached and re-attached to multiple different points in the wiki (hence the “liquidity”). Archiving was to be done automatically, but only if a summary had been created for a thread.
As these things go, it was merely an idea that would probably have been destined to be abandoned — until David McCabe picked it up and used it as a basis for a Summer of Code application in 2006. He demonstrated a fairly slick prototype at Wikimania 2006 (Hacking Days), but the project was on hold until Wikia and the Commonwealth of Learning joined forces to pay David for further work on it. I have played a project management role during this time. By now, LQT is still beta software, but it’s largely feature-complete.
It has turned out to be less liquid than we originally intended. It does not have the “one thread on multiple talk pages” feature, for one thing. It does implement the summary-based archiving, as well as page moves and a fairly cool message watchlist that replaces the “You have new messages”. Essentially you can get notified about any reply to threads you’ve been posting on — curently the notifications are shown on the watchlist, but David is working also showing a general notification for user talk messages.
There’ll be more debugging and usability work as we try this out with a real community, and the other major remaining step is to turn it into a proper MediaWiki extension (because it touches so many pieces of the code, it wasn’t possible to implement without touching the core codebase — we’ll have to get those hooks merged back into MW proper and get rid of anything idiosyncratic). After that, my hope is that it’ll be increasingly widely used as an alternative to talk pages, hopefully also on Wikimedia projects. With a basic framework like this in place, it’s now more realistic to think about things like in-wiki chat and e-mail-to-wiki gateways as well. All it really needs is a budget. 
If you’re interested in funding such projects, let me know.
October 2, 2007 at 10:53 am
Sweeeeeet!
October 2, 2007 at 11:10 am
Well done Erik, David and Wayne!
The LiquidThreads feels very good already. Some simple graphical element between the posts would make the threads easier to read. I was also thinking how the “editing” the posts works in a discussion, but I am sure you have thought about this, too.
In the next step of development we could think about having “knowledge types” in the LiquidThreads. I wrote about this some time a go in here:
http://flosse.dicole.org/flosse/?item=mediawiki-feature-requests
Anyway, I think LiquidThreads is a major step for MediaWiki to the direction of becoming an educational platform.
October 3, 2007 at 1:44 am
Thanks Teemu – so would thread icons with associated editable “types” be roughly what you want?
I do want to Keep It Simple and Stupid, so we’d assign a default type if none is selected – but some existing forums also have this kind of thread classification, and it generally seems to be useful.
October 4, 2007 at 3:32 am
LiquidThreads has always been great concept and fell in love with the idea when I first saw it.
Thanks to your vision and tenacity to push the envelope combined with David’s coding skills we now have a functioning technology that will lower the thresholds for educators to form discursive communities in MW.
The Wikia/COL collaboration is also a great example of how free software does push innovation in sustainable ways.
BIG thanks to Erik & David. I trust that many MW installations will benefit from LQT.
October 5, 2007 at 7:50 pm
Erik,
In Fle3 each “Knowledge Type set” has (1) title, (2) description, and (3) 1-10 knowledge types. Each “Knowledge Type” has (1) name, (2) abbreviation, (3) colour, (4) icon, (5) description, (6) help text, and (7) starting sentences. Sets may also have “rules” so that some of the type(s) must be followed with some other type(s).
Here is an example of one Knowledge Type set:
Title: Progressive Inquiry
Description: Learning can be seen as a research practice aiming to solve a group’s understanding of a subject by creating a visible discussion of research challenges, theories, scientific facts and summaries. The process aims to be progressive in its approach by starting from initial problems and ideas of the students and then becoming progressively more challenging through creation of more elaborate problems, theories and research practices. The Progressive Inquiry knowledge types aim to scaffold a learning community to follow the process of setting up research problems, making current knowledge visible and working from there to deepen the understanding on the issue by creating discussion notes. The reading and writing of these notes is seen as the key momentum of the process, helping learners to structure their ideas based on the principle of scientific research.
Knowledge types: (1) Problem, (2) My Explanation, (3) Scientific Explanation, (4) Evaluation of the Process, (5) Summary.
From here you can have a look what the knowledge types of this set contains:
http://fledev.uiah.fi/svn/FLE/tags/Fle3_1_5_0-1/FLE/types/pitt.py
The idea is not only to categorize the discussion notes, but also to “guide” novice students to have progressive discourse. We call it scaffolding.
To keep it (at least a bit more) simple for the LiquidThreads we could, at first, use Fle3 as the knowledge type set editor (it is already implemented) and make LiquidThreads to work with the knowledge type sets originally made for and in the Fle3.