Editing Wikipedia

I’ve been asked this question a few times recently, so thought it worth sharing my answer with everyone that reads this blog:

What’s the best way to approach editing Wikipedia articles about us?

There are a number of reasons why you might want to do this – the most obvious being that there are some factual inaccuracies that you want to correct – though sometimes there are other reasons too.

There have been several high profile incidents where Wikipedia has been edited – by either the individual who is the subject of the article or by an employee of an organisation with a page on the site – with various degrees of success or humiliation. Here’s my guide to getting more of the former and less of the latter.

My instinctive reaction is: don’t do it. Editing Wikipedia is a minefield and getting it right will take up an awful lot of time. Think about another way around it – could you publish a list of corrections on your own website, or on a blog? Perhaps encourage someone else who reads it to make the corrections, but leave Wikipedia itself well alone.

If you are determined to get involved, here’s what to do. Firstly, do not edit anonymously but create an account on the site. This is for the very good reason that your edits will not be anonymous anyway – your IP address will be recorded and if you are using a work computer, people will easily be able to find out where you are.

Instead, give yourself a username that’s understandable, not some random pseudonym. Then, open your personal user page and edit it to explain exactly who you are and who you work for. What you are aiming for is complete transparency – the last thing you want is people thinking that you are being sneaky.

Once that’s all done, it’s time to edit the entry itself. Or, rather, not – because my advice would be not to edit the text of the article itself first of all. Instead, I’d limit my edits to the article’s talk page initially. Explain in the page the inaccuracies, and perhaps link to the web page I mentioned earlier with a list of corrections. Then let the community do its work – some corrections will be made to the page – maybe all of them. What you are doing is giving the Wikipedians the facts, and allowing them to put their own house in order.

If that doesn’t happen, or if there is an urgent correction that needs making, then edit the text itself. Firstly, make the change, ensuring that you clearly link back to sources to back up your edits – and make sure you use the edit summary box to explain what you have done and why. Then, drop by the article’s talk page and again explain who you are, what change you made and why you did it.

Once all that is done, sign up to get email alerts when the page is changed so you can keep on top of what further edits people are making.

If you find that someone just goes in right away and reverts – that is, removes your edits and restores the page to how it looked before you started – do not get tempted into reverting their reversion! These tit-for-tat “edit wars” do nobody any good! Instead, try and engage with the person making the reversion, again through the article’s talk page, or on that user’s own page maybe. Most Wikipedipedians are friendly, conciliatory folk and you should be able to talk them into being more reasonable.

Of course, if that fails, there is always the Wikipedia arbitration process. Good luck with that.

For more on Wikipedia culture, I found Andrew Lih‘s book The Wikipedia Revolution pretty good. Lih is clearly a fan of Wikipedia, so it is hardly an unbiased account, but there is some really useful background in there.

Open source gov

Last week, the Cabinet Office published a new action plan for government and open source, to level the playing field when it comes to procuring software.

So we consider that the time is now right to build on our record of fairness and achievement and to take further positive action to ensure that Open Source products are fully and fairly considered throughout government IT; to ensure that we specify our requirements and publish our data in terms of Open Standards; and that we seek the same degree of flexibility in our commercial relationships with proprietary software suppliers as are inherent in the open source world.

Excellent stuff. There is a Netvibes dashboard set up to help monitor what is being said online, some of which is a little cynical and critical. I tend to prefer to be relentlessly positive.

Anyway, the situation with open source is a little similar to that of social web stuff, in that knowledge about it, and its possibilities, are somewhat limited. We need open source digital mentors!

Alternatively, we just need a wiki.

OpenSourceGov

OpenSourceGov is a simple MediaWiki site which aims to collect together all the information a civil servant might ever want to know about open source and the options it makes available. Hopefully it will soon be able to answer questions like:

  • Which licence should a government open source project be published under>
  • What is the best open source content management system to use for which purpose?
  • Where are the suppliers of open source solutions?

As well as many others.

Please do visit the wiki, and make use of the (currently limited) information on there. Even better, register for an account and add or edit some stuff you know about and share it with everyone else!

Wikipedia a bad example for enterprise wikis?

Helen Nicol writes an interesting post about how to get wikis taken up within organisations. Using Wikipedia as an example, she writes, is a bad idea, because it sets unrealistic expectations of the amount of content likely to be generated, and will also likely scare people away.

Unfortunately, many companies begin their wiki experiments by trying to create the definitive knowledge asset on, say, knowledge management. This is a big ask for people who’ve never had their own contributions edited by someone they don’t know. It turns people off, and prevents them from recognising the potential in wikis. They need to start with a simple and non-threatening activity like a progress report or lessons learned review. Even a shared agenda would help as I said in this post some time ago. Starting small will really help people gain confidence enough to start working on bigger projects like knowledge assets.

This taps into a real problem for those wishing to encourage the adoption of these tools within their organisations. Saying wikis are like Wikipedia (which they can be, but…) is a bit like describing blogs as online diaries (which they can be, but…).

As I often say, the best thing is just to start using something, with a freely available tool, whether a blog or a wiki or whatever and then use that to demonstrate what you mean to the unbelievers. Much easier than making people think they have to start recording the sum of all human knowledge, or start publishing their innermost thoughts on the web!

Contribute to DigitalMentor.org!

A few new pages have been created on the Digital Mentor wiki which are screaming out for content to be added, and it’s really easy to do so!

All you have to do to add to the wiki is click the ‘edit’ link on the relevant page, and then type in the site-wide password, which is printed on the top left of every page. No need to create an account, or think up a password to remember!

The pages that are open for contributions right now are:

  • What is a digital mentor? – Give your thoughts on what you see as being the important parts of the digital mentor role
  • Links – list where you have seen web pages and blog posts about digital mentors, or related stuff
  • Online tools – where have you seen online resources which could be used either by digital mentors, or by those mentoring the mentors?

If you don’t like using wikis, you can still contribute! Leave your thoughts in the comments here, or email them to me, and I will do the wiki bit.

Quick and easy consultation with PBwiki

I was presented with a little challenge last week at work. There was a requirement to change the information provided on various pieces of data, and to do this around 100 forms had been produced with the new information on, one for each field, and the aim was to get these forms in front of a selection of people so we could get their feedback on them.

This presented a number of challenges:

  • Emailing out all the forms to people would probably bring down the mail server, and would make it confusing for consultees to manage, and very difficult for us to organise the responses
  • Putting the forms on a network drive would undoubtedly have issues around access, and again responses would need to be emailed which would be a pain
  • Printing all the forms out multiple times would be rather wasteful, and once more collating responses would be nightmarish

So, the solution was devised to put all the forms on a wiki, one per page, and allow consultees to be able to edit the page to leave their feedback. This means that there is only one copy of each form online, and everyone reads the same one, and all the responses will be on the same page, so the collation will be done for us. Of course, the word ‘wiki’ wasn’t actually mentioned – it was just referred to as ‘a website’…

There are of course quite a few different wikis available. The short term nature of this exercise meant that a hosted solution would be best in terms of the speed at which it could be put together, and usually at this point I would be reaching straight for WikiSpaces. Instead, though, I went for PBwiki.

The main reason for this is the way people access the wiki. With WikiSpaces, consultees would have to first create an account with the site, then request to join the wiki and only once allowed in could they edit the pages. Not having any access control was out of the question. But PBwiki has a cool access restriction, which makes it possible for anyone who knows a common password to be able to edit the wiki. This was perfect to us, as we could email all the consultees with instructions and the password. Perfect.

This proves quite an interesting point – that even once you have identified the precise tool, it takes some serious consideration to decide precisely which platform you want to use. Also, while it’s good to have favourites, don’t let familiarity blind you to what other services have to offer.