Slashdot Mirror
Put MediaWiki to Work for You
NewsForge (Also owned by VA) is running a short writeup on how to put MediaWiki to work for your organization. The writeup includes several addition tools that could be helpful in rounding out the overall package. From the article: " Imagine how useful it would be to have an online knowledge base that can easily be updated created by key people within your organization. That's the promise of a wiki -- a Web application that 'allows users to easily add, remove, or otherwise edit all content, very quickly and easily,' as Wikipedia, perhaps the best-known wiki, puts it. Why not bring the benefits of a wiki to your organization?"
Because I want to start a cadre of petit bureaucrats who think their subjectivity is objective and your objectivity is subjective.
What a thoroughly useless article! It makes some vague assertions about what a MediaWiki good for, and than just regurgitates installation instructions. How about comparing this Wiki software with its many alternatives? Or even explaining why Wikis are so big?
Learning how to successfully edit a wiki page can be quite easy, however learning to completely manage a wiki and learn all of its editing and layout syntax is another matter altogether.
"To err is human, to mod Funny divine."
I work for a large visual effects company, and we have been using this resource for a while now. It is especially helpful when dealing with frequently changing pipelines and procedures, because it provides an easily modifiable up to date resource that can be accessed remotely from any machine on the lot.
The wiki solution to every problem: add more idiots.
-Grey
Silver Clipboard: Time Management Tips
Because of recent vandalism, or to stop banned editors from editing, editing of this page by new or unregistered employees is currently disabled. Please discuss changes on the talk page, or request unprotection. Anyone continuing to propogate stories about the CEO, the monkey and the baby oil will be severly reprimanded.
It worked for me. I teach physics at a community college, and our physics stockroom has hundreds of pieces of equipment that we need to keep a catalog of. The solution we tried before was that the lab technician kept the catalog in an MS Excel spreadsheet. The problem with that was that if someone other than the lab tech wanted to add something to the catalog, or document the fact that they'd moved it, there was no easy way to do it. Also, the only way to get access to the latest version of the catalog was to ask the tech for the latest (paper or electronic) copy. None of this worked very well, for example, in night classes when she wasn't there. I converted the catalog to a wiki, and I think it's worked fairly well. Nobody in the department was familiar with the concept, so they needed a little hand-holding. But even people who aren't comfortable with editing a wiki can at least understand that there's this web address they need to go to in order to find a piece of equipment.
Find free books.
Don't expect to be able to extend or modify it easily. I've come to the conclusion that it would be easier to reimplement it than to modify it.
I'm not a MW guru, but does the article's idea of <PHP> tag really do what I think it does?
As in "raw code in a a place where people can edit it?"
Doesn't matter they are trying to limit the wiki's edit access only to registered users - this is wrong.
Ugh. You know, one of the reasons why I like MediaWiki is that it does well with separating the page code from the HTML. And now these people want to sprinkle random PHP crap in the pages again. Argh.
And as an additional bonus, you get to store your mysql_connect() parameters to the page source. Whee. Realllly smart.
Somebody please submit this to TheDailyWTF...
The real way to do this is to write a MediaWiki extension, of course (look at ParseFunctions for an example of something simple), which is then accessed through the usual hooks, like {{foo:...}}, but don't ask me, I don't know that much about MW's internal structure. I just know bad ideas when I see them. =)
There are many different Wikis available. All with different pros and cons. To compare them all is the aim of the WikiMatrix project. If you are not sure which Wiki is best for you, WikiMatrix offers a Wiki choice wizard.
Sure, user education would help here, but there is only so much one can do... especially in a company of 30,000+ users.
While wikis certainly lower the bar for producing web content, there really needs to be some sort of way to prevent users from doing things that they don't particularly realize are (overall) harmful. Or at least much better training tools.
I like wikepedia, but I don't like wikis. Your "knowledge base" is your web site or documentation section. If you add a wiki, I have two places to search for information, do I have to look in the docs, or in the chaotic wiki, where you won't be able to find it anyay? Wikis seem an excuse for laziness, just throw the information somewhere instead of making a structured, well designed web site or documentation section.
I've put into it design documentation, instructions for accessing our other services (e.g. Subversion repositories), troubleshooting tips, sequence diagrams of various race conditions, you name it. I try to periodically dump everything in my notes directory into the wiki. The effort of cleaning it up means I'll understand it later, having it on the wiki server means it's backed up regularly, and as a bonus, other people see it and don't need to ask me as many questions, so I can spend more time developing. And it gives people a way to still get answers when I'm off bicycling through Africa.
But collaboration technology like MediaWiki or bugzilla only works when people use it. There are always some people who won't play with others. If I put information on the wiki, they'll come bug me for it anyway. If I tell them it's on the wiki, they still won't read it. If I give them information verbally and specifically ask them to put it on the wiki, they won't do it. And then they wonder why I ignore their emails...
Our management wanted an "intranet" a few years back but had zero budget. My answer was JSPWiki on a Linux box.
The wiki has succeeded in a couple of notable areas. The photo directory page is critical for learning new faces on a rapidly growing staff. Another page has completely replaced sticky-notes that were formerly used to coordinate certain tasks among staff and interns. The IT department has a lot of miscellaneous documentation pages. A few other pages serve the function of an electronic bulletin board for staff scattered across two buildings.
Management was very concerned at first that staff would abuse the wiki, either by wasting time posting trivia or by outright vandalism. Neither fear has materialized.
The biggest failure of the wiki is the number of abandoned pages. They don't do any harm, but about a third of pages are derelict, with old information that the author obviously lost interest in maintaining. Having a wiki editor might solve that problem, but in practice it doesn't rise to the level.
org.slashdot.post.SignatureNotFoundException: ewg
Now, I may be wrong, (and I welcome corrections if so), but from what I gathered, MediaWiki has poor-to-nonexistent support for advanced granularity of permissions. Essentially, everything is editable by everyone. Beyond that, there is a very simple level of control inasmuch as admins can lock a page and whatnot. But setting up a system whereby users come out of AD/LDAP and can edit (or not) different areas corresponding to their department/group, or setting up workflow systems where (for example) anyone can edit but it must be approved by a departmental admin (who can act as admin within their department's pages, but not elsewhere) before showing up... It didn't look as if any of this was possible.
Furthermore, I was told there's no point even asking for it. Because such things don't gel with the Wikipedia philosophy, the people spending their time coding MediaWiki simply aren't interested in implementing them. (Don't get me wrong, I'm not whinging about this - naturally they should devote their time to features which actually suit their demands, not somebody else's).
So it seems to me very odd to promote MediaWiki for the corporation, when other systems have much more sophisticated ACL-type features, granular permissions, and so on.
Comments welcome?
(PS. FWIW, we eventually settled on Plone. Plone does have a Wiki plugin so if we ever do use Wiki's I guess we'll use that. But I'm still evaluating which Wiki system to use for a separate project, outside work, but which still requires more advanced editing permission granularity. DokuWiki seemed the best fit, with the one problem that it uses flat files for storage, and our sysamin would prefer a db backend as they have a dedicated db box, so it'd be quicker. WikiMatrix narrowed it down to ErfurtWiki, Midgard Wiki, miniWiki, PhpWiki, TikiWiki, WackoWiki and Wiclear: out of these, I didn't like the look of phpWiki for some reason I can't remember right now, and I've never even heard of the others. If anyone has any experience with any of these systems, please do share :) )