Magnus-
- WikiData
- cur/old integration
- stable revision number for both cur/old
- single login
- XML parser
- use of wikicommons
- centralized interwiki link management
- stable/editable version management
and peer review mechanisms.
I've been thinking about the general problem of workflow, fact-markup etc. I'll have some more details soon.
- SVG support (editable SVG source?)
* proper multi-language support within a single DB * completely new way of looking at discussion pages
The fact that we are using a mailing list to discuss this is a sign that our dogfood is not quite good enough to eat yet in the department of discussions. In fact, one Wikipedia WikiProject even created a separate phpBB-type online forum as a replacement for individual aricle talk pages.
Talk pages are confusing and do not offer most of the functionality that we have come to take for granted from other online forums, usenet, mailing lists etc.: - different view modes for a thread - sorting - reply button - quoting - comments are signed for me - watching individual threads for replies - isolated viewing/linking of individual comments/threads - automatic archiving - search by author, subject etc. - group or aggregate related discussions easily - ...
On the other hand, of course talk pages have the full power of wikis - they integrate into RC, they allow wiki syntax, refactoring, diffs etc. So I've been thinking in the last few weeks about a good way to combine the advantages of talk pages and discussion forums into a truly revolutionary new system.
This system, which I have dubbed "LiquidThreads" for now, requires each comment to be stored separately in the database. It will not just *allow* refactoring, it will in fact *require* it - the archiving process depends on old discussions being summarized. It will be possible to attach open wiki pages to a thread which can then be used to create a summary for one or several threads; only if such a summary exists, the thread will be automatically archived after a given time. For easy refactoring into summaries, it will be possible to generate a "flat" wikitext view of a thread.
The system will make it easy to create new "channels" of discussions and to "attach" channels to individual article pages - multiple channels per article, or multiple articles per channel. Discussions can be moved easily so that we can get a decent workflow on general discussion channels like Wikipedia:Village pump.
It will make it possible to immediately see recent comments on a Wikipedia article or a Wikidata entry without going to a separate "talk page", if you want to. You can get a "You have new messages" type notification for *any* reply, no matter where it appears. Discussions of interest to you can be followed on a single page. Yet the system will provide the whole flexibility of the traditional wiki talk system. It will allow setting individual comment permissions so that others can edit your comments. Each comment will have a history, diffs etc. And perhaps functionality for polls can be added, too.
OK, I know, someone has to code it, too ;-). I've created some mock-ups (yeah, I really like mock-ups) and will very soon start writing the specifications for this system, which I believe definitely needs to be taken into account when desigining the new database scheme. I'm fully aware that this will probably only get implemented if I code it myself.
So I hope we don't hurry too much, and at least spend a month or two laying out the requirements for the 2.0 database. Design flaws are always difficult to fix later. I want this design to be *good*, better than anything else out there. I want us to take wiki to the next level.
Regards,
Erik