gioman commented 1 year ago

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:

users wanting to report a problem frequently have an hard time searching/browsing the queue to check whether a specific problem was already reported
developers have hard times prioritizing tickets or reproducing bugs. This is especially crucial during bug fixing rounds when they often spend valuable time digging the bug queue instead of doing actual coding

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:
- it is a valid issue
- it has a proper title/description with steps to reproduce (modifying title/description and/or adding steps to reproduce if needed) as well as test data
- assigning/changing labels
evaluating all feature requests (including created prior QGIS 3.0):
- it is a valid feature request
- it has good title/description and proper labels

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)

esnyder-rve commented 1 year ago

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.

gioman commented 1 year ago

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.

baswein commented 1 year ago

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

uclaros commented 1 year ago

closing all bug reports created prior QGIS 3.0.

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. As a dev, what's important to me is:

Making sure it's a real bug
Clear description and steps to reproduce
Having related bugs reference each other
Tags are also nice

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.

gioman commented 1 year ago

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

@baswein thanks, this is an important observation

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"

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.

gioman commented 1 year ago

I'm strongly against closing old bug reports just because they are old.

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

and it doesn't really cost to keep them at the far depth of the queue.

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

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

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.

anitagraser commented 10 months ago

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.

gioman commented 10 months ago

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:

162 bugreports and feature requests which were already fixed or implemented
29 bugreports and feature requests which are invalid (data issues, wrong use of functionality, etc)
57 duplicate bugreports and feature requests
5 won't fix bugreports
5 bugreports were converted to feature requests
33 tickets were closed (does not contain steps to reproduce, test data and no feedback was provided within several month)

Additionally we ensured that all tickets has correct tags assigned to to make them easier to find.

Thanks for making this possible.

uclaros commented 9 months ago

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.

gioman commented 9 months ago

won't fix https://github.com/qgis/QGIS/issues/43904 https://github.com/qgis/QGIS/issues/49036 https://github.com/qgis/QGIS/issues/49803 https://github.com/qgis/QGIS/issues/51134 https://github.com/qgis/QGIS/issues/48816

before closing as won't fix we consulted with a core dev (@alexbruy ) who was actually the one pressing the buttons.

qgis / QGIS-Enhancement-Proposals

QGIS Bug Tracker cleanup #266

QGIS Enhancement: QGIS bugtracker cleanup

Summary

Proposed Solution

Affected Files

Performance Implications

Further Considerations/Improvements

Backwards Compatibility

Votes