Tracking Ubuntu Community Issues

Recently Melissa wrote a post about how we track problems with community, and how she feels that blogging about community problems is a reasonable approach. As part of her post she says:

Blogging about problems we see in our community should be seen as a good thing, not a bad thing. Why? Because this blogging is action. The alternative is no action, and that is much worse.

Firstly, I entirely agree with Melissa that we need a better way to track issues with community, which I will get to a little later in this post. While blogging has become a tremendous tool in online communities and enabled community members to have a platform in which to share their opinions, ideas, perspectives and achievements, I don’t feel blogging is the most suitable means of tracking community issues, improvements and regressions.

Blog entries are single shot capsules of feedback, wisdom and opinion ejected onto the Internet and often aggregated in places such as Planet Ubuntu. They are typically highly personalized, lurking in personally-driven locations (such as a homepage or personal blog), have no facilities for applying status, assignment, milestones or priority, provide little or no means to subscribe to specific problems, and lack facilities for communicating when a problem has been solved: if the issue is resolved the blog is sometimes updated and sometimes not.

While a blog entry can express a concern about something, they are not really useful for finding solutions to the problem. Notification of a problem is one tiny element in the issue-tracking process and although blogs can indeed be used for this, it is equivalent to asking your neighbour to move his car by opening your window and yelling out through a loudspeaker. Aside from more elegant and better directed methods of communicating that a problem exists, we ideally want to attach problem-solving capabilities to the reporting of an issue: I care only a small amount about hearing the problem, what I am really interested in is collaborating with that person and others in trying to find a solution. Blog entries are not really cut out for that kind of collaboration.

Bugs are though.

Bug reporting systems were designed to allow people to collaborate around defects in software and include facilities to identify, track, prioritize, milestone, subscribe and share information. Although everyone complains about bug reporting systems, they are generally productive in finding problems, developing solutions and having visibility over the lifespan of a problem.

I think it could be useful for us to use Launchpad for filing bugs for community, process and governance issues. To this end I have registered the Ubuntu Community project in Launchpad which we can use for tracking these kinds of bugs. There are some benefits to this:

  • Visibility – this is going to help everyone keep visible on community issues. On a slightly selfish note, this will also help me keep visibility over issues for me and my team at Canonical. This should mean more bang for your buck with your friendly horsemen.
  • Tracking / Triage – this will make tracking, prioritization, feedback and potential milestoning much easier.
  • Assignment – this improved visibility will help us assign bugs better to the right people.
  • Familiar – many of us live and breath bug reports: the interface is part of the furniture. No new systems to learn, no random blog entries to keep an eye on.

Before I wrap up, there is one simple caveat here. I have literally just set up the project this afternoon and we will need some documentation, guidance and best practise written and shared around these bugs, and this will take a little while to be developed. As such, you may have some questions which we will need to document the answers to over the coming weeks. In the meantime we can work with existing bugs and file new bugs there. Feedback on this is of course welcome!

  • jonobacon’s status on Saturday, 27-Jun-09 00:54:57 UTC –
  • Nathan Handler

    This is an interesting idea Jono. There is one issue with it that I see. When it comes to community issues, they are traditionally discussed in blog posts, in mailing list threads, and on IRC (which includes team meetings). Launchpad does not currently provide an easy method for keeping track of this information. Sure, we could simply add a comment to the bug updating the status and providing links to relevant discussions, but that is a fair amount of work that really does not accomplish much in terms of the bug. It would be useful if we had some tool that we could set to “watch” certain email discussions (possibly by CC’ing an email address watched by the tool or parsing the list archives) and IRC channels (using a bot or parsing logs). Users would then be able to update the status of the issue by using different commands (similar to how we interact with MootBot and LP or the BTS). The tool would then take care of updating the issue. I am not really sure that this tool would be appropriate for Launchpad. For the majority of the bugs, we are not going to be having discussions on the mailing list and on IRC. For those bugs, comments can suffice. As far as I know, such a tool does not currently exist, so for the time being, Launchpad will have to do. However, if we were to create this tool, I think it would be much better suited for tracking issues in the community.

  • jono

    Thanks for the comment, Nathan.

    I actually see this as a benefit. I think we should be encouraging people to target their discussion and opinion on the issue in the bug report. Right now we have the problem of discussion happening on blogs, IRC, mailing lists and elsewhere, whereas I think it would be better if it were targeted in the bug: this then means everyone can be up to date. :-)

  • Nathan Handler

    I agree that it would be nice to have all discussion in one place. However, Launchpad comments are not suited for long discussions. Just take LP Bug #1 as an example. I frequently get OOPS error messages when attempting to view it due to the more than 1000 comments. It is also impossible to sort, filter, or search those comments to try and find certain information. This is why I think that instead of attempting to convince people to carry out their discussions in comments on Launchpad, we should design a tool that can pull discussions from multiple locations and display them in an easy to navigate interface. This would allow users to continue to use the same workflows that they have been using for years. It would simply provide another tool that people could look at to see the current status of a community issue.

  • jono


    Firstly, I am not anticipating many of these conversations to reach anywhere near 1000 posts, so I doubt LP should oops.

    Secondly, while a custom tool for this very requirement could be nice, I would rather have a system up and running now in which we can manage these issues, and LP Bugs is ideally suited to this. While it may not have some of the ideas you suggest, I think it will satisfy most cases and if we find it doesn’t I am certainly open to discussing further solutions.

    Maybe we should try this approach until the end of the cycle and see how it works out?

  • Nathan Handler

    Jono, I do not disagree with you that as of right now, Launchpad is the best way to handle tracking community issues. I was just trying to outline some of the features that Launchpad is lacking that would really benefit an issue tracker such as this. I would also be interested in knowing what types of issues will be handled in this manner. A lot of community-related issues are already handled by different teams and councils in the community.

  • Mike Basinger

    Great idea Jono. I’m interested in seeing how this develops.

  • Jono Bacon: Tracking Ubuntu Community Issues |

    […] related to your search Jono Bacon: Tracking Ubuntu Community Issues is now available in this link…: News […]

  • ethana2
  • Flimm

    Great to see Melissa’s feedback blossoming into action, I guess blogging does work sometimes! :)

    My question would be: what kind of bug is relevant to ubuntu-community? eg: can I post bugs concerning ubuntu-forums? the wiki? the behaviour of certain ubuntu members? the use of the Ubuntu trademark? the beard of the community leader?

  • Stefano F. (tacone)

    Excellent initiative.

  • jorge

    All those seem to be relevant good examples. (especially the one about the beard)

    One of the reasons I think Melissa’s idea is so great is that we can have a grasp of what problems people are having as a whole as opposed to “Well I mailed Jorge about this, waiting to hear from him”. This also gives us an opportunity to track things better instead of just saying “Yeah I’ll ask Nick to mention this in UWN” or “Someone should ask the forums to run a stick on the Free Culture Showcase.”

    And of course, the entire thing is transparent to everybody, which is a big win.

  • jorge

    Actually I take that back. I wouldn’t file a bug on someone’s behavior, I would just use the normal channels – a private email or whatever.

    If we let people file bugs on other people we would overwhelm launchpad.

  • jorge’s status on Saturday, 27-Jun-09 14:32:36 UTC –

    […] Tracking !ubuntu Community issues via a bug tracker, thoughts? […]

  • siguiendo los problemas de la comunidad « effiejayx’s blog

    […] los problemas de la comunidad Al leer un post en el blog de Jono Bacon, voy a hacer un poco de eco en español para traer el debate a nuestra comunidad en […]

  • Nathan Handler

    Jorge, wouldn’t we want to continue to allow the various teams to handle certain issues in their domain? For example, actual bugs concerning the forum should be filed against the forums (which are a project on LP). If it is another type of issue with the forum, it can go on the Forum Council meeting agenda for them to discuss. Wiki bugs, depending on their nature, can be filed against the website. Otherwise, it might be beneficial to contact the documentation team (more so for the community wiki). Trademark issues in the past have gone to the Canonical legal team/Community Council. And issues with the behavior of other members have gone to the relevant council (depending on the area the behavior took place in). Would these teams still be handling the issues? Or would the new community team be taking over all of these? If it is the later, I think the Community Council would need to delegate some authority to the new community team.

  • Randall Ross

    Excellent idea Jono. I’d argue that it’s not a new one though. Isn’t Bug #1 by definition a “community” bug?

    Credit goes to Mark Shuttleworth 😉

  • Andrew Bennetts

    It’s important to realise the choice of forum will affect the conversation you get. I’m reminded of Jono Lange’s talk/paper on code reviews, which makes the same point about how where you discuss and track code reviews affects the review process. Bug trackers especially will produce a different sort of conversation to blogs and mailing lists.

    Some obvious differences: a bug (as tracked by Launchpad) has an overall description that can be updated anytime, a status, maybe an assignee, and an unthreaded series of comments. It’s also not as straightforward for an interested party to subscribe all conversations held in bugs for a project as it is to subscribe to a mailing list or the planet’s RSS feed.

    These differences might be a good or bad thing for this purpose, I’m not sure. But I think you should definitely treat this as an experiment, and keep an open mind about what the results of this experiment will be.

    Perhaps “filing a bug” which has “status” and “importance” fields will generate conflict and adversarial conversations. Perhaps “here’s a problem for us as a community to fix” will encourage collaboration and consensus. Perhaps issues that might have been forgotten will now be addressed because they are formally tracked. Perhaps arguments that would normally fade due to lack of interest will be sustained indefinitely because they never get “closed”. Or something else entirely, I don’t know :)

    I hope the experiment goes well!

  • Michael @ QuinnCo

    Maybe Brainstorm would be a better tool than bug tracker? Except that they don’t get “assigned” to someone to resolve.

  • Ubuntu Podcast Quickie #7 01 July 09 « Ubuntu Podcast

    […] This Ubuntu Podcast Quickie, we discuss: Kubuntu Tutorials Day, Ubuntu Brazil at FISL, president of Brazil with ubuntu-br shirt, Debian/Ubuntu Boot Performance collaboration, first One Hundred Papercuts milestone reached, and tracking Ubuntu Community issues on Launchpad […]

  • Alex Lourie

    Hi Jono

    In addition to doing bug commit in Launchpad, some of the “community bugs” could be also reflected in Forum/Ubuntu Weekly/Ubuntu Planet posts (and that’s where blogs are still highly useful), so the issue will be exposed for more “general” broader public.

    It would bring less technically inclined folk to discussions about the issue and may bring more ideas about to how it could be solved/taken care of.

  • Ubuntu Podcast Quickie #8 «

    […] This Ubuntu Podcast Quickie, we discuss: Kubuntu Tutorials Day, Ubuntu Brazil at FISL, president of Brazil with ubuntu-br shirt, Debian/Ubuntu Boot Performance collaboration, first One Hundred Papercuts milestone reached, and tracking Ubuntu Community issues on Launchpad […]

  • Reporting Ubuntu Community Problems | jonobacon@home

    […] how we report problems and issues in the Ubuntu community. I shared some thoughts about this a little while back and I have been talking with many people inside the Ubuntu community, at the Community Leadership […]