grow your wiki
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.
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.
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!
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.
A simplistic way of achieving this is to install entirely separate wikis for different groups/teams.
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:
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.