QGIS Bug Tracker cleanup #266
Comments
|
I totally agree with the idea of cleaning up the issue tracker. I've had some ideas before, but never posted them. Since this is now a thing, here's my thoughts. If I may make a related suggestion, have new issues created be given the tag "Needs Triage" so it can be easy to filter issues by those needing to be processed and tagged. I would also suggest retroactively setting existing issues with just "Bug" or "Feature Request" to be given "Needs Triage" so that we can find old issues in need of processing. I would also include ones with "Needs Feedback" with no other tags other than "Bug" or "Feature Request" so we can see outstanding issues that still need triage/tagging once feedback is provided. I don't know how much of this is possible with GitHub, but this is merely a suggestion/discussion point. |
@esnyder-rve certainly doable, and not very dissimilar to what I have been doing for long up until March 2022. |
|
Thanks for putting this forward @gioman. As a user putting issues in I always appreciated your prompt triage of the issues. I do feel like this is an important and delicate issue because for many users the response to an issue is their first interaction with the QGIS "organization" and that experience sets their perception and expectations of QGIS and the QGIS maintainers. Old issues that may not not be appropriate for the core QGIS are still valuable user stories and could be useful for someone making a plugin to address the issue. Perhaps closing with a label that is not "will not fix" but rather something else more diplomatic like "good feature for a plugin". |
I'm strongly against closing old bug reports just because they are old. The original author and issue date are completely irrelevant as long as there is a reproducible bug out there (eg. see #14070, that took some 11 years to get fixed) and it doesn't really cost to keep them at the far depth of the queue.
I'd make sure to update those four rather than close and re-open or wait for someone to eventually re-report. Regarding features though, the queue can definitely be cleanup up a bit, as there are lots of old features that are either already implemented, completely absurd or not applicable any more. However, they don't affect bug fixing efforts at all, since they lack the Bug tag. |
@baswein thanks, this is an important observation
No one wants to just "delete" or make disappear very old bug tickets or feature requests that are deemed to be more suitable for a plugin. We will (eventually) tag such tickets with an appropriate label, so they will be easily searchable. |
@uclaros that's not exactly the idea, but I (we) see your point, after all opinions about that were always split. Beside the cleaning "as usual" (closing invalid, not replicable, with no feedback, etc.) issues, the idea is to close, not delete, old/very old reports that maybe are valid but that no one (not even the users, much less the developers) are interested in fixing. This do not apply to feature requests of course.
True, it does not cost anything but as noted before this causes the tracker to feel a bit frustrating for users as some developers too. Maybe we could apply a special tag/label to such issues, leave them open, and have the tracker exclude that tickets on load (not sure this is possible).
this is one of the main goals of this proposal. Anyway this will also need a word from devs, as their opinion matters a lot in deciding if a request is worth staying or is more appropriate for a plugin. |
|
Hi @gioman. I'm working on wrapping up the 2023 grant programme. How is the progress on this project? Can you give me an estimate for the completion and final report? As you probably know, I'm collecting all final reports and summarizing them so everyone can read up on the results of the programme. |
|
Final report here QGIS grant report: QGIS Bug Tracker cleanup We are pleased to announce that this grant is now completed. While checking existing bugreports we have identified and closed ~291 tickets, among them:
Additionally we ensured that all tickets has correct tags assigned to to make them easier to find. Thanks for making this possible. |
|
Hi @gioman , thanks for completing this! Can you share more info on the bug reports closed? I'd be more interested in the 5 wontfix and 33 closed ones. |
|
won't fix closed before closing as won't fix we consulted with a core dev (@alexbruy ) who was actually the one pressing the buttons. |
QGIS Enhancement: QGIS bugtracker cleanup
Date 2023/04/20
Author Alexandre Neto (@SrNetoChan), Giovanni Manghi (@gioman)
Contact giovanni dot manghi at gmail dot com, senhor dot neto at gmail dot com
maintainer @gioman, @SrNetoChan
Version all versions
Summary
Along the years many tickets/issues reports have accumulated in the QGIS bug tracker (Redmine first, Github later) and while all recent (or not too old) confirmed/valid reports are an invaluable resource, is arguable that (several years) old reports still hold any value.
Keeping the stream of new bug reports queue clean/tidy is a considerable effort on its own, and keeping open the many tickets which are irrelevant, have poor title/description, have wrong labels, lack test data or that are even already fixed, makes things hard for both contributors and final users:
A similar rationale, even if not totally the same, can be used for feature requests: rarely features requests have been questioned by developers as valid or not (i.e. when a clear -even if indirect- path is available in QGIS core, or when the feature requested is more adequate for a plugin): the feature request queue should be re-evaluated in order to leave open just what is really deemed to be a missing core functionality.
Historically there has been an "open" effort around the bug tracker, with many persons involved in a more or less continuous way, while the bulk of the effort ( since 2009) has been done by Giovanni (Manghi) that had to take a sabbatical since March 2022. This proposal aims to restore the tracker situation as it was until March 2022 and improve on that, taking decisions on very old tickets as also evaluating and cleaning the feature request queue.
This effort is to be done by a group of persons that is used to work as a team and that is able to handle the many aspects of testing/triaging, like using: multiple environments (Windows, macOS, Linux, Dockers, Virtual Machines, etc.), command line tools (compiling, GDAL/OGR, etc.), RDBMSs (PostgreSQL, Oracle, etc).
Proposed Solution
A big cleanup of the bug tarcker should make things more manageable. This includes:
closing all bug reports created prior QGIS 3.0. To note that many tickets for QGIS 2.x (and even 1.x!) have been migrated from Redmine and have lost any connection with the original author. Important issues still valid for QGIS 3.* can be re-filed if needed (while is arguable that any valid bug filed for QGIS 1/2.x that is still valid has any relevance at all).
going through all remaining bug reports and ensuring that:
While someone may argue that very old tickets bring some value (we have reports that are many years old, even 10 or more), we should be pragmatic and use the approach used in many other projects: close tickets that -even if valid- no one care to fix, which likely mean that is about something that do not affect a relevant number of users (especially -but not limited to- the ones that have lost any connection with the author and/or that are missing clear steps/data to replicate or are about pieces for the code that is abandoned, i.e. GRASS plugin).
The expected outcome of the proposed cleanup is a much lower number of open tickets with better metadata and content, which should make life of developers and users easier.
Affected Files
None
Performance Implications
None
Further Considerations/Improvements
(optional)
Backwards Compatibility
(required)
Votes
(required)
The text was updated successfully, but these errors were encountered: