Wiki Patterns

Patterns for successful wiki use

User Tools

Site Tools


onehammer

OneHammer

Classification
TypeAnti-Pattern
FocusAdoption

Your organization's wiki is used for all matters of collaboration, including especially: issue tracking, project management, appointment scheduling, data archival, form-filling, code revision control, electronic laboratory notebook, meeting presentations, virtual science fair… At first this might seem like a pro-pattern, showing broad acceptance and usage of the wiki technology and philosophy, but in the long term it deprecates quality of contributions or the perceived value of the main body of your knowledge base.

Example (Symptoms)

  • requests for One wiki space per group to isolate groups page names from other groups, rather than contribute to the shared knowledge network
  • people complain your pages have an 'industrial' or 'database' feel
  • you get what seem at first like unreasonable feature requests:
    • 'I need to be able to set recurring meetings on my delegates calendar' on a calendar page
    • 'How do I extract the number of hours my programmers have spent documenting their code'
    • 'We need to be able to browse and edit these pages while not connected to the internet'
    • 'People keep changing the contents of my page 'meeting minutes' to minutes from their meetings'
    • 'How can I restrict the options for the 'department' section of every page about a 'product' to just the controlled vocabulary choices in this external database'
  • you have too many hierarchical page names (not child links, very long page names with prefixes)
  • you have too many page names that have dates in them
  • you have a page named marked 'draft' for every page and this draft needs to be approved before it's copied to the 'official' version

Solution

  • wikis work well as a gap solution for certain types of structured information–information that is perhaps better supported by applications designed to follow a specific process or information workflow. Pehaps a wiki will work well in these cases with a particularly open culture or a particularly small organization, and if so there is no issue. However, if you run into problems, consider graduating some of these well-established systems to proper frameworks and your apparent 'conflicts' and 'unreasonable feature requests' may disappear. (If possible, make sure to integrate these new systems back into your wiki, using trackback links or at least static permanent link URLs)
onehammer.txt · Last modified: 2018/11/28 16:07 by splitbrain