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.
Possibly related posts:
]]>
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 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!
Possibly related posts:
]]>
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!
Possibly related posts:
]]>
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.
Possibly related posts:
]]>
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.
Possibly related posts:
]]>
Chris, the Digital Pioneer, asked in the comments (and on his – I assume Chris is a he! – own blog) for some advice how how wikis can be used to throw some rough notes up and invite people to collaborate and share knowledge and experience to develop them into more coherent documents.
Much of this stuff is standard across any kind of online community, and I don’t claim to be very original in any of this. However, for what it’s worth, here are my thoughts:
1. Identify who might be interested
There’s no way you will pinpoint every person who might be interested in what you are collaborating on. However, you should be able to spot the people you are aware of who will definitely get things going. This might be because they have a track record of getting involved on this issue, or that they know their way around these kinds of processes. Either way, they are useful people to have around.
Reach out to these guys and let them know what you are planning to do. Keep the specifics around the tech side of things vague, but recommend they encourage others to get in touch, so you can use other people’s networks to create a bigger list of initial collaborators.
Also find out at this stage roughly what level of tech-savvyness there is among this initial gang. Find out how they like to communicate – do they prefer email, discussion forums, or are they happy getting their hands dirty with a wiki? This will help inform which platforms you choose.
2. Put a platform together
Bearing in mind what you found out in step 1, decide at this stage what wiki system you want to use. The fundamental factor is to keep things as simple as you possibly can. Other issues include whether you want to host it yourself or are happy for the content to be sat on someone else’s server, and whether you need to restrict access. On the first point, by and large hosted wikis are far easier to use and more functionally rich than those which you manage yourself. On the second, make it as open as possible, so that there are few barriers for people to get involved.
I am a particular fan of Wikispaces, because they are quick, easy to use, and can allow you to have your own space to create as many wikis as you like under your own banner, each with their own access privileges. The other cool thing about Wikispaces is that each wiki page has a discussion forum attached to it, allowing for threaded discussion about the content on that page – ideal for those who don’t feel comfortable about editing pages themselves but who nevertheless would like to suggest a change. The cost for Wikispaces goes from free to £4,000 a year, depending on what you are after.
Other hosted options include pbWiki, Stikipad (see comments), Wetpaint and Wikia. Most offer, like Wikispaces, different levels of customisation for different prices.
MediaWiki – the platform that Wikipedia, amongst many other wikis, runs on – is probably the best of the free self-hosted options. It lacks Wikispaces’ easy wysiwyg editing, and the talk pages for each entry aren’t as easy to manage either. It is however easy to set up and open source. Other self hosted options include the free PMWiki or the paid-for SocialText or Confluence.
3. Get the content on the wiki
This, depending on your starting point, can be a quick or a very labour-intensive job. Copying and pasting text from other documents is fine, but when it is from (say) a PDF some cleaning of the formatting is likely to be necessary. Make sure you factor the time in to get this done.
Don’t forget your users when adding content to the pages. Consider adding some consistent header text to the top of each page, explaining what the content is, how it can be edited or discussed, and how the wiki administrators can be contacted for help, etc. Ensure that you take into account what people told you at stage 1. If people say they like to respond by email, make sure there is an email address they can send comments to, and a process for getting those comments onto the wiki.
Ensure that the navigation for the wiki makes sense and that people will be able to find the bits they are interested in easily. Test it out on some of your initial group to get their thoughts. Maybe find a complete web-novice in your organisation to take a look and see how they get on with it.
4. Set the rules of engagement
Having rules is boring, but a lot of people like them. Part of this will come into the page heading text I mentioned in step 3, but it is probably worth explaining again on a separate page. Make it explicit who should have view and edit rights to the content and also how vandals will be dealt with.
It might also be worth explaining exactly what will happen to people’s content that they add, who it ‘belongs’ to and under what licence it is published online. These things shouldn’t matter to most people, but those that do care do so loudly.
It probably is also a nice idea to explain what the aim of the whole exercise is – what is the eventual output likely to look like? And how will those who have collaborated on it be credited?
5. Invite and manage contributions
Now invite your initial group to come onto the wiki en-masse to start collaborating on the content. Keep it to this gang as much as you can to start off with. Any problems in the structure of the site or the way content is made available will soon be spotted and fixed.
Other things will be bound to go wrong at some point. People will accidentally delete entire pages of content, for example, and panic about what to do about it. Make sure you and your team are keeping a constant online presence to monitor what’s happening so you can react quickly to a) calm down the person who has just ballsed things up and b) put things right so the project retains at least a veneer of professionalism.
6. Market it
To get people involved beyond your core group of volunteers, you need to get eyeballs. Post to relevant forums, blogs and mailing lists about what you are doing. Telephone other contacts and get them to sign up. Stick a link to the wiki in your email signature. Mention it in every letter you write.
Don’t forget that you are asking people to give up their time to help you out for nothing in return other than the kudos of actually being asked for their opinions. Some will jump at the chance, others will need more persuading.
7. Get everyone in a room
At the very least, have a party at the end of the exercise to thank everyone. But even better, have one towards the beginning too. Even online networking fanboys like me appreciate that to get trust in a community, you have to meet one another face to face first. OK, you don’t have to, but it really does help.
Maybe you could have a wiki day – a big room with lots of laptops, wifi, flipcharts and post-its, where everyone does their best to get as many quality edits done as they can, chatting to each other and developing ideas in real life. Plenty of coffee and sandwiches would probably help too.
8. Chilax
Involvement in any activity like this one will involve the acceptance of a significant loss of control and messiness in the way things develop. This is good, don’t try and fight it.
Do moderate offensive or stupid content – that does no-one any favours. But if things are developing in a direction you didn’t expect, or don’t like, let it. Have a conversation about it. Examine your own preconceptions and assumptions and see if things can be worked out another way. But don’t go round reverting pages because you don’t agree with them.
9. Get the output sorted
Finally, make sure there is a recognised output at the end. Hopefully this could be some sort of document that people who like documents can read. Make sure it is full of links back to the wiki so that people can see who developed what idea, and how that idea changed from the original.
Make sure that a description of the process is included in the final document, and that everyone who contributed is credited. Go back to those forums, blogs and mailing lists that you punted the idea around on and let them all know how it finished. Make a fuss about the fact that this stuff works!
10. There is no tenth point
Sorry
Possibly related posts:
]]>
Interesting stuff going on at the Foreign and Commonwealth Office, with a wiki being built by Ben Hammersley using MediaWiki with a bit of skinning and the addition of a few plugins, like that which adds social network type features to the wiki.
It’s a nice piece of work, though I have personal reservations about MediaWiki as a collaboration platform, rather than just community-publishing content. But then it’s free as in beer and speech, and very quick to deploy.
Let’s hope that this wiki experiment isn’t vandalised to death like the last one that a department headed by David Miliband experienced.
In other wiki news, I have been taking a look at the white-label services offered by wiki-hosts Wikispaces today. For £500 a year, you can have as many wikis as you like running off subdomains of a web address of your choice. Each can have it’s own access criteria, and with the rich and easy to use functionality of Wikispaces, it’s an absolute bargain.
Possibly related posts:
]]>
Huzzah! Google Sites has finally been added to my Google Apps account, which means I can start playing. I’ve created a test wiki here, whicha anyone can view, but if you want to have a go at editing it, you’ll need an account. Just mail me to get one (er, if I know who you are).
Overall, it’s pretty great. Dead easy to use, lovely interface, plenty of customisation options. You can have multiple wikis, all with different designs. Pages within wikis can be standard text and image affairs, or you can use one of the presupplied templates:
- Dashboard – let’s you create an iGoogle style page with loads of widgets and RSS feeds etc
- Lists – let’s you create to-do lists, issue trackers etc. There are a few templates for these, or just create your own
- Announcements – effectively a blog within the wiki. Very nicely done
- File cabinet – upload and share files. Easy to use – just a shame that files can’t be directly loads into Google Docs, you have to download them
The widgets and stuff can be embedded in any standard page as well, though. Essentially, if it’s available on iGoogle, you can have it on Google Sites.
Google doesn’t mentioned the word ‘wiki’ anywhere on Google Sites though, maybe because it scares people off, but possibly also because there are some decidedly un-wiki things about Sites, not least the fact that I can’t seem to be able to compare versions of pages, nor roll-back to previous ones. Also, you can’t create a new page just by linking to it, which is a bit poo.
These minor niggles apart, Google Sites is really rather good. It completes the circle of applications that might be needed by a small organisation to communicate and collaborate within Google Apps. It’s very professional looking, and is much, much better than Sharepoint. Seriously.
Possibly related posts:
]]>
You can now make your MediaWiki running wiki have social networking features, too, as reported by Wikia head honcho Jimmy Wales:
Today at Wikia we have released our social networking features for MediaWiki under the GNU GPL 2.0. The best place to see this running live is at Halopedia, our Halo site.
I am excited about all the stuff going on in this space. With google’s open social initiative, our work in social search and social networking for mediawiki, I think the whole wiki/free culture space is about to get a whole lot more interesting.
Cool. Will have to track down where I can get this from and have a play. Might be useful for GovHack?
Edit: I can’t find it anywhere. Help?
Possibly related posts:
]]>
Finally Google has finished making the JotSpot wiki service their own, and have relaunched it as Google Sites. This is great news, as a wiki solution is something that has been sorely missing from Google’s line-up of services for some time.
This is TechCrunch’s take on it:
Google Sites looks absolutely nothing like Jotspot, other than the fact that both are hosted wikis. All of the structured data templates launched by Jotspot in July 2006 have been stripped out. Users now have a choice between just five basic templates – a standard wiki, a dashboard where google gadgets can be embedded, a blog-like template for announcements, a file cabinet for file uploads, and a page for lists of items. Instead of creating structured templates, users will now simply embed spreadsheets, presentations and word documents from Google Docs, as well as Google Calendars, YouTube Videos and Picasa Albums.
Here’s a video from Google explaining a bit about it all:
[youtube:http://www.youtube.com/watch?v=X_KnC2EIS5w]
At the moment though it looks like it is only available to people who use the Google Apps service, where you can have white label versions of various Google services with your own domain and branding. So you can’t start a Google Site wiki with your standard Google account, I don’t think.
I use Google Apps to handle my email and calendar and stuff, and will be implementing a Google Site as soon as it appears on my dashboard, and will make it available for people to have a play.
That’s my weekend sorted, then.