KNotations

Yesterday I posted about planning a 'release version' of knotes. I'm going to try to post at least once every day on this subject - heaven knows there is enough to write about! We use the FirstClass groupware system for our intranet. I send hundreds of messages a week to firstclass 'conferences' we've set up for documentation. I'm going to try to post some of those here instead.

As an aside, though, let me re-state the bleeding obvious: if you want to install KNotes in its current version, please do. We employ KNotes in as lot of sites now, and could not imagine living without it. But if you can wait a while, you might find life a bit easier. In either case, if you are thinking of trying KNotes at some point, please let us know.

We have to make some decisions about what exactly makes an issue a pre-release one. We already know of a lot of issues, minor bugs and feature requests, and we already have extensive plans for improving and extending KNotes. Most of those issues, bugs, features and improvements should be made post-release, but some of them would be much better completed before too many other sites were deploying KNotes in anger. I think these can be roughly categorised as follows:

Extended text for this entry:

Issues complicating installation [must-do]

...for instance, the main-template X fast_folders issue: before expecting site managers to install KNotes, we must complete, test, and merge-in the safer skins-path technique for getting plone forms and content into iframes without its navigation wrapping.

Planned changes with backwards-compatibility issue [must-do]s

...for instance, any changes to the data model of the kndiscussion SQL table reguire an object migration on existing installations. Also, the current CSS/JS file names are whacky because we make continuous changes in a very severe cache-control environment. We have to make some changes to the templates to make them ready for localisation as well.

Sources of frequent bugs [must-do]

...for instance, the editing of weblog objects (title, about etc) has often generated bugs (at the moment it causes a cloning of all categories). We must thoroughly analyse and repair this source of bugdom

Major speed-ups [must-do]

During development of features, there is a natural drift towards poor performance (for instance, tickling Zope objects unnecessarily, or adding expensive branched TAL steps inside iterations). Then there is a phase of re-engineering a 'rational reconstruction' which delivers the improved features in an efficient way (followed by another cycle of feature-bloating :o) It would be much better to draw a line under a 'release' version when the product is optimised for its current features. (At the moment, KNotes is pretty darned slow compared to it original performance).

Serious usability issues [must-do]

...for instance we're aware of serious usability problems with the discussion of weblog entries; these must be corrected in a coherent way before we encourage site managers to install KNotes for their own end users

Very common feature requests [should-do]

...for instance anonymous comments are almost a requirement, but our current solution is not good enough to release ( vulnerable to comment-spam, not easy to use...); end-user skinning is another example

End-user documentation [should-do]

We still have a lot of documentation to write for end-users. We may try to get the community involved in this

Localisations [should-do]

It would be good to have started work on one localisation before release, in order to shake out any issues that would cause backwards-compatibility problems later

Pride issues [should-NOT-do]

There are many small issues I would like to take care of before the world notices KNotes -- the stylesheets need work for instance. It'll take some discipline to let the product out without addressing those issues, but we should do exactly that 8-)