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?"
I welcome Wikis to my organization. We've been using Dokuwiki for past year and it's been a success story. Knowledge is shared in an effective way.
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.
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
I'm a wiki skeptic. It works fine on a large scale like wikipedia, but smalls-scale wikis - such as in your office - tend to be rubbish. Nobody has ownership over content and they suffer from the tragedy of the commons. I think it's probably more effective to use a blog for lots of internal communication, and then probably some sort of CMS-with-comments where you need a graph of pages.
Believe with me, my saplings.
... and I consider it one of the best things I've done there.
The situation we used to work in was that we had a lot of customer information that changed quickly, a group of engineers who worked disparate hours (there was supposed to be someone available between 7AM and Midnight) and documentation that was scattered all over. We had a central repository for documentation, but it was the pits. You could only search on key words or categories, check-out and check-in procedures were laborious, if not counter-productive, and everything had to go through an approval cycle. Finally (and that, combined with the fact the repository was unsearchable, was kinda the nail in its coffin), reviews were partially based on how many entries you'd submit. The end result was an essentially unsearchable repository was filled to the bring with duplicate entries and outdated stuff.
Fed up with that, we created a Wiki on the side project. Initially I filled it myself with random things that I found useful. Then other people started using it. It wasn't perfect, but it was loads better than what we had - we could actually find information! Outdated stuff could be updated. People didn't have to call others at all hours of the night for server information anymore. And best of all, new hires could be pointed to it, and they could find useful starting information.
To give you an idea of how successful it was, it was initially completely disallowed by management, as it was creating a duplicate information store. The desktop server on which it was stored was yanked. But it stuck around, because people actually used it. Now, the entire group uses it for storing training, server, contact or any other information that a lot of people need and that changes often. Contrary to the commercial data storage software, it helps us do our job more efficiently.
Wikis are undeniably useful and loads better than anything else out there - if you make sure that the information you try to make accessible falls in the following categories:
- lots of different people can use it
- changes often
- lots of people can contribute to it
Oh, and it also helps if people aren't dicks, to use Wikipedia's rule.
Those who can, do. Those who can't, sue.
At our university we have several different instructors teaching a series of logic courses. Currently, each instructor uses their own favorite notes and textbooks. This means that what students learn in in one class is different from what is used in the very next course in the series. We also have several different instructors for the same course, each develops her own course materials. It's a mess.
We have started using a wiki to cooperatively develop materials for this course. We hope that it will eventually replace the text books. People are excited because no one is giving up control of *their* course, but at the same time, we don't duplicate efforts and people are forced to resolve their differences when it comes to presentation.
-z
I finally (last week) got a go ahead on a Wiki which I have been playing with, but couldn't get anyone else on the sub-group to play (on the road, not enough time, yada yada) to at least stick one on the new intranet. I was working with MediaWiki, but their install readme says it is more for Unix/Linux and this is a strictly Windows house. I think it oughta work on the Windows server, but haven't set it up there, and wondered if there is any recommendations amongst the /.ers of a Wiki that will be easy to setup and easy to use.
For our purposes, almost anything is a step in the right direction, but I am not the one who will be doing the full install, merely assisting he who maintains it all.
My brain is overly lubricated
I realize that mediawiki is the current myspace of wikis, but it is not really ment to be deployed in a corporate environment. Most corporations would need to use a wiki with more access controls like TWiki or confluence.
I've heard that a while ago, some folks inside Intel set up a mediawiki site for internal documentation, and when the lawyers heard about it, they had the project shut down. There was too much liability I gather.
Anyway, I've set up a TWiki installation at my work three years ago now and am not totally sure if I would call the project a success story.
First off, in order for management to buy in, we needed to demostrate that we could lock down sections and properly secure the site. With TWiki it was easy to create 'Webs' with different access permissions.
Second, in order to get users to buy in, we needed a reason for them to go to the site. For example, they go to the site and find useful content, and so therefore get an idea that the wiki is useful for them. When starting out, there is no useful content in a wiki. Two or three of us have been dutifully putting in what we know into the site, but it has taken maybe two years of effort before there is enough content for other people to find the site semi worthwhile.
It would be better if everyone just 'got it' and contributed to the site right away.
Another issue is the employees that know a lot but like to horde information. Having a nice collaboration tool around will not get them to release nugets of information they certainly have.
Some people insist on publishing perfect documents to the wiki. Those kinds of documents are nearly impossible to come up with on the first pass, and so a lot of documentation that is partially captured and written up has never made it to the site. I'm sure this issue is partly my fault as I haven't impressed upon the users that it is ok ot put up half ass content into a wiki, and then work on it later to polish it up if it would be useful.
One more problem we've had is that most of the employees think that documents in the wiki are owned by the creator of the document and not to be touched by them. I know I have explained about colaboration and cooperative editing a lot, but still, most people will not fix minor errors in documents created by other people. I have had people come up to me and tell me that there is an error in a document I've written in the wiki, or some have sent me emails telling me so. I have demonstrated that they should have edited the page themselves and fixed the error, and now a few of my fellow employees are more willing to do that.
Anyway, even dispite all of these hardships and difficulties, I think the wiki installation is invaluable, and at least for the few of us that 'get it' with regards to wikis, the site has made us maybe 20-30% more productive then we were before we had it around.
My god, thank you for that pointer! That wizard is fantastic at whittling down the data deluge.
One simple rule for its versus it's
It depends on the company. I set up a wiki for a small company of all fairly technical people. It turned out as a great place to share ideas and documentation. Of course it was a small group of people, but if the people using it respect each other then I don't see a problem with the openness of allowing most everyone to edit things.