Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

  1. Blog
  2. Article

Graham Morrison
on 26 February 2024

Introducing Canonical’s Open Documentation Academy


tldr; Our Open Documentation Academy starts this week with our first weekly Documentation Office Hours on Friday 1st March 2024 at 16:00 UTC. Everyone is welcome! Keep reading, or see our forum post for more details and to leave questions.

Many of us at Canonical wouldn’t be here if it wasn’t for Linux and open source. Their availability and accessibility helped so many of us to get involved, wherever we were in the world. We didn’t need to ask for permission.

Open and inclusive collaboration, and the sharing of ideas, remains the best way to develop software (and to do many other things!), but we also recognise that this “getting involved” step can be difficult. Where do you start? Who do you ask? What needs to be done?

It shouldn’t be this difficult. Open source projects should be as open to new contributors as they are to critical bug fixes, because new contributors are the next generation of critical bug fixers.

One of the problems is the lack of an established Getting involved process. At Canonical, this is something we can solve, and we want to help solve it together by inviting contributors to write documentation.

Documentation is the circulatory system for a project. New features do not exist unless they’re documented. New users don’t exist unless they know where to start, and established users won’t stay unless they know what to stay for. But these requirements are also what makes documentation challenging, and for those of us into this kind of thing, ceaselessly fascinating.

We’re in a fortunate position at Canonical because we now have a well-established team of technical authors who work across all of Canonical’s major projects, alongside a scattering of projects that haven’t even been announced yet, and we all work within a common framework called Diátaxis.

Our own backgrounds vary hugely; from academic linguists and Linux industry veterans, to IT journalists, astro-physicists, teachers, developers and support engineers. From Brazil and Bangalore to Wales and New Zealand.

We all very much want to help people become open source contributors by building an on-ramp process. It may take some time, and we will need to adapt, but this is exactly why we’ve started our Open Documentation Academy.

Thanks to the wide range of open source projects that Canonical works on, from the Ubuntu Desktop and command line tools, to security, cloud orchestration and device provisioning,   we have a fantastic opportunity to help people make meaningful contributions to technologies they’re most excited about. Documentation is the ideal place to start making contributions for several reasons:

  • it’s how you learn about a project and its governance
  • no contribution is too small, or too big
  • documentation can always be improved
  • small changes can have massive impact and benefit so many people

To help you get involved, the Open Documentation Academy provides a curated list of documentation tasks. Choose one, let us know, and get started. Tasks include testing and fixing tutorials, updating the outdated, restructuring large documents, and anything else you may want to suggest. Our list is growing, and a big part of the Documentation Academy will be ensuring there’s always a wide range of tasks available, across as many projects and technologies as possible. And of course, we’re here to help. We’ll guide you through your first contributions, provide advice on approaches, and help you build your confidence.

And it all starts this week! 

If this sounds like something you might be interested in, here’s what to do next.

Our task list is now open, and growing. Take a look, bookmark it, and see our Getting started guide for next steps.

Join our discussion forum on the Ubuntu Community Hub. Chat to us on Matrix, and follow us on Fosstodon!

If you’d like to ask us questions outside of our public forums, feel free to email us at docsacademy@canonical.com.

Join our weekly Documentation Office Hours starting at 16:00 UTC on Friday 1st March 2024. Everyone is welcome to join, and our first one will introduce you to the Open Documentation Academy. Leave your questions beneath the forum post and we’ll answer them live. We’ll publish a recording of each office hours meeting a few days later. Links and comments can be found on the forum post

Also, take a look at our official Open Documentation Academy page. It covers a few more details on what we’re trying to achieve.

Finally, subscribe to our Documentation event calendar. We’ll expand our Documentation Office Hours schedule and add other events throughout the year.

Thank you for reading, and good luck!

Related posts


Daniele Procida
3 December 2024

Documentation, development and design for technical authors

Documentation Documentation

Typically, a technical writer takes the product created by a development team, and writes the documentation that expresses the product to its users. At Canonical we take a different approach. Documentation is part of the product. It’s the responsibility of the whole team. Documentation work is led by a technical author, who is part of the ...


Bill Wear
17 March 2023

Help us build better doc

Canonical announcements Article

We want you to join our Ubuntu circle, and help us document MAAS. More minds, more eyes, more hands make better doc. ...


Teodora Mihoc
28 October 2022

Humans may be rational, or how to collect better documentation feedback with linguistic theory

People and culture Article

Anyone who has ever built a product wants user feedback – and we in open source want it more than anyone else, and place higher demands on it than anyone else. However, this feedback can be hard to give, hard to receive, and hard to act upon. My product is open source software documentation, and ...