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 _______________________________________________ Gnome-bugsquad mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
