This feature has been added to 1.6: https://lists.webarch.co.uk/pipermail/mkdoc-commit/2005-August/000955.html It needs to be ported to 1.8
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.
Adding a comment via the comment form should not change the last-modified date or the last-modified user
MKDoc::Text::Structured modifications
Any URLs that are automatically hyperlinked should implement the <a rel="nofollow"> spec:
http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html
URLs and long words that are longer than a certain length should be split visually as per google results.
Similarly <pre> text longer than a certain length should be detected and dealt with appropriately.