Issue tracker - bug squad team

developers
1

Dear all,
I have been monitoring the issue tracker and it is getting really big. I think that we should put some energy in tiding it up. Of course, this is not something new, there was another attempt a few yeas ago: https://forum.fritzing.org/t/cleaning-up-the-issue-tracker/259

However, things have changed and the development has resumed. Maybe it is time to set some guidelines and share the responsibility. You can see a picture of the issues over time in fritzing-app repository here:

fritzing_issues_over_time
fritzing_issues_over_time1086×746 394 KB

This picture was done using this software: Bug life
“The bottom graph shows the lifespan of issues. The bigger the semicircle radius, the longer it takes to close an issue. If the end point of the semicircle is not visible on the graph, then the issue is still open. Each open/close event is visible on the graph. The color of the issue is set by the issue label. This is a good representation to determine old pending issues and view project agility.”

If you analyze it, there were a lot of issues closed last year, thanks the excellent work done by @KjellM, but this year most of the new issues are not labelled. Until now, I believe that @KjellM was the only person in charge of labeling and closing the topics. However, he seems that he is busy programming and maybe it is time to change this. Kicad has a “Bug squad team”, and maybe we should follow the same approach:
Basically, "Members of this team are the “bug supervisors” for the KiCad bug report database. Bug supervisors are responsible for the following:

  • Verifying reported bugs are reproducible.
  • Getting clarification such as the KiCad build information, test
    sample files, stack traces, steps to reproduce bug, etc.
  • Set appropriate bug report status and severity information."

In addition, we should consolidate the labels. We have “enhancement” and “it´s a feature”, “web” and “website”, “easy/changeling start” and “grab me”. And we should decide some rules to close the issue: For example, if we should not fix a bug because that code will be replaced in a new version or if we cannot reproduce it and the person who reported does not give us more information. For example, bugs #2783, #2654, #2184

Finally, there are still a lot of bugs that are related to parts that should be moved to the part repository: #2754, #2416

By the way, one big problem with the imported bugs is that the links that they have do not work. I guess it is not feasible to fix them.

I am willing to put some time in this and fix some bugs too, but it would be easier if all of us combine our efforts. Specially, because most of you are already checking and commenting the issues. So, it should not increase too much our workload if it is just add labels and close issues.

I have not checked the technicalities (basically, if Github supports this approach), but I hope that we can find a way to implement it.
I look forward to your replays/feedback.
Cheers,
Andres

2

Hi Andres, thanks a lot for the analysis. What would help me the most from that

  • Adding reproduction information to bugs would be incredibly valuable (it’s not easy though, for many of the issues) .

  • Commenting on issues (more information required, duplicate, already fixed, outdated …)

  • Actual PRs with fixes

The question of when to close issues, or DoD (Definition of Done) certainly is important.
But most github users would not look at a board like https://github.com/fritzing/fritzing-app/projects/1 , and I think for the number of active developers, it is overkill.
Before the 0.9.4 release and some time after, I closed issues once the code was in the dev branch. That is simple, but might lead to confusion, so I recently introduced the ‘solved’ label. Fixed issues are marked solved, and only closed once a release was made from the fix.
Issues can be marked with a release milestone, if there is a big chance that the issue will be fixed for that release. So, solved issues should all be marked with a milestone.

For all the other labels, sometimes it is clear, sometimes just a matter of taste. No strong opinion about it, except, that the labeling should be done by people who work with those issues (Reporter, Dev, Test…)

You are right about the old issues: When the issues were moved over from google code to github, the links were probably still working. But soon after, google broke them. Some of them contain important hints event though the links are dead, and some are just outdated.

3

Hi Kjel,
The problem is that the reporter , developer or tester do not have the rights to add the labels (or am I wrong?). Additionally, I do not think that the reporter should create the labels. The labels should be done by testers or developers after the issue is replicated or more detailed information is provided. Thus, you triage of the issues.

I agree that the “solved” label is useful. Kicad uses fix-commited and fix-released but it is the same concept.

Any hint on how to treat the part issues on the app tracker? I am not sure if there is a way of moving them instead of copy/paste them.

4

Yes, issues can be moved over to different repos. In case of #2754, #2416 I closed them since there seems nothing to be done: one fixed, the other one a problem with a 3rd party file, which is lost with google code.