Getting developers to use a wiki [closed]

Answer 1

If the developers still need to maintain 'real' documentation (s.a. Word documents), I see no way to meaningfully duplicate that on a Wiki.

• It does not make sense for people to write twice
• Any duplicated data is prone to get out of sync, soon.

What my current customer has done is move all this to Wiki. So I only document once, and I do it on the Wiki.

This is okay. Working with Wiki is more tedious than with Word, but at least the doc is online and others can mix-and-match with it.

Another working solution (imho) would be to store docs alongside the source, on subversion. But then the merging system needs to be able to cope with rich text etc. as well. I don't know, if any solution for that exists (other than using HTML or LaTex, which actually would not be bad picks).

Answer 2

As I mentioned before, a Wiki is very unorganized.

However, if that is the only argument from your developers, then invest some effort to create a simple index page and keep it updated (either do it yourself or ask people to link their contributions to the index). That way, the Wiki might grow into a very nice and quite comprehensive collection of documentation for all your work.

Answer 3

Some tips:

Any time someone sends information by email that really should be in a wiki, make a page for that topic and add what they put in the email. Then reply "Thanks for that info, I've put it into the wiki here so that it's easier to find in the future."

Likewise, if you have information you need to share that should be in the wiki, put it there and just send an email with a link to it, rather than email people.

When you ask people for information, phrase it so that putting such documentation in the wiki should be considered the default or standard: "I searched in the wiki but I couldn't find it. Have you put that info up there yet?"

If you are the "wiki champion", make sure other people know how to use it, e.g. "Did I go through how to create a new page with you yet?"

Edit the sidebar to make sure it is relevant to your work.

Use "nav box" style templates on related pages for easier navigation.

Put something like {{Special:NewPages/5}} on the front page, or recent changes, so that people can see the activity.

Take a peek at Recent changes every few days or week, and if you notice someone adding information without being prodded, send them an email or drop by and give them a little compliment.

Answer 4

You can't force developers to do something they do not have an incentive of using for; unfortunately wikis, like documentation (well, in fact wikis are documentation) rarely have any "cool" value for developers. Besides, they're already deep into dev work -- could you really bother them with a wiki?

That being said, the people who pushed for the wiki (e.g., you) should be primarily responsible for updating it, and you really would have a lot of work cut out for you if you're serious about it.

You might also try the ff:

• It's not very structured you say -- a lot of people get turned off from ill-structured (hard-to-search/browse) wikis. So maybe you can fix that first
• Maybe you can ask lead developers/project managers to populate it with things that are issues for them: things like code conventions and API design for your particular project
• Lead by example: religiously document your part of the system. Setting a precedent may encourage others to do the same

Answer 5

I have done some selling and even run some training sessions. I think some people are turned off by the lack of WYSIWYG editing and ability to paste formatted text from Word or Outlook. I know there are some tools to work around these, but they are still barriers.

There are some areas where the wiki is being used to log certain areas, but people who update those are not doing anything else with it.

I will use the wiki to document my specialised area regardless as it acts as a convenient brain extension. When starting a new development I use it as a notepad for ideas that I can expand on as it progresses.

It would help if management would give it some vocal support, even if it is not made mandatory.

Answer 6

I have a hard job getting people to actually use it, let alone contribute.

One of the easiest ways to get people to contribute to a wiki, is to actually have them provide contents in a wiki-suitable fashion, i.e. so that whatever they post using their usual channels of communications (newsgroups, mailing lists, forums, issue trackers, chat), is basically suitable for inclusion on the wiki.

So that others (users/volunteers) can simply take such contents and put them on the wiki.

This sounds more complicated than it really is, it's mostly about generalizing questions and answers, so that they are not necessarily part of a conversation, but can be comprehensible, meaningful and useful in a standalone fashion.

For example a question like the following:

how do I get git to clone a remote repository???

Can be answered like this:

Hello, Just use git clone git://...

But questions can also be answered in a less personal style:

In order to clone a git repository, you will want to use the clone parameter to git: git clone git://....

What I am trying to say is that most discussions in a project can and should be easily used to become documentation eventually. With this sort of mindset, your documentation can actually grow rather rapidly. You only need to get people to keep in mind that useful information should be ideally provided in a fashion that is suitable for wiki inclusion.

I have witnessed several instances where open source projects started to use this approach to some extent and while some people (largely new users) complained that answers were not very personal, the body of documentation was increasing steadily, because other people simply monitored such discussions and started to copy/paste such responses to the wiki.

Basically, this is one of the easiest ways to get people to contribute to a wiki, without requiring them to actually use it themselves, the only thing that's required of them is a shift in thinking.