Setting up and using wikis @ ILRI

Setting up wikis

We use www.wikispaces.com to collaborate online, either to support the documentation of events or to keep track of collective work. Usually, the social media coordinator (currently Tsehay Gashaw) or anyone else with the credentials for the ILRI Comms account creates wikis and sets them up (layouts, default options etc.) so please do not create wikis without first consulting Tsehay Gashaw (t.gashaw@cgiar.org) or Peter Ballantyne.

Using wikis to work collaboratively on projects/programs and collective initiatives
As explained on this very simple video tutorial, wikis are meant to help people collaborate without the problems of endless email strings and difficulties to find the latest version. They can be really powerful tools for projects/programs and collective initiatives. Ensure the management of the program (or the team using the wiki) agrees with using this wiki and set it up. Different wiki set-ups are possible with more or less control on page privacy and roles etc. Once you have set up the wiki (with an easy name) - ideally having consulted the people concerned (and expected to use this wiki later) - you may think about the following steps:

Create content / sections

Every wiki will be different, following the specific needs of a given initiative. However, typical wiki sections for a new wiki might entail:
  • About (mirroring content on the initiative's website);
  • Key contacts (a page with all the key people and their contact details);
  • Outputs and publications (possibly with a self-generated RSS feed menu displaying the latest at all times);
  • List of events, possibly also a link to a Google Calendar to display the most crucial events;
  • Communication channels and tools (showing the overview of all platforms used in the initiative) - this should certainly include the logos, templates etc. that the people involved will need later;
  • Specific thematic or geographic sections, as you see fit.
Note that all important pages should be reflected in the navigation menu on the left hand side, which only administrators can edit (and should continually edit to reflect the changing nature and content priorities of the initiative)

Inform and involve staff

You may want to:
  • Introduce the general logic of the wiki and what people may expect to find there;
  • Try and find 'champions' that, individually or in teams, agree to take care of keeping the content of specific sections up-to-date;
  • Train them on wikispaces.com to show them how basic editing works - and possibly more advanced functions for 'power users';
  • Explain to them how to get notifications on specific pages of interest to them;
  • Regularly mention the wiki to keep it on the radar of the people involved in the initiative;

Fuel and further develop the wiki until its end

The most difficult part is to keep the wiki up-to-date. These steps might help:
  • Link to and from the wiki, with the website, Yammer, CG Space, FlickR, Slideshare and any other online page or collection that might be relevant;
  • Use events as key moments to use the wiki to document conversations (see section below);
  • Rely on your 'content champions' to keep updating their pages and ask them if they need help/clarifications on a regular basis;
  • Provide regular 'refresher' training on using/editing wiki pages for your regular team and new people joining in;
  • Provide stats about the usage of the wiki (only wiki administrators have access to stats though) to show that people are accessing the wiki and editing it;
  • Occasionally organize a big 'clean-up' to re-structure the wiki and to update specific pages;
  • When the initiative ends, you may keep the wiki up and running, but you might want to update the pages in a way that reflects the end of the program (so no visitor gets the wrong idea that that initiative is still happening).

See a couple of examples:

Using wikis to document events

Before the event - preparing the wiki:

  • Set up a page for the event. On that page:
    • Add the objectives and possible outcomes/outputs expected from the event.
    • Create links for:
      • The agenda
      • The list of participants
      • If relevant, logistical information
  • List the event in the wiki menu and/or appropriate places on the wiki to keep track of events (e.g. as the list of events as on this wiki) so that visitors can see this event as part of a wider list of events.
  • For each page created, use the same heading comprising:
    • The title of the event (formatted as heading 1)
    • The dates of the event i.e. Day Month Year
    • The venue of the event i.e. room/venue, location, city, country (e.g. InfoCentre break out room, ILRI Campus, Addis Ababa)
    • You may also add a link to the event home page.
    • You may also use colours to differentiate headings or sections.
    • If you create multiple pages (e.g. for the different days of the events or the different sessions), always use a consistent naming logic. E.g. if you event name page is 'NBDC_planning_May2012', you can use 'NBDC_planning_May2012_agenda' for the agenda page, 'NBDC_planning_May2012_session1' for the first session etc. It is important to use these headings consistently to help visitors 'situate' the content in the context of the event (they may land on this page from a search engine and need to understand where they land). And please avoid blanks in the URL, rather use underscore ('_').
  • If you organize various events or similar pages, you might want to create a 'template' rather than a simple wiki page. Once you have created and saved that template, every time you create a new page, you have the option to use that template (or to create the page from scratch). See this template for events on the Africa RISING wiki.

See an example.

On the documentation job:


When documenting an event, here are important steps to follow:
  • Meet with the facilitator and/or event organizer to understand clearly the objectives of the workshop, the theme and keywords of the event, possibly important acronyms etc. Take advantage of this meeting to also decide if one or two documenters are required. For large meetings 2 documenters are a must but it is not always possible to guarantee it (e.g. funding).
  • Ask the facilitator to inform all participants to pay attention to the documentation by: speaking clearly, spelling acronyms, writing clearly on flipchart sheets and all outputs that are supposed to be typed up.
  • Proactively interrupt speakers when they talk about unknown acronyms or when you cannot hear what they are saying because they don't speak loud enough.
  • If you don't understand the content of what they are saying, capture what you can but do not interrupt them, rather check it with the event organizer or the facilitator afterwards.
  • When taking notes, if you miss some bits of what people are saying, underline those bits so it is easier to come back to these gaps and fill them later.
  • Organize a short after action review with the event organizer and/or facilitator at the end of every day to review the gaps in your notes.
  • Use an audio recorder to help the note-taking and fill some of the gaps.
  • At the end of the event, before the link to the wiki is shared with all participants, ask the event organizer (and the facilitator) to review the full set of minutes and to add details.
  • As much as possible, take notes on one page only (multiplying pages for all days or sessions increases the risk of link errors and makes it more difficult to keep track of all the contents on the wiki over time).
  • Use headings systematically (heading 1 for days, heading 2 for sessions, heading 3 for session sub-items) and generate a table of contents (possible in the 'widget' menu when editing a page).
  • If possible, synthesise wiki notes (per day or per session) to make the contents of your documentation more digestible.
  • If possible, ask the facilitator to add 'process information' (how the session was run) in italics before the content notes, so that viewers understand how the content was generated.

After the event:

  • Review the notes (see above).
  • Make sure that all materials collected during the event are available on the wiki event page (home page or agenda page, as you see fit and as you have structured the note-taking).
  • Make sure you replace all the links to presentations (that were uploaded on the wiki) with the links to those same presentations on Slideshare.
  • On the home page of the event you may add a link to specific 'outputs' or 'next steps' of that event, or to the pictures and/or videos taken.
  • On the home page of the event you may add a picture about the group of participants, or another picture, or a slideshow (embedding the original FlickR set). All these pictures should be linked from the appropriate FlickR collection (where pictures have been uploaded).
  • Share the link with the cleaned up wiki pages with participants in ways that you see fit, for them to keep a record of these.
  • If appropriate (see section above), add a summary per day or per session of the event. It is particularly useful to keep track of key insights/discussion points and key decisions, and to specify these for specific (e.g. thematic or geographic) groups. See this example of the summary of the Africa RISING learning event 2013 here.