talk:one_wiki_space_per_group
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | talk:one_wiki_space_per_group [2018/11/14 21:14] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | |||
+ | ---- | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | Typically, the spaces that are ' | ||
+ | |||
+ | Any advice or a previously **successful** pattern of space/ | ||
+ | |||
+ | |||
+ | 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 " | ||
+ | |||
+ | The configuration for this is very simple: a 32-bit integer serves for flags for up to 31 seperate namespaces. Users similarly possess a " | ||
+ | |||
+ | 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. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | In this case, users are permitted to modify their default subscription profile. See for example | ||
+ | |||
+ | | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | 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' | ||
+ | |||
+ | |||
+ | 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' | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | 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, | ||
+ | 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 " | ||
+ | |||
+ | |||
+ | |||
+ | Posted by Tony Branfort at Jul 05, 2007 22:14 | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | * M. Decker: Now that we're starting to see some concrete examples (you cite "too many attempts at creating a page entitled ' | ||
+ | |||
+ | Anti-pattern: | ||
+ | |||
+ | Cause(s): | ||
+ | |||
+ | * Inward-facing rather than outward-facing contributions | ||
+ | * Time-sensitive rather than timeless or timely contributions | ||
+ | * People are using the wiki as they would a project management framework or file system, not a shared knowledgebase | ||
+ | * (perhaps) Technological limitations: | ||
+ | |||
+ | Solution(s): | ||
+ | |||
+ | * Institute a decent project management framework to handle the inward-facing, | ||
+ | * refocus the wiki contributors to posting the outward-facing and time-insensitive components of the project life. | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | Can naming conventions handle the issue of " | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | What the " | ||
+ | |||
+ | To achieve this would be needed a really good wiki tool with at least the following features: | ||
+ | |||
+ | * Intelligent access control and group management rights delegation | ||
+ | |||
+ | * Maintainable templates which keeps the content separable from the template and with ways to enforce suitable default access control settings | ||
+ | |||
+ | * Good search and listing functions to make automatic and manual listing of group contents possible (for example creating a list of "all pages of group X not yet manually linked from the group X index page") | ||
+ | |||
+ | **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 " | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | |||
+ | Posted by CarlJohanSveningsson at Dec 08, 2007 03:42 | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | I like the pattern in general. We use kind of similar thing in [[http:// | ||
+ | |||
+ | |||
+ | Posted by Daniel at Dec 17, 2007 04:00 | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | Re: Daniel, how do you mean you " | ||
+ | |||
+ | 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: | ||
+ | |||
+ | * TikiWiki | ||
+ | * TWiki | ||
+ | * XWiki | ||
+ | |||
+ | **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, | ||
+ | |||
+ | |||
+ | Posted by CarlJohanSveningsson at Dec 28, 2007 12:31 | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
talk/one_wiki_space_per_group.txt · Last modified: 2018/11/14 21:14 by 127.0.0.1