The bottleneck is triaging

Thomas Ward teward at
Sun Dec 14 14:17:28 UTC 2014

On 12/14/2014 08:32 AM, Alberto Salvia Novella wrote:
> Metrics suggest that the bottleneck of bug management is in triaging,
> not in fixing.
I'm going to come out and say that you haven't defined the scope of your
metrics or your method of assessing the metrics.  Therefore, I can only
assume your metrics are about current bug states, rather than
historically analyzing Fixed vs. "Fixed After Triaged".  If that is the
case, these metrics don't accurately reflect anything in the 'process'
at all.  You need to explain how you got those metrics and what was
actually assessed before the metrics can be a good reflection of any status.

So, I ask: What information is your metrics based on: In-depth
historical analysis of the bug statuses to determine if having anything
marked "Triaged" has any real impact on non-Main packages?  Or just the
current 'bug status' of the individual bugs?  Or just a general overview
of bug status over time?  (Also, a single month of time, and two data
points in your diagram, is not an accurate or usable sample of data for
metrics analyzing a process - I'd suggest your metrics be expanded to
start at the beginning of a dev cycle and take data points monthly up
until the end of the dev cycle for a release and then show the metrics)

> Fixing evolution:
> Triaging evolution:
> So what will improve efficacy of bug management right now will be
> improvements on how to triage more easily.

Are you certain that's the only bottleneck?

Part of me believes that another potential bottleneck is *not* actually
the triage process - rather the hurdle of finding individuals willing to
maintain the Universe software.  As it currently stands, Universe is
community supported, so patches and fixes end up on the Community's
radar instead of the developers in Main.  This was the case with the
`nginx` package before I kind of took it under my wing.  It is also the
case with many other packages still in Universe, including utility tools
that network analysts and developers use very day such as Wireshark, in
that patches are not actively backported to them (which results in
unfixed issues and security holes, the latter of which is not
necessarily on the Community radar, but is still relevant to mention).

Also, as well, (in the message after the one I'm replying to now),
Michel Memeteau makes a good point: Marking bugs as "Won't Fix" or a
status that is not relevant in the specific case are another bottleneck
- triagers who don't fully understand what should be done.  As the bug
referenced by Michel had its status reversed by Marc Deslauriers, I
won't dwell on this, but the point is still made.


More information about the Ubuntu-bugsquad mailing list