Wiki Patterns

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== OneHammer ======

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)

===== Related Patterns =====

  * [[All wiki all the time]] - **OneHammer** can easily lead to this anti-pattern.
  * [[One wiki space per group]] - a pro-pattern for dealing with the above conflicts using 'wikis' instead of specialized applications