How to run a wikithon

We all know about the traditional lifecycle of Wikis. They start with a blaze of publicity, attract a dozen or so pages, then activity fades inexorably away. It doesn’t have to be like this! Try starting with a wikithon

Euro stem cell wikithon, image from wikimedia commons
The Wikithon is a piece of process that can be introduced into your Knowledge Management Framework in order to help with creation of a wiki-based knowledge resource. We know that Knowledge Management needs process as well as technology (as well as roles, as well as governance) and many wikis fail through lack of process. Without a process, they remain as empty pages waiting to be filled.

Enter the Wikithon

What is a Wikithon?

The name “Wikithon” is based on the term “hackathon” (an event in which computer programmers and others collaborate intensively on software projects). So by analogy, a Wikithon is an event in which content owners, community of practice members and others collaborate intensively on creating wiki content. Wikipedia call this an “editathon”.

A Wikithon is therefore a special event for creating and editing Wiki content, which may last from a couple of hours to a day or more. The event may be co-located or it may be virtual. As a side benefit, the Wikithon often introduces many new people to the concept of the wiki.

Example Wikithons

There are many Wikithon examples in the public sector, for example the Women in STEM wikithon (one of a series held to increase the representation of women’s content in Wikipedia), the annual wikithons at Colombia University to create the content for the WikiCU, or the Wikithon for creating the Making Mobile Gov Wiki, held in a coffee shop in Washington, shown in the video below.

In the private sector, ConocoPhillips has had great success with Wikithons, each of which may create up to 100 pages of new content for the company Wiki.

How to run a Wikithon

You can find advice on wikithons from Wikipedia, some of which is incorporated in teh guidance below. 
  • Agree the topic and scope. Which wiki content do you want to focus on?  It works best if each Wikithon focuses on a small number of defined topics, to give business focus to the event.  The sponsor is likely to be the owner of that topic, perhaps the relevant Community of Practice leader.
  • Decide goals for the event. Do you want to complete the content for a topic? For several topics? Or do you only want to “get started”?
  • Determine the logistics – the date, the time, the number of people expected, the logistics needed in terms of internet access
  • Decide on venues. Even if the wikithon is global, it is good to provide large rooms in your major sites where people can gather to collaborate. Make sure there is excellent connectivity from these sites to the network. Provide computers if necessary, or insist everyone brings a laptop
  • Recruit some experienced wiki editors to provide guidance and coaching
  • Order in some food and other refreshments
  • Advertise the event. Advertise within the community of practice, use your local KM champions to help drum up support, and seek to involve as many people as possible who are working on the topic in question.
  • Provide a way for people to sign up to the event, so you have some idea of the number of people who will turn up physically ( as well as those who will turn up virtually).
  • On the day, try to mix new and experienced users. Have at least one – preferably several – experienced wiki users at each physical site. Make sure new users know where to go to for help
  • Welcome people to the event, share the goals and the scope. Do a round of introductions.
  • Demonstrate how to find the wiki, and how to edit. Explain the “rules of the game”
  • Provide a “sandbox” area for new people to experiment with
  • Have a chat area where online attendees can interact
  • Ask people to bring existing material on their laptops
  • Keep a list of “work that needs to be done” and cross it off as the event progresses
  • Order in some food and other refreshments
  • Make it fun – use prizes, awards, stickers
  • Take photos
  • Hand out t-shirts
  • Afterwards, thank everyone who attended, and summarise all that was achieved on the day.

View Original Source ( Here.

The "Designing Buildings" wiki

The “Designing Buildings” wiki is a nice example of managed industry knowledge

The Designing Buildings Wiki, pictured below and explained above, is a wiki for the construction industry.

It is active – with 5 million users, 14 million page views per year, and plenty of new edits and content added in the last few days. It’s 7500 articles cover topics such as project planning, project activities, legislation and standards and industry context, It also contains overviews of iconic buildings such as Number 10 Downing Street, the White House, the Palm Atlantis and the Bank of China Tower.

It looks like it uses MediaWiki technology, and is edited by Designing Buildings limited.  It has useful features such as a “related articles” box, and a “featured articles” section. It even contains a section on Knowledge Management in construction.

This is a really good showcase for the power of wikis

View Original Source ( Here.

4 myths of the Enterprise wiki

An article from 2009 gives us 3 reasons why wikis are not the easy route to KM that many believe. I have added a fourth

This comes from an article in pcworld based on a interview with Danish Analyst Dorthe Jespersen. Dorthe’s believes that the organisational culture can be a real barrier to the adoption of wikis, and the idea that wikis will allow knowledge to spontaneoulsy emerge, as on Wikipedia, is unfounded.

Her three myths are as follows

 Myth One: Wikis will motivate employees to contribute content. 
 Jespersen describes the “Empty wiki syndrome,” or when a wiki is deployed without a clear purpose or is too general in its focus, resulting in a site with almost no activity. It helps, said Jespersen, to appoint someone to manage the wiki, ensure there is structure like guidelines and a basic information architecture, and that it is launched with content already posted because “it’s very hard to just react to this empty space for the user.”

 Myth Two: Employees know how to contribute. 
 The concept of a wiki may be simple, but contributing content is not necessarily logical for casual users. Jespersen said some organizations prefer to refer to existing written policies around content creation that say, for instance, employees are responsible for the content they produce. But policies can be tricky considering the goal is to strike a balance between governance and structure and flexibility. Some wiki-specific policies might include guidelines around creating pages that are easy to read by having a table of contents if the page is long, or having a naming system for links to ensure consistency. 

 Myth Three: Wikis will always provide the information employees need. 
 Although searchability is often a selling point of wikis, Jespersen said the reality is wikis are difficult to search through, unlike a content management system. Given there is little structure built into wikis, “it is difficult to structure this information to make it findable the next day even.” Content on a wiki can grow faster than the organization can keep up, she said, therefore the wiki managers must perform regular searches and quality checks of the content. Overall, Jespersen suggested starting with a pilot so that the true purpose and scope of the wiki can be first ascertained before an enterprise-wide launch.

Underlying all of this is a fourth myth, which is still prevalent, and which I feel should be added to the list:

Myth Four: Wikipedia is a good model for in-house Wikis

Wikipedia is the archetypal bottom-up Wiki, drawing on the wisdom of the crowds, and is often taken as a model of bottom-up voluntary free-form knowledge sharing. However it is a poor model, for several reasons:

  1. Wikipedia is successful because it draws on a huge crowd – the population of the globe. even though the percetnage of Wiki contributors compared to teh global population is tiny, that doesnt matter because the global population is so large. A similat tiny percentage in an organisation would mean that a very small number of contributors provided the bulk of the content.
  2. That tiny percentage of Wikipedia contributors is a skewed population.  Wikipedia contributors are 80-90% male, more than 65 percent single, more than 85 percent without children, around 70 percent under the age of 30. This is the wisdomn of a subset of the crowd. You do not want this skewed viewpoint in an organisation. 
  3.  Editing wikipedia is not a case of “everyone writes what they like”. There is usually editorial overview or moderation of most pages other then the fairly niche ones. A similar form of editorial oversight is needed in organisations as well.
  4. If you want more advice, see NASA’s 6 wiki rules
  5. This video….

View Original Source ( Here.

Knowledge Assets – the "Knowledge First" format

The way we write reports, especially scientific reports, is not the way we should write Knowledge Assets in a Wiki.

Image from MaxPixel

I am consulting with a firm which is moving much of its current knowledge into wiki format, on order to take it out of the document library and to turn it into a resource that is in the public domain, searchable, hyperlinked, and constantly updated.

The problem is that many of the knowledge owners are scientists, and their default knowledge format is very much based on scientific reports. Many of their first-attempt wiki pages are composed as follows:
  • List of projects:
    • Project title
    • Project outline
    • Project objectives
    • Project results
    • Project conclusions
The conclusions are where the knowledge is found, and presenting it in this way means that the reader must scroll to the bottom of the page every time to find the knowledge, and that the reader must read every project to get a full picture. Also the knowledge is not updateable, as it is linkedin every case to a project.
We are now moving the content into a “Knowledge First” structure, as follows:
  • Here is what we currently know about this topic (knowledge summary or conclusions);
  • This knowledge is based on the following projects:
    • Link to first project, with full details;
    • Link to second project, with full details etc;
  • Here are the things we still don’t know, abut are trying to find out.
The links to projects could be hyperlinks to sections further down the page, to separate project summary pages, or even to the project reports in the document management system.

This less like the way knowledge is presented in scientific reports, and more like the way it is presented in newspapers; starting with the headline, then the introductory paragraph which summarises the whole story, and then “read on for more detail”. It is a reader-driven format, aiming to give the reader what they need to know in the most efficient way.

By presenting the material in this way, the reader can find the knowledge quickly, and then zoom in to the level of knowledge they need.  Also any update to the knowledge happens at the top of the page, in clear view, and any old, invalid conclusions can be overwritten.

Format your knowledge assets and wiki pages with the user in mind, and think “Newspaper format” rather then “Scientific Report”.

View Original Source Here.