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.