The 1.6 and 1.8 experimental discussion components should be abandoned and instead a Comment Component should be implemented
We currently have a discussion board in MKDoc-1.6 that uses an IMAP backend to store the data. This has been removed in MKDoc-1.8 for various reasons, mainly because it doesn't get much usage – Before we recreate it, we should figure-out why.
The existing design comes from our experience of various internet discussion forums; basically, we make a lot of use of usenet, mailing-lists and irc.
We hardly ever use web-boards because they are so inefficient as a means of discussion. So the MKDoc discussion board was designed as if it was a threaded newsgroup, with all the features of a decent mail/news client.
A Building Communities with software article by Joel Spolsky has some interesting ideas.
I propose that we accept what we always knew: that the web is a terrible medium for discussion, but a good medium for comment.
A replacement for the discussion board might look like this:
We do away with the Discussion component and its IMAP backend and create a new Comment component.
The Comment component inherits from the Text component, but it has two extra pieces of metadata: Author and Date.
Any authenticated user can add a Comment component to the bottom of any document, however not all document templates will display Comment components – Editors will have to select ‘Blog’ or ‘Comment’ templates to make them visible.
(Allowing comments on any document will allow a future bonus feature where users can create a comment that only Editors can see)
The interface for non-editor users will be a simple ‘Add a comment’ text box at the bottom of the page, with a single ‘Submit’ button and no ‘preview’ functionality – There will be no automatic quoting of previous text.
Editors can add, move, edit or delete Comment components just like any other component – Editors should be encouraged to prune duplicated and off-topic bloat from pages.
New comments are always added at the bottom of a page, so the page reads in rough cronological order – There should be no threading.
That's it, this ought to be pretty easy to implement.