Cleaning up the Bug Tracker

[triplus]

Hi @Kunda1.

You have been doing a lot of management related tasks regarding issue tracker for a few months now. Like opening issue related threads here on the forum and other things. I was wondering what does the statistics say. Did we manage to improve things in any regard or does it show the issue reporting and resolving dynamic in FOSS project is a bit specific?

Should we for example start thinking about closing issue reports automatically after longer time of inactivity? As the relevant ones will likely be reopened anyway. And as for the rest best to close them at some point to reduce the noise?

[Kunda1]

Hi @Kunda1.

You have been doing a lot of management related tasks regarding issue tracker for a few months now. Like opening issue related threads here on the forum and other things. I was wondering what does the statistics say. Did we manage to improve things in any regard or does it show the issue reporting and resolving dynamic in FOSS project is a bit specific?

I have been working the Bugtracker since the end of last year (Nov-Dec '16). For visual metrics I would ideally attach the MantisBT graph that is generated but it is poorly designed and doesn't fit on my laptop screen. So I'm attaching the following stats to show progress.

Tracking tickets that have been opened and closed per period.

FC-mantis-stats-2017-08-21-summary-per-period.png (18.84 KiB) Viewed 1817 times

There has been good progress.

My observation is that the FC community uses the BT differently then other projects. I think this is due to historical habit and a lack of stable integration between the forum, bugtracker, and github. At the time of this writing, the emphasis of the FC project is as following from highest priority to lowest: forum, github and then the bugtracker. Historically and currently people have been posting to the bugtracker assuming that this was a 'first-response' method of getting the teams attention. In FC as you know very well, we ask people to first open a forum thread and then the community ascertains if the issue merits a ticket (thanks to some recent refinements in banners and such this 'noise' has been cut down substantially). Because of this low priority focus on the BT, tickets have been open and then rot because they get buried without being announced to the forum.

FC team also doesn't really utilize the 'Priority' status of tickets (low, normal, high, urgent, immediate) which I think can be useful to prioritize and organize bugs.

An aside: we (mostly @yorik, @kkremitzki but also myself) tried to implement a stable workflow for Source Integration (SI) which is a plugin for MantisBT to integrate with github but due to initial import issues (the SI plugin needs to load the git history of the whole FreeCAD git repo but malfunctions so we have an incomplete import ATM) we needed to manually sync it which we do seldom and it doesn't always work correctly. If anyone is interested here are some Source-Integration issues that are blocking us from it working: here and here

An interesting phenomenon and strength of FC is it's diversity. The number of tickets closed shows some progress but not incredible progress. This has to do somewhat with the popularity and heavy development going on in FEM, Path, TD, and PDN workbenches. Although I don't have good metrics to show when these tickets were open and closed...here is a snapshot of their activity:

Shows the amount of open tickets per Mantis Category.

FC-mantis-stats-2017-08-21-Categories.png (36.48 KiB) Viewed 1817 times

FC-mantis-stats-2017-08-21-Resolution.png (26.16 KiB) Viewed 1817 times

Should we for example start thinking about closing issue reports automatically after longer time of inactivity? As the relevant ones will likely be reopened anyway. And as for the rest best to close them at some point to reduce the noise?

I'm not sure about auto-closing ticket. I've heard different takes on this before. I refer this question to the devs.

Perhaps another model to approach this is schedule a bi-yearly bug tracker cleanup where a team combs through the tracker and weeds out any non-relevant bugs/features. Right now for example there are 31 pending 'Feedback' status tickets that could be resolved.

Ticket per status. There are 31 ticket in Feedback status. Many of them are rotting.

FC-mantis-stats-2017-08-21-Status.png (18.4 KiB) Viewed 1817 times

Currently: We have 221 bug and 251 features with some other misc. tickets which brings us to 491 active open tickets.

[triplus]

Good job!

[Kunda1]

tracker-09-26-2017.png (97.93 KiB) Viewed 1742 times

[Kunda1]

[triplus]

Nice!

[yorik]

Thanks a lot for your heavy work on the tracker @Kunda1. This makes a huge difference!

[Kunda1]

Lots of work recently on the tracker

[NormandC]

I believe the number of registered reports has been steadily increasing in the past couple of years.

[bernd]

are these bugs only, or bugs and features?