Have you used a wiki in your project or group?

Question

The workgroup at my company is considering creating a wiki to store information that everyone may find useful. It would contain anything from tips/links on new technologies used on projects to internal procedures/guides for the servers we have set up. Has anyone had experience with this?

Right now we're mainly using Sharepoint to keep track of all the documents we have, and the two main wiki contenders are Sharepoint 07's wiki and Mediawiki. If anyone has had any specific experiences with either of those, I'd be interested in hear that as well.

Answer 1

well... we at Medicware are using TWiki with great success!

Answer 2

Sharepoint's wiki system is a-w-f-u-l. It's not a real wiki, just a series of html pages that you can edit (look how it's stored in the document library). Just inserting an image into your document is one of the most painful experiences.

Our team tried it, grew frustrated, and ditched it for mediawiki.

Answer 3

We are using our own development, but this is not the point.

It is always a good idea to have a shared knowledge base.

We have tips, tricks, checklists and standard procedures in the wiki. It helps a lot.

For example if the responsible person is not in the office and the mailing stops for some reason, we have a list to check whether this or that is working or not, do we have a connection, does the port open, and so on.

If we want to set up a new server, there is the standard procedure: ask for the install media, or ask for a new copy of a virtual machine, if we want to set up something, what are the prequisites, what can go wrong, what should be checked after installation, and so on.

You will have only one problem with the wiki: who should put in information. If you find some persons who are able to maintain it, ask for information about different areas and control the content, then you are on the right track.

Answer 4

I have mediawiki set up at my office, it's handy as a quick reference. Before we just had a plethora of .Doc files floating around the server. Most of which had two or three different versions. A working one and one or two older ones.

Now we still have a bunch of Doc files everywhere, but whenever the wiki is used, we don't need a bunch of extra versions of things as you can just permalink one specific revision.

It's slow going getting everyone to use a new system, but when it's used, it works great.

Answer 5

We use JSPWiki with good success.

Answer 6

We do have a wiki for our project group and by now (around 2 years) it does even contain several useful articles written mostly by two people of the team (myself and the guy who introduced the wiki). I think, we have a bit of an acceptance problem with the wiki.

It is quite easy to write in there once you overcome the initial hesitation and learn the basic markup commands, but for me (and most of my co-workers) the major drawback of the system is that you have no idea what is in the system. There is no master index or table of contents somewhere.

I resorted to have a look at the latest changes every now and then and try to organize stuff into categories that link related articles to each other, but other than that, there is no real order. It is just a pile of stuff and you might be lucky to find what you are looking for.

Answer 7

We're using MediaWiki. We use it to store procedural documents and stuff like that. Using a wiki makes it easy for any team member to keep things up-to-date.

As far as project documents go, we're still tending to use more traditional documentation methods, although we do have a simple intranet system in place to help make filing and navigating the documents easier than it might be.

Answer 8

I agree with HS, this is why we developed our own

There were three main criterias for the wiki:

1. WYSIWYG editor: not everybody wants to learn a new markup
2. Easy linking to existing pages: don't have to look around separately, but query by tags or searchwords
3. Table of content: several type of list with all of the content: alphabetically, by tags or by date.

Answer 9

We use ScrewTurn's Wiki. Its file based, so its real easy to manage and backup. I never had any problems with it. And ScrewTurn is the company that got Jeff's sweet, sweet advertising moolah.

Answer 10

I introduced screwturn's wiki (thanks to Jeff) inside our publicity agency to share knowledge between different teams. It works great. We even keep there lists of taks for every programmer. When they arrive in the morning, they only need to check their list to see what is awaiting them.

Answer 11

We use Screwturn for technical documentation and it works excellently.

Sharepoints wiki implementation is exceptionally limited (though I recall that there are third party wiki plugins for sharepoint) but it is functional.

Answer 12

I have been using MediaWiki recently. It is a GREAT piece of software. It is very easy to extend and add to as well as skin it to your liking. The only "problem" we have noticed is that it has a bit of a learning curve, because they did abstract out absolutely everything to the lowest level they could. This is a good thing but makes figuring out what they are doing a little difficult, of course this only matters if you are doing things in PHP behind the scenes.

I would highly recommend it. Feel free to post any questions and I will be sure to help you out, since I know it pretty well now.

Answer 13

We use a Wiki (ScrewTurn's Wiki) and I think it's a really good idea to use one.

I introduced it and since then we use for any guideline document we may want. I find it very useful to train new employees since you can just put a bunch of things to read in there and let them go for a while.

It's definitely a plus, but as HS said, it can be difficult to make people write in there at the beginning. Once the index starts growing, things will pick up by themselves, but initially, it's difficult, especially when there's is no structure.

Answer 14

You must check out DekiWiki. It's an excellent open source wiki, with a pretty extensive API, a good growing community, and lots of extensions for touching other web services.

Answer 15

We started using Mediawiki a month ago and are slowly transferring information from OneNote notebooks, shared e-mail folders and .doc files to the wiki. It is definitely better than those for sharing information.

I agree with HS, you have to find a way to make a table of contents or index - at the moment, everybody writing a new article adds a link to the main page, but this is not very scalable. Categories might work also, but require even more discipline (need to remember to add a category to every page) and in the beginning, you might not even know what categories you want.

Another possible problem is determining the author of an article or paragraph - you have to go through the change history, nobody really likes to fill in the "summary" field after editing etc.

One imported point (for me) in choosing a wiki engine is ease of editing - lots of people won't write at all if it seems just a little bit "difficult" to them. Different engines use different markup languages, we chose mediawiki partly because some of our users where used to its markup from other projects. If your writers know html, choose an engine that supports that also (mediawiki does).

As to who should put in information, we are going with "whoever uses some information belonging in the wiki and not there yet, puts it there" - which might mean writing from scratch or copying it (and hopefully updating/error-checking) from some already existing document (and possibly delete that document later to reduce clutter).

Answer 16

At my last company we had a TWiki install that worked well when the development and management teams were very small. As the company grew and split into many teams, the wiki was not being used so it was decided that we needed more features (discussion groups, use of office documents.) So Sharepoint Services were installed and each team set up their own site with all sorts of Office docs and even Sharepoint wikis (never use Sharepoint wiki -- as mentioned by an earlier post, it is awful) and now there's all sorts of orphaned, unmaintained information in all sorts of different formats that no one uses. After the first few weeks everyone stopped using Sharepoint.

I've seen this pattern of attempts at knowledge bases/collaborative documentation in many different organizations. The problem is NOT the tool, the problem is the lack of leadership and organizational culture concerning the importance of communicating for future reference as opposed to communicating ONLY for the immediate use. If senior management doesn't use the knowledge base and there are no consequences for not using it and no internally recognized benefits to using it, the knowledge base won't get used. Maybe a tool linked to other tasks might be better (e.g. the Wiki that is integrated in FogBugz?) but leadership is the key.

To summarize: - Twiki good, Sharepoint bad - you need leadership to get people and KEEP people using the Knowledge base, the tool used isn't really important so much as the leadership and culture surrounding its use.

Answer 17

I use FogBugz's wiki. It's great to have consolidated documentation, with history.

Answer 18

We use dokuwiki at work. I choose it mainly because it stored its data in text files, so if we ever changed it would be easier. The plugins available are great, we use a calendar plugin to keep track of who is out of the office. We've developed some custom tools that integrate into it as well. The only problem I have with it is the lack of community and support. It's a great product but not too many people use it, so that should be a consideration.

Answer 19

We also use TWiki and have had great success with it. The most recent version has a pretty powerful wysiwyg editor. For me the best part about TWiki are the plugins.....very extensive for most Intranet environments

Answer 20

We are just starting to employ a wiki where I work and while researching different options for wiki engines I came across the MoinMoinWiki engine, it is used by some of the big names in the Open Source community (Apache, OpenOffice, Ubuntu, etc.). One of the reasons it caught my eye was its option for the use of a much more feature-filled WYSIWYG style editor while also allowing access to the straight wiki-markup input style as found with MediaWiki.

One of the key hurdles my team found with using a centralized wiki (such as a MediaWiki installation) was the learning curve required to master any special markup languages in order to keep documentation productivity up. For us, having a rich WYSIWYG style editor is a major factor to establishing a successful documentation wiki.

Answer 21

I used MediaWiki on a previous job. The lack of participation from co-workers (both writing and checking it) made me quit the wiki. But if used correctly, it's an awesome tool. Mostly for new people integrating into current projects.

I think DokuWiki has less of a learning curve, and I am using it for a local wiki on my own pc to store stuff. I use a plugin to display an Index, it's a must.

Answer 22

I've not done much with Sharepoint, but helped instigate a Mediawiki instance at work. Like others here I seem to do 90% of the editing despite evangelising it at every opportunity. I get fed up with having to reverse engineer code to find out things that should be documented. The ability to cross-reference everything is invaluable.

I've written some scripts in Oracle PL/SQL that generate pages for our tables and some types of data to automate the documentation.

I just discovered the Wikied Greasemonkey script that adds some great editing features. One of the most important is to turn Word text into Mediawiki format. That will save me a lot of time.

Answer 23

You've had heaps of ideas on other wiki tools you could use. We're a bit in the same situation as you are - Using SharePoint and looking for a good wiki.

We've been playing with Confluence for a little while now and it's pretty darned nice. There is also a SharePoint plugin for Confluence which goes a little way to integrating them together.

At the basic level you can show a confluence page inside SharePoint. Getting more useful you can integrate the two searches so that SharePoint search will search inside Confluence, etc. We're finding this part of it really useful.

The plugin is still new but future version should improve on it.

Answer 24

We've been trying to get a Wiki going, but it won't take off the ground without a core group of avid users to bootstrap it with some useful content. Our current KM system is SharePoint and is mananged by the enterprise group. It's great for mixing wikis with other ways of displaying information that may be faster (like creating lists of information and having SharePoint build the CRUD interfaces for you).

To combat the pain of using the SharePoint rich text editor (and wiki editor), we're going to turn to Telerik RadEditor for SharePoint 2007. We haven't finished jumping through all the approval hoops, but the product seems to solve a specific problem and isn't that expensive either.

My general SharePoint experience has been positive, every time I show it to someone new, their eyes get big and they want to use it for their projects and groups too.

Answer 25

On my projects I like to use Trac - a symbiosis of Wiki and issue tracking system. Here is how they identify themselves:

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way.

I like it because it has virtually everything needed to start working on a project to start information accumulation and start managing development tasks and items priorities. Also it is highly customizable and can fit your needs with little and easy tweaking.

Answer 26

We were in a similar boat a short time ago. The SharePoint wiki leaves a lot to be desired, but we still want to use SharePoint for a whole heap of other things.

So ... we went with Atlassian Confluence. It's a great wiki (not free though) and does have a reasonably good SharePoint plugin.

The nice thing about it is that you can include Confluence pages in SharePoint and you can set up both SharePoint and Confluence to search each other. So search results includes results from both apps.

Answer 27

We are using MediaWiki, but WordPress is the new kid on the block. I know, it is not a wiki system, but it has some features that are more suitable to us:

• Better way to organize knowledge: tags, categories, pages
• A lot of themes and plugins
• So much more usable than MediaWiki (this is important to reduce resistance when adopting tools)
• some other goodies like RSS, better user management, easy installation, etc.

Kind Regards

Answer 28

My development team at work landed on DokuWiki after going through a wiki evaluation earlier this year. A few key features:

• A feature set designed for hosting of technical documentation, such as built-in code syntax highlighting with support for many languages.

• Good community support, including active support forums and many community-developed plugins.

• Easy upload & embedding onto wiki pages of images and other media.

• Can define a global set of acronyms and their definitions; these are rendered using the browser's acronym tag (so the acronym definition is displayed in a tool tip upon mouseover of the acronym). Good for helping new developers understand internal corporate acronym jargon.

• Highly portable; Apache/PHP front end, flat file storage back end. (During the evaluation, I was able to transfer a "test" DokuWiki installation that I had set up on my Windows XP dev machine to a linux server simply by doing a directory tree file copy!)

• Side-by-side "diff"-style view of differences between old versions of a page.

• Free and open source (GNU v2 license).

There's a more complete feature list available at the DokuWiki site.

Our 10-member team has been using DokuWiki for about 6 months now; we've been very happy with it so far!

Answer 29

You have to populate wiki with a lot of info before everybody starting to feel it. I fill up more than 60 thousands errorcodes in it. Now my colleagues from company's call center are very happy about it. I even make a lot of links to word documents to be downloaded. It would be nice to convert all of them to wiki. But there is just no luck to find the right tool.

Answer 30

Before diving into a wiki, you should take the time to peruse the following site:
http://www.wikipatterns.com/display/wikipatterns/Wikipatterns

It explains the social aspects of wiki adoption.

I've used Atlassian Confluence & XWiki.

1. Confluence has a vibrant plugin community and good support.
2. XWiki has the ability to structure data in the wiki ina a more discreet format and manage it through an extensible application.