On Feedback

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, 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.

  • http://www.jasonwjones.com Jason W. Jones

    Thoughtful post as always Jono. One thing on my mind also, is given that the community is broken up into so many distinct pieces, do we possibly lose sight of the big picture, if for example, two components should be more closely integrated?

    One sort of tangent example that comes to mind is Sun’s work on ZFS — they threw out some of the normal ideas of modularity and instead combined things different than has been traditionally done.

    I have been thinking for awhile that while Ubuntu does a good job of integrating so many pieces together, it might become desirable to treat the packaging of Gnome in a less monolithic way. A huge part of the Ubuntu experience hinges on what Gnome looks like and its paradigms (which in turn has many dependencies on X.org, which in turn has a lot to do with the kernel), and instead of treating Gnome (for example) as one big thing, maybe a more selective approach would be better.

  • Andrew Yeomans

    You’ve not mentioned the other component – documentation. The need for bug reports and patches can be significantly reduced by putting effort into easy to access documentation.

    As an example, I’ve not found anything in the Ubuntu world that’s as easy to use as http://www.fedorafaq.org/. Instead the documentation is scattered around; there’s the release notes http://www.ubuntu.com/getubuntu/releasenotes/810 – which you can’t find from “Documentation” https://help.ubuntu.com/8.10/index.html which don’t mention Medibuntu or easy links to https://help.ubuntu.com/community or Launchpad or the forums.

    Another example: I discovered that my floppy drive support had disappeared with Intrepid. It’s actually a simple job of adding “floppy” to /etc/modules, and one line in the release notes or a FAQ would have been really useful. Instead there are loads of good and bad suggestions in the forums and bug lists, which could have been avoided completely if the answer was readily available.

  • http://nancib.wordpress.com/2008/11/20/pengs-links-for-thursday-20-november/ Peng’s links for Thursday, 20 November « I’m Just an Avatar

    [...] Bacon: On Feedback. Most tech developers love getting feedback from the user community. It’s not always pretty, [...]

  • http://www.bautforum.com/off-topic-babbling/77483-input-wanted-building-my-next-pc-10.html#post1670525 Input Wanted: Building My Next PC – Page 10 – Bad Astronomy and Universe Today Forum

    [...] were having difficulties with their FDDs starting with Ubuntu 8.10: Andrew Yeomans comments about his missing floppy drive in 8.10. LinuxQuestions.org: "Ubuntu 8.1 wont use the [...]