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!