====== One Wiki space per Group ======

In a large organisation, different teams want to share knowledge and collaborate on different topics. Some teams are more open to sharing and collaboration than others. A natural approach might be to give each project or group a distinct wiki.

===== Advantages (as an Adoption Pattern) =====

  * Easier page naming in the context of your knowledge area and fewer problems with naming clashes
  * Space to focus on a particular topic without distraction of other teams editing
  * Team-based permissions e.g. "other teams can view and comment but not edit" or "other teams can only view" or "other teams cannot view at all"
  * Keeping projects separate just //feels// like a sensible approach

Page naming is a tricky problem in large cross-organisation wikis. If one Wiki is used for all projects, page naming conflicts might occur. For example, two projects meet on the same day and want to create meeting minutes with the same title. The problem can be tackled by putting together (collaboratively) a set of page naming conventions, and by enforcing these with regular wiki gardening. With separate spaces, you save a lot of this the hassle. Page names only need to make sense within smaller focussed project teams.

===== Disadvantages (as an Adoption Anti-Pattern) =====

As mentioned above, this pattern //feels// like a sensible approach to aid organisation of the wiki, and so it is natural that people would go for a separation of wiki spaces. But is it a mistake? There are a couple of pretty big disadvantages, which lead some people to conclude that this in fact an anti-pattern!

  * Same concept duplicated as a page within two different spaces discourages mind-share.
  * With community collaboration, bigger is often better.
  * Separate recent changes discourages wiki gardening.
  * May lead to restricted access, which then prevents cross-polination
  * Fewer 'collisions', thus fewer opportunities to collaborate and innovate outside your regular box

If a concept has a wiki page in one place and one place only (with any attempted duplicates getting redirected) then the whole organisation is forced onto one page to discuss that concept. For example, is it better, and more efficient, if your organization has a single page called "Organisational Chart" for the entire organization, or if each team has their own page with that name, and with it, their own interpretation? Perhaps one team proposes developing ABC, while another team already has begun development or has documentation showing difficulties they've encountered. If the two different mindsets clash on the 'ABC' page, and they are forced to describe things in a neutral point of view, presenting arguments for and against. People may get upset (including high-level managers) but the resulting mindshare can be wonderful. The alternative is the two groups go on thinking their own separate ways until the project is much farther along, further accentuating the rifts in your organization.

The 'recent changes' page is a focal point for the 'wiki community'. It helps to create a buzz and reinforces the idea that everything is editable and anyone can join in. But this only happens if there are lots of edits happening. People will either feed off each other's editing enthusiasm, or perceive a lonely and desolate collaboration space, depending on how busy your recent changes page looks. If people are asked to look at recent changes only within a small team collaboration space, a potential community spirit is quashed.

Wiki gardeners tend to be more wiki-savvy than most, so hopefully they will find the centralised recent changes (if you provide one). However wiki gardeners may only become wiki gardeners by slowly developing a 'recent changes' addiction.

===== Implementation of separate wiki spaces: Separate wiki installations or a Separate spaces on a single installation =====

A simplistic way of achieving this is to install entirely separate wikis for different groups/teams.

  * This might occur naturally/accidentally anyway.
  * Teams can select their preferred software independently, which might be a freedom some people enjoy.

However, many wiki software incorporate a concept of spaces such that a single software installation powers multiple wiki spaces (terms vary e.g. 'workspace', 'namespace', 'twiki webs'. This approach:

  * gives people the ease of accessing all spaces from one site with a single login
  * facilitates cross-linking and moving content between spaces, and
  * centralises the administration overheads, e.g. upgrade, migration, backup responsibilities, etc.
  * users may have the option of viewing a centralised 'recent changes' display (see wiki edits occurring across the whole organisation).

The advantages above, garnered by hosting the //individual team spaces// on a //single installtion// , help alleviate the disadvantages of the wiki pattern of having individual spaces for each team.

Where separate wiki installations are created, it may also be possible to configure easy interlinking (e.g. MediaWiki's interwiki feature) while centralised recent changes could be presented using an RSS aggregation.

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

  * This is **related to** [[Naming+Conventions|Naming Conventions]]
  * This is **similar to** [[My+Personal+Info|My Personal Info]] .
  * This is **similar to** [[Business+Units+-+Buckets|Business Units - Buckets]] .
  * This is an **example of** [[Clean+Permissions|Clean Permissions]] .
  * This pattern is **contrary** to [[Permission+Granted|Permission Granted]] .
  * See also [[Permission+Patterns+Overview|Permission Patterns Overview]]

===== Further Reading =====

  * This contribution was initially taken from Using Wikis to Manage Use Cases: Experience and Outlook, page 113 of  [[http://www.se.uni-hannover.de/events/LSOplusRE/LSOplusRE-Proceedings-web-v1.0.pdf|Proceedings of Workshop on Learning Software Organizations and Requirements Engineering]]