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:
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.