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."
OVERTIME
Overtime must be paid out as double time, with the employer providing meals, alcoholic beverages, and a masseuse.
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.
So... On one hand people are spending some more time in reading the injokes of their work-buddies but on the other hand, people are consumed by endless edit-wars.
I can see how helpful it can be for a company.
Seriously though, a friend of mine actually did install a wiki under the same premises of the article. They are having lots of fun with it, but it hardly helped their workplace.
I wonder if PHBs would even like this? Many would prefer a system in which info passes through several hierarchies before being published, the idea that anyone can edit and their edits would automatically be viewable would put off many clueless PHBs...
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.
Yup, you can almost heard it overdubbed in a soft-spoken male voice on top of muzak and footage of offices....
as part of a sales pitch.
I setup a wiki for our small software company a long long time ago. This really isnt anything new. Wiki's are great for documentation, especially with any rapidly changing products.
Its cool that this idea is put out, but I don't understand why this is such a big deal. It was on newsforge, linked from ITMJ, slashdot too? Yippy?
snowulf.com
it can work for your company!
It's not offtopic, dumbass. It's orthogonal.
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.
New edit:
Overtime must be paid out as double time, with the employer providing meals, alcoholic beverages, and a nude masseuse.
When the public for a MediaWiki installation is not too big, a must have extra is the Semantic MediaWiki. It really helps in making content rich and when using it in an environment for more organisational knowledge sharing, it is one of the best extras you can find. Thanks, GerardM
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.
We are using Mediawiki as documentation system to document all our servers, procedure and contacts within the tecnical departemnt. Since I am an open source advocate I introduced the system in 2003 and from there it only grew. Although you have to keep a look at it and do a re-structure from time-to-time to adjust to the amount of information it has been proven to be very useful. The only thing i am really missing is a good admin structure where it would be easy to configure a closed user group of editors since we would like to keep passwords and things like that in the Wiki too.
On the other hand an alternative would be a good password sharing solution. It should be safe and very strict in how I share password with other people using teh same too. Does anyone have a good solution to this problem?
Spelling errors were made for your amusement only...
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.
What the heck is VA?
This is the second post I have seen recently that states that something is also owned by the mysterious VA.
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...
I actually installed MediaWiki last week as an attempt to get documentation moved off the dreadful pile of crap that is Lotus Notes. Its amazing how quickly useful content has been added to this since the documentation on Lotus Notes is updated so infrequently. The difference is that Lotus Notes is not very easy to use and MediWiki content is a simple search away.
NEW EDIT - by Employer
Overtime need not be paid out at all, with the employer providing no benefits.
the layman's guide to computer science
Nice try, goddamn taylorist.
Wiki not gonna hit main stream in cooperations until the Oracle support is streamlined. I have a version at work I got about a month or two ago that has issues with the basic install using Oracle. One mistake and you have to DROP everything it created (providing you can actually figure out what it created). Hasn't MediaWiki dev folks herd of "CREATE OR REPLACE?"
From the article:
let's see where the wiki comes into its own. Try editing the Main page, save the changes, and then click on the History tab. You'll see that MediaWiki tracks who made all changes and when. You can compare the differences between different versions. In one fell swoop you've got yourself a document management system as well as a potential in-house knowledge base.
Let me put that into perspective. One of the main features selling M$ Word is easy to use versioning. So, imagine people at your place of work using a Wiki instead of emailing each other 20MB binary files and overwrite each others changes all day long. Give them a decent browser with spell checking and this is a much better way to share work. Oh yeah, it's also free.
Friends don't help friends install M$ junk.
I've volunteered for to setup a Wiki for a CRM we use, but the admin is not clear.
It would be real helpful to have a Wiki-template or importer tools.
How do I move CHM/html docs into Wiki? I want to search the manual.
How do I backup the database? (yeah. dump the db but where's the GUI?)
If I use GNU documentation licence, why doesn't the wiki populate it, or any how-to-wiki articles?
How do I easily set up Catagories, without modified each and every page?
I've read the mediawiki guide, and asked the CHM/DB question in the IRC forums.. to no avail.
The things I want to see in our Wiki are
This is why I'm working with efurt, as it seems to be pretty modular and easy to adapt (bsides being PHP based).
Is learning MediaWiki really any harder than learning Microsoft Office Word or OpenOffice.org Writer?
Many would prefer a system in which info passes through several hierarchies before being published
Then let the hierarchy approve specific versions of each article that are copied to the world-visible web server. Remember that MediaWiki stores all previous versions of each article.
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
Your "knowledge base" is your web site or documentation section.
And your web site or documentation section is a copy of wiki page versions chosen by your program's release crew. Release engineers search for the version of your page that most closely matches the behavior of the release branch and then copy that version to the publicly viewable site that uses the same wiki engine.
A wiki can be a great tool for sharing information in a company or another community.
However, the information does need to be organized, otherwise you can only really put info into it and nobody will ever find it. Luckily Sinorca4moin provides a wiki editable navigation menu, that allows you to put some minimal organization on top of your wiki.
This has allowed me to migrate the Kernelnewbies site to a wiki. Now it gets regular updates again...
Changes to corporate policy without consensus on Talk: shall be treated as vandalism.
It's a huge improvement on any previous method we've used to organise our documentation - mostly FAQs, instructions, process documentation, links to external resources, screenshots, all sorts. Apart from backups (VBSCript to take a MYSQL dump and copy the images directory), I use HTTrack to take a 1 link deep HTML snapshot of the 'Special:AllPages' page. This can be copied to a laptop or flash drive for offline reference. The wiki pages cut-n-paste into word nicely too.
I've recently come across TiddlyWiki, which is very nice. I'd consider that for any future small scale projects.
Simon Hibbs
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.
Hasn't MediaWiki dev folks herd of "CREATE OR REPLACE?"
First of all, have MySQL folks heard of it? MySQL uses the syntax CREATE TABLE [IF NOT EXISTS]. If you want MediaWiki to use IF NOT EXISTS or other DBMS programs' equivalent, then you're free to file an enhancement request at MediaZilla (bugzilla.wikimedia.org).
10 PRINT "LOOK AROUND YOU ";
20 GOTO 10
... 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.
Says it all, I think.
You cannot truly appreciate Dilbert until you read it in the original Klingon.
We have used mediawiki in my department (Emerging Technologies) at PSU and it has been a great success. There is some features to be desired that we had to modify it to handle. Specifically, using an external authentication system (we already have University wide accounts through Kerberos and our web single sign on system thanks, don't need another one) and some form of access controls would be nice, but overall it is great.
However, you really need to work with people who already are used to collaborating in general. A wiki is not going to change anything if the people you work with don't already work together on stuff. Interestingly, our "killer" use so far for it has been the yearly report, which is generally a huge document that everyone contributes little bits and pieces to. That seems to be the best use case for a wiki.
Finkployd
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
We've used the Wiki for a while now at ECONZ http://econz.com/ and it has been very useful. All it needs is someone to take control of the formatting of the site, rather than just leaving everything totally free range. The one remaining problem is the actual editing process, which MS Word users can't seem to get their heads around.
:v)
We did find FCKEditor http://www.fckeditor.net/ but that doesn't come built-in and support is beta. Mention that to the system admins, and they'll refuse to install it. Once that gets integrated, we'll be able to get even more of the staff using it.
Vik
I believe Lifehacker had an article showing you how to set up a MediaWiki on a Windows machine.
I tried this, and it worked quite well.
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
We're using an in-house MediaWiki knowledge-base system here. It's been running for over a year and is a huge step forward from the previous setup we had(which was developed in-house in CF). The hardest part was writing code to export/parse/import from the old system to MediaWiki. Once that was done it's been smooth sailing
4 (a patch to have restrictions of namespaces to certain groups)
Some useful add-ons we've used are:
http://bugzilla.wikimedia.org/show_bug.cgi?id=192
http://bugzilla.wikimedia.org/show_bug.cgi?id=814 (LDAP/ActiveDirectory authentication plugin)
It's a great example of a good open source tool beating the hell out of one-off systems developed out of a not-invented-here mentality
Perhaps the secret behind the wiki mentality is that once there are 1000 monkeys behind 1000 keyboards editing 1000 wiki entries, eventually one of them will end up being useful and correct...?
...and it seems that in this thread I'm monkey #4!
I really should read all the child posts first...
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 :) )
You can find information and a survey (in German!) about Wikis in Enterprises here: http://wikipedistik.de/umfrage/
Hopefully this information will be translated to english in the next 1-3 days.
But only 5 will be correct at the same time....
Fine-grained permissions don't gel with wikis in general, not just mediawiki. The idea behind a wiki is that most people are well-intentioned (this is triply true when they're using company resources), and that it's good to have lots of people collaborate. Even if readers aren't directly related with your project, if someone is interested enough to read the content, they might briefly stop to contribute in a number of different ways (some people will wander by and fix spelling mistakes... other people might wander by and hilight a possible security problem that isn't covered by the design document).
To start hacking on the awesome Semantic MediaWiki extensions, I downloaded XAMPPLITE (MySQL, PHP, Apache, and phpMyAdmin all nicely bundled for Windows) and the MediaWiki source. I had it up and running on Windows XP in 10 minutes!
For PHP development, I downloaded Eclipse and the PHPEclipse extension. I already had Cygwin and Vim installed, but I don't think you need them.
I've also used TWiki at work. The benefit of MediaWiki is the users' familiarity with Wikipedia.
Semantic MediaWiki adds attributes to articles (e.g. [[telephone:=555-1234]] ) and typed relations between articles (e.g. [[works for::Joe_Smith]] that you can query. So you can get information from articles without reading each one. Amazing stuff.
=S
That is not their way. While mediawiki does have a few basic permissions to keep guests from openly spamming, wiki's tend to be pretty trusting. That's not really a problem though because it's pretty easy to rollback bad changes and in a corporate setting that is good enough because the editors are all your employees.
I have used a Swiki (Squeak Wiki) for the last 4 years to organize IT/IS information.
While it is a fantastic resource from an organizational standpoint for many reasons,
In my experience it works as good as your people's incentive to input the information.
Ownership of information like "HowTo's" are an issue with some technical employees.
Very true, point taken.
In fact I did make that point in my doc. Something along the lines "although it may seem strange/scary to have everything freely editable, it does mean anybody can correct a silly typo or broken link on ANY page, which helps keep/make the quality higher, faster. Furthermore, since it is internal-users only, vandalism should be of no concern, and since it is logged-in users only, even if there is vandalism, the culprits are easily traced".
Nevertheless you know what managers are like. It would be nice to at least be able to offer such things.
Also, my other non-work project is for a public website where a degree of vandalism could be expected if we were not able to restrict permissions to some extent.
Finally I have to say, much as I love wikipedia, I do think there is some weight to the theory that pages don't always increase in quality - sometimes they get to a very high point of quality and then go downhill (I've seen it happen on the wikipedia pages I freqently edit in fact). So for my non-work project, it would be nice to be able to 'freeze' really top-notch articles from all but a cadre of trusted editors, and/or route newcomers' edits into a workflow system, or whatever.
In short: I totally see what you're saying, but for the sake of interest if nothing else, I'd still love to hear from people's experiences regarding Wiki's and permissions/workflow systems.
- do NOT allow MSWord or other complex documents to be uploaded as attachments-- it destroys the point of interactive communication
- train, train, and train some more. I am talking about a lot of coaching to get people through their first additions and edits. Once they 'get it', they'll be hooked.
- you will not be loved for the first while: everytime you get an attached Word or OpenOffice document, reply back to the person with "thanks, but why didn't you just put this on the wiki?" or "Thanks, please see my response/corrections/additions on the wiki". This pisses people off, because they are used to email ping-pong, but eventually they'll come around.
- you will not be loved by anyone who is feudal or territorial with "their" project or "their" process. Your choices are to train them, or when that fails, fire them (no, seriously).
If you can get critical mass going, you will be amazed at the results: email attachments almost evaporate, communication and overall awareness increase, the org flattens out a bit, innovation comes from anywhere, and development time is shortened.davejenkins.com |
But setting up a system whereby users come out of AD/LDAP and can edit (or not) different areas corresponding to their department/group,
For this reason, we used the Perspective Wiki -- IIS based, uses integrated AD authentication. Probably not the greatest Wiki software, but in my opinion any system that requires another password is a system that people aren't going to want to use.
Business. Numbers. Money. People. Computer World.
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.
These guys might have a few reasons why not to.
This probably holds for vandalism-type issues, but not for access control.
Imagine the wiki pages about a pending layoff. In a large organization you might want 20-30 people working on layoff related content, but you wouldn't want your entire staff to have access to it.
There are also issues with corporate intelligence. When you're releasing a top-secret kill-the-competition product you don't want your temporary employees, contractors, janitors etc. to be able to read all about it. Likewise putting staff's names and skills online could be a treasure trove for headhunters stopping by for short times at the company.
Mediawiki doesn't have the functionality to deal with these scenarios.
The problem with Wikis is the lack of a standardized markup language. They all differ in subtle ways. This is fine if you only use one, but I use several.
Hopefully GUI editors will minimize this problem.
but the management was wary of the possibility of it, even in an unofficial engineer knowledge base, becoming out-of-date, incorrect or unofficial information being relied on in place of "the real thing", (i.e. a spec or information from a supplier or customer); and we have reasonably open-minded managers. i agree that these aren't unaddressable issues; but hey, the reason we wanted one in the first place was because we're lazy.
I futzed with a few wikis to try and orgnise all the disparate parts of my life (which were usually recorded on a swarm of post-it notes). My main problems were having to setup/admin a httpd server on which to run the wiki, and then backing up/restoring the information in the wiki.
Eventually I found tiddlywiki.
Pros:
* no httpd required
* all information stored in a single html file (including the wiki code itself!)
* has tags and a search function
* monstrously quick and easy to set up.
Cons:
* haven't found anything about it I don't like yet.
I've now torn down every postit from my wall - if it needs recording, it gets stuck it the wiki (a process that takes less than a minute).
Cool, but useless.
Submitter has a bad case of Wikiphilia.
I wonder if it's related to Morgellons?
Laugh while you can, monkey-boy!
That site is about Wikipedia, not Wikis in general.
It's not typically the software's fault, it's the people. Managers are lazy/busy and resistant to change. Frankly most of them don't have the skill to organize a wiki properly. And the people who have the information to populate the wiki... well, why would they?
Knowledge bases are documentation. Who reads documentation? No one. I regularly spend more time writing documentation than people will ever spend reading it. (But it's in the contract and easy money.) If I'm an average Joe with a question, I'll just email someone. It's faster (for me) and, after the first few times I go through the project's wiki, try to navigate through it and fail to find what I'm after, I'm likely to never use it again. And forget about the people with the actual knowledge actually spending time to dump useful information in the thing. They might, after getting enough emails on the same question, but that's a FAQ list, not worth a wiki.
Three recent projects I've worked near have all had wikis. And each one (Project and wiki) is a huge mess. I'd wager problem is the project manager, thinking the wiki is going to manage the project for them, when what it really does is give them more work. After complaining about the state of the wiki's, a new project they offered me control of the wiki. I said, "OK" and deleted it. A few people complained, but in the end they couldn't use the "Oh, it's in the wiki" as a distracting excuse any more and the project (so far) is closer to budget and time than the others. (Still got that lame PM, but oh well.)
The people who want the wiki's are the same people who love "documenting" code with NaturalDocs. I went through their docs and out of over 500 functions and classes, only three were documented more than "Function: ConvertNumberToDollars (Converts numbers to dollars)". Wow. What a great use of everyone's time and resources that was.
I'm not saying it can't be helpful, it simply magnifies your management's skills--good or bad. And we all know how rampant bad management is...
Why does the article specifically focus on Mediawiki? As other people have pointed out, there are many wikis out there, some of which are faster and easier to use for certain purposes than Mediawiki. I myself run Dokuwiki on my website because it is enough for my needs and runs at a reasonable speed, unlike Mediawiki... I'm not saying that we should have an indepth review of all the different wikis in the article, but just saying "wiki software" rather than "Mediawiki software" doesn't seem too hard.
We use dokuwiki here (http://wiki.splitbrain.org/)
Although it might not be as featureful as MediaWiki, which imho is a behemoth, it has one key advantage: it Stores your pages in plaintext files, so that if you lose your webserver, php, whatever, you have still access to your stored info. very useful if you're a company that has to worry about DRP
It's also a breeze to setup and customize. MediaWiki seems to require a ponytail, pizzastained t-shirt and sandals.
Exercise caution when modding this message up: the author acts like a jerk when his karma is excellent.
I had a similar experience when I created a wiki for a project (on a corporately maintained wiki site). Noone on the team had heard of a wiki, so I explained it as a sort of "designer's notebook", but with a corporate memory. I tried to emphasize that they shouldn't get hung up on the formal structure that traditional design docs require, and just dump what they know, linking as is useful. I updated it daily with whatever decisions were made for the component I was working on, with a side policy that if I ever had to look anything up (or anyone on the team asked me a question), it went in the wiki.
After almost a year, people were still asking me questions that I had referred to the wiki multiple times, with only one other person contributing anything to the site. To your point, I frequently got comments about spelling/grammar but nobody would update the page.
It was unfortunate that I was the only contributor (as wikis have a sort of ebay effect), but there was definitely a net gain on my inputs. I'm always looking up the same things it seems, and I often forget why I made some goofy decision.
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.
In my previous job, I set up a knowledge base for our Product Support team using Swiki.
It replaced their previous knowledge base, which was done as a WinHelp file using RoboHELP, and as a result was never updated, because it was a PITA to do, and only a couple people knew RoboHELP.
Swiki was a lot easier to teach and use, could be set up to run as an automatically-started service on our Windows server, and has all the basic functionality we needed. It can also maintain multiple different Wikis, and can export the contents of the wiki to very nice clean HTML.
http://minnow.cc.gatech.edu/swikiSwiki wiki is here.
All opinions expressed herein are my own, and not those of my employers, who are appalled.
It seems like every How-To, indeed every article, review, report or book on open-source-anything whatsoever is at least 90% of "how to download and install foo." If you're really lucky an the author will spend a dozen or so pages on how to download and install the what-have-you on every sort of unix ever created. WHO CARES? Why does every author include such worthless padding in their articles? Even most published books on Free Software spend several chapters regurgitating the README and INSTALL files contained in the source (O'Reilly is one of the worst offenders). This is crap. It is a waste of my time. Please spend some time learning how to write engaging & useful articles, and join me in declaring a 10 year moratorium on redundant horsecrap about how to compile and install software.
All those people you would like to contribute will refuse to use it because it's not microsoft word.
Even though Wiki tags are much easier than HTML, they still aren't WYSIWYG, so PHB types would still find them confusing.
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
Might I read your paper? I've researched this a bit also. MediaWiki is perfect for managing a knowledge base. Others such as TikiWiki may be good for coordinating efforts. Then move on to Mambo for an equivalent to Sharepoint or Worksite. AFAICT.
People love elixers so want a magical way to be ignorant but still edit web pages. They categorize anything that can allow groups to dynamically edit web pages as a WIKI. The truth is the wiki engine's and webapps are specialized to certain tasks such as managing a knowledge base, shared calendar, project management, document collaboration, discussion groups, polls. Of course these could all be within one CMS/DMS; so, the term wiki then becomes relegated to shared documents in a knowledge base. MediaWiki when the document editing is open to all and another wiki engine with more security when needed.
Comments? Still want to read your paper.
Thanks,
TimJowers
Expect Freedom.
Twiki is more inclined to be branded and wrangled into "shape". Something that fits your business needs. (Unless you need an encyclopedia-type site, in which case MediaWiki is for you)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Basically the current system is very tree-like (parent->child) in organisation: every document sits in one place and one place only. Which is a very poor reflection of knowledge management really. (Furthermore every document has one editor/owner and one only.) Some members of the team seemed under the impression that this sort of rigid structure was the only possible solution technology could provide, so I used Wiki(pedia) to show it's often actually better to have one enormous "namespace", and let the mass of editors do intra-article linking, redirects, disambigs and so on isntead of traditional heirachical navigation.
Anyway... yeah... a very basic doc and the emphasis was on "a LITTLE research" - I basically discussed Mediawiki throughout, then noted there was a wiki-for-plone product, and many others (linked to the sourceforge wiki category/search), and that was as far as I got.
Sounds alot more useful than the "news" article that started this slashdot topic.
Best wishes,
Tim
Expect Freedom.