As many of you will know, I manage the Ubuntu Community team at [Canonical](https://www.canonical.com/) where Daniel Holbach, Jorge Castro and David Planella work. Together we strive to make the Ubuntu community a fun, productive and engaging environment. This work involves a tremendous range of diverse disciplines and projects.

One thing that we have been really keen to facilitate in Ubuntu is an ethos of *just do it*. I really believe our community should feel engaged to be creative in their ideas and be able to get out there and do it, with plenty of support resources so others can help them achieve their goals. I am keen that we don’t have a bottleneck where creativity is limited. Of course, this happens from time to time, but we are always keen to resolve it where possible.

While Ubuntu has a great many projects going on at any one time, some of these projects I explicitly put on my radar so I can help contribute to make them successful, and some of these are projects that I have been happy for me and my team to commit their time to. Each of these projects is scoped for a six month cycle, and when we get a little closer to the 10.10 cycle we will start thinking of where we will focus our time in that cycle too.

In the Lucid cycle I was keen to track work on this set of projects in a more effective way. To do this the process worked a little like this:

1. We first had a series of discussions at both UDS and online in which we discuss each project, what is involved and what targets and goals are in scope for the Lucid cycle. Targets beyond the Lucid cycle were explicitly deferred until the 10.10 cycle.
2. The conclusions generated from these discussions were first documented as a *Roadmap* on the Ubuntu wiki. This provides a high-level set of goals that the project is striving for.
3. We then produced a *Blueprint* for each project and a set of actions that are assigned to people. The blueprint is what we use to track progress on the project. The actions are stored in the whiteboard on the blueprint (which anyone can edit) and anyone can subscribe to the blueprint, which makes it great for keeping on track projects even if you are not involved in them.

The actions in the blueprint are stored in a set format, like this:

[jonobacon] An example action: TODO

In the above example, it clearly states who the action is assigned to (`jonobacon` on Launchpad), what it is (`an example action`) and it’s status (`TODO`). When an action is completed it is set to `DONE` and if we decide we want to bump it to next cycle, it is marked as `POSTPONED`.

This process in itself offers some key benefits:

* Commitments to a given project are clearly scoped to a cycle.
* Work is assigned to people: this is a great way of getting things done. Project Management theory has long taught that publicly assigning work to people improves it’s chances of getting done.
* Transparent: anyone can subscribe to a blueprint. As an example, even though I am not managing the *Desktop Experience* team or contributing to their projects, I am interested in their work, so I subscribe to a number of their blueprints. Each time the state of an action changes, I then get an automated email with the update. This is great for keeping up to date with their work.

With a bunch of blueprints that follow this format, I then approve a number of them as projects that my team will help have oversight on and help them to succeed. Some of these projects are driven by my team and I, but many of them are entirely community driven projects that I assign my team to have oversight over.

The legendary Martin Pitt then wrote a script to take this range of blueprints and actions and generate a [burndown chart](https://people.canonical.com/~pitti/workitems/canonical-community.html). Here is my team’s as of today:

It works like this: the Y axis is the number of actions in the blueprints I have approved for my team, and the X axis is the time until the end of the cycle (it is a little shorter as the graph was regenerated). The thick line through the middle of the chart is the *trend line*. My responsibility as a manager is to help keep the number of completed actions (shown as green) under the trend line: this ensures that we are on track for completing the committed actions throughout the cycle.

This was a pretty new concept for our community and of course the community is not expected to follow this way of working, but I have been stunned at how everyone has worked hard to stick to the actions they committed to and see the work through. As such this has felt like a really great cycle with some stunning work going on. Thanks everyone for your contributions!