This is a great idea, so here's my story: == Premise == I've introduced a wiki for a small corporate project team (~20 people), hoping to improve information flow, create a central information archive, and increase overall efficiency. (All desperately needed.) == Initial Reception == The wiki is still in its very early stages, and reception so far has been rather tepid. The main problem is getting people to use the wiki in the first place, as they seem to have no idea what to actually use it for. So as of now, I'm pretty much the only one actively using it. I've made some efforts to improve this situation, but as an intern I'm hardly in the position to push for adoption or even to provide incentives. == Sneaky Initiation == The team is in urgent need of a more-effective way to share documents (mostly Word, Excel and PowerPoint files). Now, before you cry out "wiki is not a document management system", rest assured that I'm well aware of that, so please bear with me. The current method is to just dump the files somewhere on the central file server, either announcing their location via e-mail or simply hoping others will find them eventually. (There is supposed to a certain folder structure and versioning system, but few people seem to care about that.) This results in frequent confusion about where to find the desired files. But there's also the question of which of those files is just a draft and which one's been agreed-upon by everyone involved. This is where I currently see my chance to make people more aware of the wiki and its potential: The project leader was delighted to hear that the wiki could be used for file storage - and even more so when I told him that old versions of a file could be retained, providing an automated versioning system. In addition, each file can be commented, discussed and categorized via the corresponding wiki page. While this certainly falls short of the capabilities of a full-fledged DMS (e.g. access control, indexing uploaded documents for full-text search*, integrated workflow management etc.), it's definitely a lot better than what's currently being used. * though that might change in the not-too-distant future; see the thread on "Storing or Linking Documents" == Exposure == As a result of using the wiki as DMS, everyone on the team will be exposed to the wiki on a regular basis. By commenting the files being uploaded and discussing them in the wiki, they will also make their first baby steps in using wiki markup. I will closely watch all changes to improve the file descriptions (e.g. by adding simple formatting, and maybe even links to other files or relevant wiki pages), thus "leading by example". My hope is that people will gradually venture into other realms of the wiki and take a look at the actual wiki pages instead of just using the files area. Ideally, many of the documents being uploaded could end up as wiki pages themselves; users might realize that it's much easier to edit the text in the wiki directly than downloading the file, modifying it and then uploading it again... == Problems == The major problem I see at the moment is compatibility with existing tools - that is, word processors (MS Word or OOo Writer). For one, it's not always easy to move existing documents into the wiki (despite tools like Word2MediaWikiPlus). This usually requires at least some manual adjustments and thus takes some effort. Conversely, writing a long document (e.g. a manual) in the wiki pretty much demands the use of subpages to split up the contents. That, however, complicates exporting the wiki pages and combing them in a single document (DOC or PDF). (Not to mention the general issue of converting hypertext to linear documents.) Also, I am not aware of any production-ready wiki2doc (or wiki2odf) converters that would enable us to fine-tune the layout in a word processor. Also, I suspect that the lack of a GUI interface for editing might be a problem once people start actively using the wiki - but that remains to be seen. == Closing Remarks == Despite my somewhat sneaky approach, I do not intend to force the wiki on anyone. Instead, I just want them to realize its potential. If they then decide they're more comfortable with the existing tools, fair enough. After all, having the wiki linger on that server doesn't cost us a dime (it had been set up anyway for another PHP application, and MW is free software). Also, I've thought about using a different wiki engine (e.g. MoinMoin) to have an integrated GUI (WYSIWYG/M) editor and Acess Control Lists. However, it's hard to resist MediaWiki's features as well as its active developer community (including extension developers). Also, it's ties to Wikipedia make it somewhat familiar even to many non-geeks, which might ease adoption. In case you've actually made it as far as down here: Apologies for the long posting - it just ended up being way more complex than I had originally intended... -- F.

I run a private extranet MediaWiki wiki which has been used on and off inside my IT consulting and contracting company, Taos, Inc. We've just replaced it with an integrated extranet website (with message-based discussion forums and document management and a bunch of other extranet functions), but I'm trying to keep active in looking for opportunities to use MW and similar tech for customer IT documentation and intranet services. -george william herbert george.herbert(a)gmail.com