Re: Live bugzilla analysis/statistics

["Willem van Bergen" <gnome vanbergen org>]

Hi,

> > I have worked on a similar tool to analyze platform maintenance
> > process data in the natural gas industry for the last two years in my
> > former job. This tool has been in use now for some months and is
> > really helping getting the maintenance work done.
>
> can you elaborate a bit about the features that you have in mind, or
> which stuff you would like to track and show?

The main idea is that each bug propagates through a list of defined
statuses. At this moment, only stats about opened and closed bugs are
available. Because of this, everything that happens in between
essentially is a big grey area and is hard to monitor. To overcome
this, we need to look at other statuses in between. I would suggest to
define a list of statuses a bug propagates through *ideally*. Let's
say: new -> confirmed -> is being worked on -> patch available ->
patch reviewed -> patch applied -> resolved. (This has to be adjusted
to the actual gnome bugzilla situation, of which I am not 100% aware.)

The next step is to measure Some interesting things to measure would include:
- the number of bugs "arriving" in and "leaving" from a status;
- how long bugs are "waiting" in the current status and how long it
takes for bugs to propagate to the next status (how long does it take
to confirm a bug or review a patch?);
- the amount of bugs that do not follow this ideal workflow and at
what status these bugs diverge from this workflow;
- how many patch versions are needed before a patch is applied;
- bugs having patches from users with a low bugzilla score (may need
extra reviewing, extra support, quicker response);
- bugs without comments by a maintainer;
- bugs tagged with "user interface" but without a mockup attached;
- etc.  You probably can think more and better measurements than I
can. Go crazy! :-)

The results of these measurements should be categorized. A tool would
present the results of these measurements in trend graphs, showing the
number of applicable bugs per category per week. This makes it easy to
identify trends. The actual numbers are also shown in a table as a
link. Clicking this link will present a list of the actual bug numbers
in that category. This makes it easy to act upon the results of a
measurements. The tool should have the possibility to only include
bugs that are interesting to you, for example: only bugs from a given
module or with a given priority.

To be able to implement a tool like this, it would probably be best to
create a copy of the bugzilla database and regularly keep it up to
date. Most of these measurements will require significant resources
and should not degrade bugzilla's performance of its primary goal.
Luckily, bugzilla contains all the history information we need. In my
previous job, I had to generate history information by analyzing
differences between daily uploaded snapshots. It was a pain to get
that right :-(

I hope this explanation clarifies my ideas some more. If you have any
other ideas for such a tool, please let me know.


Regards,

Willem