A quick braindump so I can get back to work.

I’ve been playing with wikis a little over the last year or so: first, I have a wiki here. What happened here is that I wanted to password-protect parts of the wiki and then forgot the passwords. It would be much better to have a wiki with pukka logins. In fact what would be best would be a wiki engine with user-authentication hooks - that way I would be able to write the shims that mean you can log in to the wordpress engine and you’re automatically signed in to the wiki too.

I also have a wiki at work. I use this to jot down notes about process and problems with tools. We have a formal document management system with our quality procedures in but really it amounts to a change obstruction system - the software is so focussed on preventing unauthorised changes to the process documentation that it’s too expensive to make small changes - like file X no longer goes in folder Y but folder Z instead - so the documents end up little use to the grunt on the ground who is meant to follow the procedure. My wiki is searchable and thus great for the grass-roots guys. What it doesn’t do is have a formal control mechanism whereby certain revisions of the document can be marked as official releases. Nor does it afford printing out in a professional-looking document, not even a semi-professional looking document like Word can manage.

Thirdly, I use the Unreal Wiki, which is interesting as an example of a large over-authored and under-edited wiki. The problems with the unreal wiki are that authors drift off topic and take pages with them, information is replicated, different opinions of what the wiki is FOR shape the wiki, and lack of confidence to change the text mean that lots of accurate information is stored as comments to inaccurate pages rather than the pages being simply correct.

For a wiki to work in a corporate environment, I think you would need to have a nominated owner of every page. Also all changes would need to be under an authenticated name. This is not too hard to achieve under an intranet environment since your IT people should know who every principal on the network is, and are able to enforce the presence of certain software or configuration options.

The page owner would be able to nominate a page editor, by default the owner, who would get email whenever changes were made to the page. It is up to the editor to keep the page coherent and on topic.

The other tricky part about a wiki in the workplace is that some information is sensitive and shouldn’t be shown to external eyes, or even to certain colleagues within the same organisation. Keeping the information purely technical and stating that the entire wiki is company-confidential may address this.

Wiki markup languages are immature and thus of variable quality and all have their own quirks. This is a tricky tradeoff because consistency usually comes at the price of terseness, whereas terseness contributes strongly to the convenience of contributing to a wiki. A light but regular structure-based input language with subject-domain extensibility is ideal. By subject-domain extensibility I mean there may be certain styles that are applicable in certain contexts, e.g. all user manuals should have a NOTE: style associated with them that causes the particular style and branding to be output in the printed edition.

As an online resource, Wikis tend to have a manually-maintained contents (forward index) and are searchable. For printed documents, an index is extremely helpful. How could this be implemented?

There should be the notion of documents that are drawn together out of the wiki. This would provide the ability to gather a group of wiki pages together in a structure, branching the pages at that version and allowing tweaks that will only apply to this document. There are always final touches that are needed to produce a coherent document and it should be possible to make these without negatively impacting the living text that people are updating day-to-day.

Finally, there should be hooks for auto-generated text. Teams should be able to easily lash-up their data to automatically update the wiki. Perhaps the commands to retrieve and insert this information would simply form part of the wiki text so is fixable by all (recall that all changes are seen by the page’s editor and the author identified for the purposes of audit)