Mailinglist Archive: opensuse-project (370 mails)

< Previous Next >
[opensuse-project] Improving the bug management lifecycle/process
  • From: Jim Henderson <hendersj@xxxxxxxxx>
  • Date: Wed, 16 May 2012 03:04:39 +0000 (UTC)
  • Message-id: <jov5g6$cnk$>
OK, so this is something I'd like to start trying to get my arms around
so we can have a more comprehensive approach to dealing with bug reports
and increase the rate of resolution as well as the follow-up rate when
additional information is needed.

It seems that we have a few areas that we should be looking at:

1. There should be some sort of "screening" that takes place before a
bug is accepted - to ensure that the devs aren't seeing multiple copies
of the same bugs. I think it's fair to say that those who write code
would far rather *write code* than try to sort through duplicate bug
entries. While it's likely there still would be dupes with a screening
process, the incidence should be reduced.

2. There needs to be more of a "human" reply, especially on older bugs,
that are being addressed. Looking at the current Bugzilla stats, I see
that (for example) 12.1 has 183 bugs in a "NEEDINFO" state - there needs
to be some sort of consistent follow-up to ensure that the info needed to
fix the issues is provided, and if it isn't and the information can't be
obtained (because the issue cannot be duped, those looking at it don't
have the necessary hardware, etc), then the bug needs to be closed.

3. For older bugs, (such as on 10.3-11.3, which there are still open
bugs on), a determination needs to be made as to whether the current
supported releases have those issues, and if they do, the bugs need to be
updated. If they don't, then the bugs need to be flagged in an
appropriate way.

4. It would be extremely useful, I think - especially for the non-techie
audience - to put some specific training together on things like (a) how
to submit a bug and include the relevant information, (b) what to expect
with your bug and how to monitor progress, (c) how to provide additional
information when requested (and what to do if you've upgraded/moved to
another version/changed distributions/decided to go back to Windows/MacOS/
whatever) so the bug can continue to be evaluated by those evaluating it.

Ultimately, the goal of this project is to increase resolution rates,
reduce the time to resolution as much as possible, and to visibly improve
the bug resolution process so more people don't perceive (correct or not)
that reporting bugs is useless because they don't get resolved (and
actually, looking at the stats on bug status, I think it's pretty unfair
to say bugs aren't getting resolved. I see, for example, that of the
reported bugs on 11.1, for example, over 3/4 of the bugs are marked as

And overall across all releases of openSUSE, and SUSE Linux Professional/
SUSE Linux from 8.2 on, the bugs marked resolved are 13026/18285, which
is nearly 3/4.

75% isn't bad (the Pareto rule is 80/20, and on 11.1 we're actually
around 78% "resolved"), but I'm sure that if we can guide the process and
streamline it, we can increase that.

Of course those are just rough statistics and the reason bugs are marked
as 'resolved' isn't included in that - and there is a further breakdown
that can be done that might help identify trends that would be useful.

There's clearly more that we should be looking at, but these four areas
are a good place to start. For my own part, I'm willing to do more than
talk and discuss the ideas, but it's going to take more than just one
person working in his spare time to move this along.

I also think something similar to this should be done for FATE, but
that's perhaps a topic for another day. :)

Jim Henderson
Please keep on-topic replies on the list so everyone benefits

To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx

< Previous Next >