Ubuntu is a big project. Hundreds of teams, thousands of contributors, millions of users. Every day the project grows by a fraction of a percent, but the fraction is bigger than you might think. With such a wide ranging and diverse community, growth in the project happens at an intense rate. We are not the largest collaborative project in the world, but we are not small, thats for sure.
In addition to this existing Ubuntu-focused diversity, now let us roll into the mix the deep relationship that Ubuntu has with a great many other Open Source projects. There is the obvious connection to Debian, but we also have an extensive relationship with a range of upstreams – GNOME, KDE, X.org, OpenOffice.org, Mozilla and more. With thousands of Ubuntu contributors interfacing with thousands of upstream contributors and millions of users, the jigsaw puzzle is rather large. With so many interconnections between communities, one of the problems is that a person can only see so much of the picture any one time. Part of the skill of a community manager is to try and see the full picture.
This has been something on my mind for a long time – how can we see the great many interconnecting lines between different parts of community. In effort to make progress this area, I have worked closely with my team to build some metrics to understand our community. These metrics are mostly based around bugs, but they give us a solid idea of how to see additional parts of the picture. But metrics are one thing – they show progress and they show the timeline of progress, but they don’t provide good solid *feedback*. They don’t help us to *fix things*.
Like any Open Source project, we get our fair share of criticism about what we do. Although I cannot guarantee that we will always make the right choices every time, I can guarantee that we make every effort to make the right choices based on informed evidence. The work that my team and I have been working on recently is to help better make those choices. To achieve this we have been on something of a feedback shopping spree.
Much of this started back when Jorge and I started work to improve our upstream bug story. As I talked about in [previous entry](https://archivedblog.jonobacon.com/?p=1302), bugs are an important mechanic in how Open Source projects communicate and we want to make all of the points of interaction as painless and as smooth as possible. We broke down the workflow and discovered we needed to know about the problem, and with this mind we threw out an upstream survey to some upstream projects that we work closely with, and a general survey that anyone could contribute to. We then evaluated some of the comments from the survey and continued work to develop the upstream report. The feedback helped us to craft a tool (the upstream report) which has helped us focus our efforts in the right areas. Subsequently, we have seen a marked improvement in linked bug reports between Ubuntu and upstream.
As part of this feedback, we were told that our patches could be better. Patch quality typically falls into two key areas – *quality* and *discoverability* – people want quality patches that apply easily and they want to be able to find them intuitively. We have since made this a priority and I asked Jorge to post a patch survey to a number of upstreams and also solicit more general feedback. Jorge did an excellent job here, and this survey will help us drill down in more detail how we can improve our patches. The aim here is to firstly produce best practise around patches – to help our community and our staff at Canonical not only produce technically proficient patches, but to understand what upstreams like to see in a great patch. Thanks to everyone who has participated so far. I am looking forward to the outcomes of this research and its impact on how we work with upstreams.
Feedback is a useful tool and I recommend all Open Source projects to make use of it. When sitting down and exploring ways in which you improve your governance, processes and methods of interaction, it is tempting to become to wrapped up in technical processes. It is tempting to try and produce technical solutions to social problems, but many of the problems and issues we can face within a specific community or the wider Free Software world are cultural, social and habitual divergences in practise. Feedback, and the simplicity of providing objective feedback can be a fantastic antidote to the production of unnecessary processes that attempt to solve half-understood problems. Bureaucracy is the ultimate enemy, but decisions without enough feedback from those who your *solutions* will affect, are just as potent an enemy.
