views:

220

answers:

9

I've been asked to install Mediawiki to house documentation for a company intranet. Furthermore, I've been asked to install several instances - one per contributing group: non-technical users get one, developers one, management one, etc. The idea is to provide separate web spaces for each group. Is there a way to achieve separation within one instance?

A: 

Your supervisor is wrong.

jrockway
Perhaps you would like to help the OP explain why to his boss?
EBGreen
lol... I can just see this conversation... NO, YOU ARE WRONG! JROCKWAY TOLD ME....
RSolberg
"Perhaps you would like to help the OP explain why to his boss?" Nope, but thanks for asking.
jrockway
+1  A: 

The namespaces are there for a reason.

Yancy
I'm not familiar with namespaces in Mediawiki. Can you expand on your answer?
i3ensays
+2  A: 

While calling out your supervisor may be enjoyable... I would have to think that it would be easiest to deploy a single Wiki like you've suggested with different categories or departments inside of the Wiki.

Also, given the current economic conditions, there may be some added job security in managing 5 or 6 Wiki implementations...

RSolberg
Any employee that I found intentionally "generating more work" would be rapidly removed. The job market makes replacing them too easy right now.
EBGreen
If you were the supervisor and calling the shots and the developer does not have a choice, would you then be removing yourself? This was a, yeah its not ideal, but that is a positive...
RSolberg
+6  A: 

I think you've already got a strong argument: maintaining multiple instances will be a pain. Plus, if all users can read/write to all of them, it'll be a pain in the ass to coordinate a sign-on system between them all.

You might be able to convince your supervisor that what you really need is one wiki using multiple categories, as it sounds like that is more what he actually wants. Categories can keep the entries organized. You could even write a separate portal page for each category (it'd sure be a lot less work than maintaining a new instance for each group!).

Though I don't suggest it, you could setup your server to have multiple entry points that point towards the same site... (i.e., wiki/dev, wiki/qa both point to the same site).

Daniel Lew
If it's on a company intranet, there should be a way to tie together MediaWiki's authentication and network authentication using one of the modules from http://www.mediawiki.org/wiki/Extension_Matrix, which is both the correct thing to do and would obviate the sign-on coordination.
DLJessup
A: 

I am working with trac, that based on wiki.
(With small assumption, that your wiki is something like wiki that i am worked with.)
I think that you can install even more wiki's, because they are easy to maintain.

Of course you can to suggest to your boss, to start with one wiki with many categories.
Suggestions:

  1. one wiki is a project that more flexible for backup and restore
  2. preventing from documentation duplicate
  3. start from one (lets say, for developers), and then add other wiki. (when developers is start to work on wiki, you can try again with "categories version" and you will know exactly what the cost of a lot of wikis)
  4. did he shure about the Mediawiki? wizard of wiki choising
Avram
A: 

If you do end up going with one wiki, with multiple namespaces, make sure to include the $wgNamespacesToBeSearchedDefault in your local settings, so that when a new user account is created it is set to automatically search the new namespaces by default.

Adrian Archer
+3  A: 

It would be possible to have several MediaWikis hooked together as a "wiki family" or "wiki farm". However I have to agree with the other commenters that this would be overkill if everyone has access to everything, and it's not a huge group.

Namespaces "can be thought of as partitions of different types of information within the same wiki, and keep "real" content separate from user profiles, help pages, etc." You might have namespaces "Testing:", "Dev:", "Mgmt:", "Users:". Then you can write about each topic from those different perspectives. So a page "Testing:Logging in", "Dev:Logging in", "Mgmt:Logging in", "Users:Logging in" etc.

However when you make [[links]] in MediaWiki, you always have to put the namespace explicitly (if there is no explicit namespace, it is the "main" namespace which has no prefix). So you would have to teach each group to always put the namespace into their links and searches. It's pretty annoying. If you are insistent on using an approach like namespaces, I would recommend PmWiki. Its "namespace" feature is called WikiGroups. Creating a "namespace" is as simple as creating a link, and more importantly, if you are on a page in a particular name, by default links you make to other pages will be in that same namespace. If you want to link to a page in a different namespace you have to put it explicitly. So that is a big plus for users.

But you certainly don't need to go to namespaces to organise content in MediaWiki. You can use categories and/or templates to group content. If you are likely to have more than one group writing on the same topic, though, it's likely you'll have page name clashes. You could just get everyone to write on the same page, separating the different author groups by sections, e.g. ==Users== ==Testing== ==Dev== ==Management==.

To be honest, from what you have described I would really just use PmWiki. It is quite simple and effective.

pfctdayelise
A: 

1 Year plus later - for any archaeologists who stumble upon this question,

http://www.mwusers.com

is an excellent resource for this sort of thing.

mickeyf
A: 

I recommend asking whoever asked you to do this why. It's probably for "security". But wikis are all about collaboration - that's when they flourish. And over-zealous security considerations will kill a wiki.

I suggest you argue for one namespace for the wiki and then separate wikis (or namespaces or even Word documentation with content management) for the "secure stuff".

Note that you can also track page views. If this is publicised it will lower the chance of a security leak.

Mark Robinson