[QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues

[Nyall Dawson]

On Sat, 24 Aug 2019 at 18:40, Giovanni Manghi <giovanni.manghi at gmail.com> wrote:

> As someone else said is not true that a "bug is a bug": while certainly there are issues that is not easy to classify if they impact a lot or not, the vast majoity is easy to to say if they are important or not. Do not confound the fact that maybe a ticket do not gets much attention or comments: just a few people actually do that (file tickets, comment), part of them were also educated to have faith and expect fixes (of important issues) at least in the upcoming LTR releases, sometimes just to wait in vain (just because the the paid bug fixing effort do not comes with any sort of priority list).

Putting aside the rest of the conversation regarding regressions for
now, something I'd like to see clarified is what exactly classifies as
a regression? There's SO much users can potentially do in QGIS which
goes far beyond the original design of any particular feature, and
which works by sheer chance alone. If this breaks in a future release,
is it really a regression? To use a ridiculous example, if I wrote a
custom script which relied on hooking into QGIS dialog's widgets via
raw PyQT api, and then that dialog is rearranged in future and the
button I was tapping into is removed -- is this really a regression?
I'd argue strongly not, and that all along I was playing it dangerous
by relying on unintentional behaviour.

So maybe something explicit like: "a regression is a clearly
documented feature (or a feature with pending documentation ticket),
or a feature covered by existing units tests, which breaks". This
means:
- clicking the browse button in the file attachment widgets crashes
qgis: regression
- a project which depends on postgres foreign data wrappers to
evaluate a default field value by performing an aggregate on a related
layer from the current project breaking in a future release: not a
regression

Nyall

>
> have fun there
>
> -- G --
>
>
>
>
>>
>> Yesterday at a dinner with many well known friendly faces, a discussion
>> started about the priorization of issues.
>>
>> One of the main problems when deciding which issues to tackle is, that a
>> developer perspective often differs from the one from the average user
>> perspective.
>>
>> So we thought it might be a good idea to start giving our users a bigger
>> voice in how bugs are prioritized - and how the projects funds are spent
>> - by giving the developers more information about the "impact footprint"
>> of issue reports.
>>
>> *In short: if you particularly hate an issue (or two or three) go to
>> this issue on github and just give the first post of it a thumbs up****.*
>>
>> The following link will then show the leaderboard of annoying things
>>
>> https://github.com/qgis/QGIS/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3ABug
>>
>> While there is no guarantee that these bugs really will be solved first
>> (there are a couple of other things also to take into account, like a
>> well defined solution being at hand) this should give us a much better
>> (democratic) idea of the often-cited user expectation.
>>
>> Thanks for reading
>>
>> Matthias
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer