Comment component

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.