I don't have an answer or negative agenda (and hopefully I'm not Trolling) but the treatment of this topic so far seems wholely inadequate for dealing with 'real word' organizations of more than a couple hundred people, where you have multiple axes that divide people (site/country/division/department/project/role or specialty/business unit) and yet most people work on teams accross several of these axes. Therefore the creation of a space for every permutation, and granting individuals 'broadest possible access' to each of these permutations, is both an awesome administrative burden and potentially not even feasible – we would have more actual groups than actual employees and perhaps none of the projects would ever reach critical mass. On the other end of the spectrum, if we try to jam everything into one or a few spaces, we definately run into turf wars, non-safe zones, name conflicts, philosophical divides, managerial lock down, not to mention legitimate permission and access control issues.
Typically, the spaces that are 'naturally' made are indeed project centric on a fairly small scale, with one project per team adopting the space for a particular use, but then they are locked down, or isolated virtually, and there is little cross team sharing of practices and content and much duplication of effort. In fact, we have some teams that have multiple spaces, each for a different role but essentailly made up of the same people! We don't want to limit these natural seeds, as this is how the wiki will grow, but we do want to encourage them to be tied together and we do want to prevent some of the forseen administrative burden we will encounter if the pattern of 'one space per team/activity' continues.
Any advice or a previously successful pattern of space/permission architecture in a multi-dimensional 'matrix' large organanization (other than wikipedia model of all-open-all-the-time which is not feasible for many existing companies?)
Posted by James Mortimer at May 02, 2007 10:08
Alert: this is about a technical solution to the issue.
Over in the FoxPro Wiki I deal with this issue simply with what we call “transclusion”. It works with a Publish-Subscribe model, wherein each wiki topic is assigned to one or more namespaces, and users then subscribe (or are assigned) to one or more of these namespaces.
The configuration for this is very simple: a 32-bit integer serves for flags for up to 31 seperate namespaces. Users similarly possess a “subscription” integer that also serves as flags for each namespace.
Thereafter it's a simple matter of bit matching to determine if a topic is resolved, or not, for the user.
For example, the following wikis all come from the same data, and are served by the same server-side instance.
http://fox.wikis.com <sup></sup>
http://sql.wikis.com <sup></sup>
http://vb.wikis.com <sup></sup>
http://b2b.wikis.com <sup></sup>
In this case, users are permitted to modify their default subscription profile. See for example
http://fox.wikis.com/wc.dll?Wiki~TransclusionReport <sup></sup>
This has been working like this since 1999 and it's very slick and works just fine.
On private wikis, the namespaces are typycally named for departments or groups, like “developers”, “marketing”, “tech support”, “accounting”, “HR”, and so on.
In this way you get “one wiki space per group” but, behind the scenes, it's one consolidated wiki.
I hope this is helpful…
Posted by Steven Black at May 03, 2007 11:07
I have wrestled with this issue myself and I've blogged about it internally a bit. My organisation is project based and team based. I work in multiple teams and generally change project every week or so. If we had a different space for every project and team we would end up with thousands of spaces many of which would just end up dormant.
We currently operate with thousands of different databases and the problem is that there is very little collaboration and knowledge sharing between teams. The beauty of a wiki is that it brings everyone within one database and potentially allows everyone to see what everyone else is up to.
I'd argue that the way to start is to give one space to each group of between 50-200 people. All the projects which that group works on can go in that group's space.
Posted by Charlie Perry at May 04, 2007 00:21
My view is that multiple spaces will be better for one large space as information can be better classified and organized and it will be easier to look for information. Sometimes searching can be very tedious when there are all lot of similar pages.
Wouldn't it be better to create multiple spaces and also different groups and then give some spaces to the same group of people. Maintenance effort can be reduced by changing an user's membership to the group and all the spaces access will be updated accordingly.
It also enjoys the flexibility of excluding someone else from a particular space if there are multiple spaces being defined as compared to one single space.
My 2 cents.
Thanks.
Posted by Sim Hua Soon at May 19, 2007 21:52
I gave this page a complete rewrite and added a large section on disadvantages.
My own view is that this is actually an anti-pattern! It's a mistake to lose out on cross-organisational collaboration and mindshare, just because of a few page naming issues.
I did also expand upon the advantages. Hopefully the article is reasonably balanced now.
Posted by Harry Wood at Jun 08, 2007 11:25
Hi,
I still stick to this pattern. OK, it does not make any difference if you are using a sub-web/wiki oder a separate wiki.
To differentiate information into different Wikis, the lifetime of the information needs to be taken into account (next to the access rights) .
Take the team / project example mentioned before:
- The team (People, corporate structure, general regulations, lunchplan) is something that will last longer than the
projects. –> This forms a group of its own
- The projects have a limited lifetime, so they also form a group of their own.
Crucial to this pattern is the usage of the Interwiki feature to easily link other wikis. The link is normally directed to the page that is created earlier (e.g. from a project, the personal homepage of a person is linked)
Namespaces won't do the job - they are used Wiki internal (e.g. like Images in mediawiki)
Another simple Pro for this pattern are naming conflict.s Imagine wiki pages that hold minutes of project meetings. If you a re just using minutes, you might get a naming conflict. Adding prefixes makes the title longer and harder to remember.
These naming conflicts actually initiated the considerations why we set up this pattern.
Finally, if set up right, people tend to accept the wiki as THEIR wiki.
Posted by Björn Decker at Jun 12, 2007 18:34
Great page and discussion. I can see both sides but overall I would agree with Mr. Wood that this is an anti-pattern. Working for a company of 30,000+ I constantly see confusion and missed opportunites because of communication pools and segmentations. I think the real advantages here will be when everyone in the company knows that when they go to the “topicNameHere” page and see (1) oh, other people use that name for different things and (2) wow, look at what everyone knows about the topic I'm looking for. It helps everyone think outside their 'space' which is a good thing.
Posted by Tony Branfort at Jul 05, 2007 22:14
Anti-pattern: One Wiki space per Group “wikiAdmins find they are requested to create an individual space for each project / team because of naming conflicts on pages such as 'meeting minutes' or 'purpose'”, or because of disagreements on permission settings
Cause(s):
Solution(s):
If this change is not too draconian and I get some positive feedback on this comment, on my next visit I will incorporate into this article.
Posted by James Mortimer at Aug 13, 2007 15:00
I am trying to devise an organization structure for a wiki that will start with 200 users and if successful could expand to 5,000 users in a large company of potentially 50,000 users.
Too many areas: I would argue that sub-wiki's that go dormant often creates the need for more gardening (not less). Someone must determine what content is relevant to merge into some more permanent area (and what to throw away).
The more Projects and Teams change, the less fun it becomes for the Gardener. If it takes too much time, people won't do it. Companies are constantly trying to re-invent themselves, realign departments as markets change, whole divisions move around.
People need one obvious place to create new content, and to look for it. For example, I have one “TestAutomation” web and then other “ProjectXx” webs, when I create a new topic, does it go into TestAutomation or ProjectXx, or both? I usually pick TestAutomation because the test outlives the project. ProjectXx2 could redefine. Again time. I don't want to have to move the topic later, but I want the ProjectXx folks to be able to easily find their TestAutomation while it is relevant.
Can naming conventions handle the issue of “MeetingMinutes” topic creation 50 times? do “XxMinutes”
Thru all the organization changes, ideas, teams, projects, what stands up to the test of time? My role as a Z and my work on product Y assuming ProjectXx is part of product Y . And some kind of sandbox area for stuff way too new and undefined to fit into anything else.
Posted by Ann Brady at Oct 05, 2007 15:42
To me this issue seems incredibly tricky to work with, especially in a corporate environment. However, I am hoping to find a solution, so bear with me for this somewhat lengthy and technical comment. If you're really into good wiki usage, please read the whole thing and comment on it.
IMHO, obviously the drawbacks outweigh the benefits of this pattern, making it an anti-pattern, but I'm yet to see any good enough suggestions on how to avoid it.
The challenge here is how to achieve a solution which gives the requested benefits (easy partitioning of access control and information scope as well as delegated management responsibility and local sense of ownership) without suffering the consequences of one wiki-space per group (limited organization transparency and partitioning when it's not suitable, leading to duplicated or misplaced information)
If you enjoy the luxury of projects which are easily separable, then great, put them in different namespaces, replicate the little they may have in common and be done with it.
If you don't need to restrict access then it should be possible to create group pages with some content belonging to several groups, so that's pretty ok at least.
It's getting hard when you have a multitude of different constellations where you want to achieve the benefits of wikis and transparency, while maintaining order, sense of ownership, access control and without having to hire (too many) monkey-workers to keep this in order.
What the “free” world often forgets is that access control and confidentiality is about more than just corporate secrecy - In our organization we both need this, but scalable access control would also be great to keep nice order and keep an information scope to the limited group related and then they could “de-classify” or “publish” certain pages for other groups or everyone to see. I am aware of that “free for all to see” is a generally advised wiki policy, but sometimes it is also good to just shade people from too much content.
To achieve this would be needed a really good wiki tool with at least the following features:
What wiki engines do you know which are closest to provide this? I have got the impression that twiki has pretty nice support for fairly advanced “situational applications” and mediawiki must be pretty scalable as well, but will I be happy if I try them out?
Currently in our organization we use MoinMoin, without really having anyone able to custom-write macros in Python and besides I think MM has too large flaws for example in template maintainability, search functions and access control management.
Also we have patched in hierarchical ACLs, which would effectively be analog to wiki partitioning and interwiki linking or twiki subwebs - one wiki space per group, besides it gives really ugly naming habits. Wikis are not at least strictly hierarchical - I imagine a sort of delegated ACL scheme, where the member of a group may add access control to a page unless it already has some and where multiple groups may share control of pages.
There still ought to be no problem to keep access hierarchical where needed, just a matter of not granting the top-level rights to anyone outside of it. It may seem complex to get non-strict hierarchical inheritance of access control, but I believe it could work and is necessary to achieve a truly scalable “non-free” wiki.
Posted by CarlJohanSveningsson at Dec 08, 2007 03:42
I like the pattern in general. We use kind of similar thing in Wrike.com <sup></sup> . We have tasks in Wrike and update them writing new information in the tasks body. This way information is kept organized and we can easily update it.
Posted by Daniel at Dec 17, 2007 04:00
Re: Daniel, how do you mean you “like” the pattern in general, and how does it apply to the relationship between Wrike/tasks? Obviously you couldn't use one wiki space for such a small thing as a task, or how big do they get?
To me it looks like a cheap way to try to pitch an indeed quite interesting-looking project management solution.
To update on my own progress, I got someone suggesting me Confluence as a feasible option, with little further motivation rather than it's solid. That someone however didn't want to pitch it here, since, as you can see below, wikipatterns is sponsored by Atlassian Software. However, it's worth noting that both Confluence and XWiki are based on Reposita Radeox, thus seem to share some in look and feel, and possibly some in features.
Currently we have decided to further evaluate:
TWiki is looking like the current strongest and simplest candidate, in which will try to implement (and of course will come back and report on the result) the above described scalable categorization and access control scheme to mediate the drawbacks of this pattern.
Totally of topic, team members have started to use FreeMind as an extremely cool way of linking and organizing chunks of information, and we'd prefer a wiki with that integrated as a plugin or something. Does anyone use it?
Posted by CarlJohanSveningsson at Dec 28, 2007 12:31