Ubuntu User: I have a problem…

At UDS-O I led a session on improving the community involvement with Bugs. The original intent had been to ensure that Ubuntu users understood the bug life cycle, but as the discussion progressed it became clear that the wrong assumption had been made. We had forgotten that there would be group of users who would not have any interest in putting in a bug report or following it through the life cycle. The wrong starting point was also being discussed at the beginning. Users do not have ‘bugs’; they have problems. A problem may end up being a bug, but it could be many other things as well.

In the end the goal was still the same. Increase Ubuntu users understanding of the support ecosystem to ensure that they had valid expectations and improve the quality of the bug reports being put in to launchpad.

The first step in the process was to create a high-level diagram of the process. For some this diagram will be too non-technical, but the aim was specifically to reduce technical details. Other documents will be created that can provide a deeper dive in to bugs and QA. I would like to gather some feedback on the diagram as it stand now. Thanks for Brian Murray for helping edit the diagram with me.

ubuntu-problem diagram

ubuntu-problem by charles profitt and brian murray is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

UDS-P: Community Bug Involvement

I drafted a blueprint at UDS-P this year to address the issue of poor bug reports and Ubuntu users being upset about ‘nothing being done’ about their bug reports. When I first drafted the blueprint I knew that many people in the Ubuntu Community did not understand that bug lifecycle and that the documentation was very complex.

Carlos De Avillez made a solid point during the discussion that changed my original perception and brought a solution in to focus.

Users are not trying to file a bug report; they are trying to solve a problem

That is an impactful statement! I had been focused on trying to teach people how to put in proper bug reports and to understand that SRCs do not happen that often. The focus now became on how to ensure that people just looking to get ‘stuff done’ using Ubuntu could find help without having to engage in filing bug reports that ended in frustration.

The first step in this will be to improve the pathway to resources that help resolve problems and only lead a person to filing a bug report as a last step. Also, making people aware that filing a bug report may not result in a fix until the next release of Ubuntu. Part of this will be to create a graphic flow chart of the process. On of the best flow charts I have seen is one from Fedora (seen below). I hope to make a chart that is similar, but that includes avenues for getting the problem solved prior to filing a bug.

I plan on starting to work on this diagram this weekend and will look for feedback from the community to ensure it is complete and easy to understand.

Ubuntu Bug Workflow and the Community

In the proprietary Apple or Microsoft environment bug reporting and work flow is, to me, more clearly defined to the end user. In most cases the manufacture of the software is responsible for bugs in its software and identifying the manufacturer is easy since their name is on the box the software came in or the website it was downloaded from. Despite this many end users still lack a basic understanding of this. The environment in Ubuntu does not have the same delineation since the software comes from Ubuntu’s software center. There is a warning about updates in the software center, but I think most end users do not fully understand how this applies to bugs.

Canonical does not provide updates for <software title>. Some updates may be provided by the Ubuntu community.

There is also a difference between a Canonical project and an upstream project that Canonical provides support for which adds even more complexity to the process over what exists for Microsoft and Apple. Microsoft only accepts public bug reports for twenty-one titles; a small fraction of the software they produce and sell. Ubuntu developers accept bug reports for a much larger set.

I believe the community needs to have a better understanding of this environment and the bug work flow and triage process. After giving this some thought three tiers of knowledge emerged.

• Developers – high understanding of the entire process including the submission of patches to the repositories and upstream communication
• Bug Triage / Bug Control – high understanding of the bug triage process including reporting the bug upstream, finding matching bug reports upstream and in other distributions
• Ubuntu End User – general understanding of the bug triage process including knowledge about the existence of upstream bugs and a good understanding of how to report a bug

In recent cycles there has been a focus on improving bug-control and at UDS-P there are three blueprints regarding improving this process.

• Process review and improvments for mentoring new Bug Squad members
• bug tracking, targetting, lists
• Detection of appropriate package for no package bug reports

These three sessions focus on the first two tiers. I have proposed a blueprint for inclusion at UDS-P for dealing with the third tier. I believe that if the third tier becomes more aware of the environment that initial bug reports will be better and the entire process will become much more efficient as a result.