An Authoritative Author?

Now my wiki-for-work is my first wiki, and is less than a month old, so I'm shooting from the hip, here. That said: I think that a wiki intended as a source of information, even one which is a collaboration between true peers, needs an organizational vision. An authoritative author or authors, or more delicately, an Editor. A wiki intended as a forum is a different thing, and might be more free-form to allow for emergent structure. This seems to be a philosophical schism in wiki authorship; the strength of a wiki is in the ability of every member of the community to contribute, be it with questions, answers, theories, evidence, or signs of cluelessness. All of these are helpful because the wiki can then accurately represent the structure of thought in the community.

But it can also then get pulled into the confusion or the discord in the community. If the goal of the wiki is to represent the 'state of the art' for a community, the emergent structure is important to see even when the structure is 'conflict'. But when the goal of the wiki is documentation, to help bootstrap most of the readership to greater knowledge, then that discord will more likely lead to frustration and abandonment before it will lead to epiphanies about the challenges the community faces. It seems that a greater authority, even in the form of an active moderator (rather than author) may help by setting down the spirit of the community, by providing a vision that the 'cats' are more than happy to be herded by. Regarding wikis aimed at documentation or user support, I side with the authoritarians with the caveat that a good wiki will have areas where open discussion, questioning, and tinkering is clearly welcome.

For instance, the Tinderbox Wiki evidences (as of this writing) that people don't know where to find or place things. Has their comment been replied to? Is the question already answered over in the [FAQ]? Or is that the [Frequently Asked Questions]? These are dummy examples, but the point is: without a clear framework for us to build upon, all the good will in the world is going to be hidden within a tangle of different conceptions of how documentation should work.

And this is done with the best of will. What we could have is a body of documentation which is criss-crossed by trails established by as many indices as we have perspectives on the material. Once the material is there... want an index (linking edit-discouraged pages) for YourFirstDayWithTinderbox complete with narrative context? Sure. How about ProducingPHPFromTemplates? Sure. But without a clear sense of what is an answer area and what is a question area, where discussion should happen and where plain description is, those indices are likely to start bearing content... which someone else won't know is in ProducingPHPfromTemplates and not HowToMakeTemplates or ExportTemplates.

We're already running into this issue in our work-wiki because we're refactoring an old html-based documentation site into the wiki. We have it easier than Tinderbox (or Wikipedia, etc.) for a few reasons, though. Ours is a documentation wiki, and the work we're documenting has a clear structure-- several constituencies with discrete functions and tasks. Several namespaces are clear and useful: summerNetworks and summerSetup vs. yearNetworks and yearSetup. There are grey areas when something applies to several constituencies, but those are by far the exception, and when they pop up I as head of the department can determine policy. We'll have discussion, but most of it will happen offline, so the wiki doesn't need to deal with it.

The answer, as usual, probably doesn't lie in either the extreme of control (restricted edit privileges to the site or hard-line 'fixing' of edits) or of freedom (unmoderation). From my lack of experience as a wiki moderator I wonder whether there isn't a happy medium in clearly defining portions of sites or pages where edits and discussions are encouraged and portions where edits by anyone but the 'editors' are allowed but socially discouraged.

The software I've played with attempts to solve this with software. One package made the easiest way to edit be a 'comment', which was just a wiki editing window that deposited the typed text onto the bottom of the page in a write-only fashion; edits to existing text were still possible but required clicking through the editing process. Dokuwiki doesn't do that, but the top of the edit page asks: "Please edit the page only if you can improve it." I like that sort of social solution.