Internal wiki for Information Access Group

Summary:

• I led the Documentation Working Group to plan and implement a new internal wiki for sharing knowledge at the Information Access Group.
• We researched open-source options available and settled on MediaWiki.
• We created draft content within a small working group before opening it up to the wider team.
• I did research about wiki best practices and became a big proponent for sharing knowledge in an asynchronous way.

Why I did this project, why it’s exciting

• When I started working at the Information Access Group, I was given a big 100-page staff manual. It was a big Microsoft Word document.
• At the time the company was quite small, there were under 10 full time employees. So this way of sharing knowledge was
• However there were a few issues with a big Microsoft Word document:
  • as there was a lot of information related to editorial, design and document formatting, the document became large and complicated, so it took a long time to search through the document.
  • inside a Word document, you cannot see when a certain piece of information was added, and by who, unless that information is manually recorded.

What we did

• We created a Documentation Working Group to try to find a new way to share information in a more organised way. The working group consisted of a couple of editors, a couple of designers, a project manager and a
• I led the technical implementation of the wiki, researching different open source options available. We ended up choosing to self-host an instance of MediaWiki, which is the same software that powers Wikipedia.
• I did some research into ‘the wiki way’ and best practices for managing a wiki. We had some internal discussion about how to manage approval of changes. Traditionally, if someone suggested a change to some process documentation, those changes would need to be approved by a senior team member before the rest of the team could read the documentation.
• In ‘the wiki way’, all viewers are allowed to make changes to the content, and are encouraged to do so. If you notice a typo, correct it! That way, changes can be made more efficiently, without the bottleneck of waiting for approval.
• The wiki was initially slow to gain traction from the rest of the wider team. When the wiki was launched to the wider team, it felt like everyone was too busy to use it. I was a bit disappointed, after
• But over time, specific members within the team became ‘champions’ for the wiki. When team members would share a tip or an update in a meeting or an instant message, those champions would ask the team member to put the information on the wiki. This way, the wiki became the main source of truth for how we share internal knowledge.

Sharing video resources

• When the COVID-19 pandemic hit in 2020, we needed to pivot to working remotely. This was quite disruptive for our team.
• As a way to efficiently share tips and tricks and document how to do things, I got into the habit of recording short videos and sharing them on the wiki.
• This is how I did it:
  • I would start a Zoom meeting by myself, and then share my screen.
  • I would hit ‘record’ and then talk through what I was doing.
  • When I hit ‘end meeting’, Zoom would export a video with my face in the corner.
  • I would upload this video to our shared YouTube channel and change the ‘visibility’ to ‘unlisted’.
  • I would embed the YouTube video into a new page on MediaWiki. We use the YouTube extension for MediaWiki to embed videos into the pages.
  • I would write a bullet list summary of the video below the video in the wiki page. That way, the videos would be easier to find using text search.
• Sharing little videos became a really good way to share knowledge, document processes and share tips and tricks. I much prefer it to booking in a meeting, where people may be unable to join, or unable to engage with the information because they are too busy. I’m a big fan of asynchronous communication.