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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Matthias Kuhn 🌍

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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

pcav
Hi Matthias,

On 24/08/19 09:16, Matthias Kuhn wrote:

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

I find the idea interesting and positive, but I see a couple of problems:
* this may generate frustration among users (why the hell an issue with
tens of "likes" has not been solved already? You crappy developers don't
listen to us!)
* thumbs up is cheap, and does not necessarily reflect real interest.
I would be more in favour of an honest expression of interest: I put my
money where my mouth is. Can we have a mechanism of donations attached
to a articular ticket?
Cheers.

--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

Matthias Kuhn 🌍
Hi Paolo

On 8/24/19 9:21 AM, Paolo Cavallini wrote:

> Hi Matthias,
>
> On 24/08/19 09:16, Matthias Kuhn wrote:
>> 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.
> I find the idea interesting and positive, but I see a couple of problems:
> * this may generate frustration among users (why the hell an issue with
> tens of "likes" has not been solved already? You crappy developers don't
> listen to us!)

I think this is mainly a point of communication.

If explained well as an "indication" and not as a "guarantee" - online
and live while teaching - I think we'll get the message out.

And, even if not fixed it will help us triage the important ones and add
status information (for those who read carefully).

> * thumbs up is cheap, and does not necessarily reflect real interest.
> I would be more in favour of an honest expression of interest: I put my
> money where my mouth is. Can we have a mechanism of donations attached
> to a articular ticket?

It's an interesting idea, but I am afraid we'll put the project in a bad
position. In particular, it brings the project into a situation where it
acts as a service provider proxy, where it's easy to interpret the
project as the one to take responsibility for those bugs being fixed
(just like you wrote above "why the hell has issue X not been solved
yet", but with money involved this time), and last, it's hard to come up
with a good process (should there be estimates first? or money first and
when there's enough someone picks the issue?).

I would say we better leave this role to the developers and have
earmarked fundings for well defined projects (like the mac builds) or by
directly advertising current crowdfunding projects from developers.

Cheers

> Cheers.
>
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

Giovanni Manghi
In reply to this post by pcav
Thanks Matthias, thanks for this, as of course it *is* the eright thing to do,

I only hope that next time this will be at least announced a little bit more in advance other than a Saturday morning, during August, at the start of the dev meeting.

I did in the past several "priority lists" and it takes a while to decide, togther with you developers, what is worth prioritizing and what not.

SpeakingΒ  about that, and just to clear air about a thread on a similar subject in the PSC list:

There is no "paranoia" (I kindly ask stop using this word around this matter) about/around regressions. Regressions *always break someone workflow*, and it is not about you or me to decide if not fixing them (who are me/you to decide that someone else workflow is not important?). They should be always fixed, at least in our LTR release (and also thanks to Sandro Santilli for basically saying the same thing).

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

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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

Giovanni Manghi
In reply to this post by pcav

I would say we better leave this role to the developers

what role, to choose what to fix? if yes then... no, not completely at least.

-- G --

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

Nyall Dawson
In reply to this post by Giovanni Manghi
On Sat, 24 Aug 2019 at 18:40, Giovanni Manghi <[hidden email]> 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
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

Giovanni Manghi
Hi Nyall,


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?


in my mind, a regression is some functionality that worked and does not work anymore. It also does not have an acceptable workaround (or alternative path to achieve the same result)


- clicking the browse button in the file attachment widgets crashes
qgis: regression

clearly a regression, and it does not matter that is an upstream problem. We knew about it for about a year and only took action (removing the button!) only now.
This particular regression should have been handled much more gracefully than we did.

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

clear example of something that likely is not used by many, unlike the previous example, so something that can be discussed if is urgent to fix or even a won't fix.


In the real of "technically not a regression, but pretty bad one" I could make a recentΒ  example:


which is clearly something that was overlooked when re-writing/re-designing that edit toolsΒ 

-- G --

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

pcav
In reply to this post by Matthias Kuhn 🌍
Hi Matthias,

On 24/08/19 10:06, Matthias Kuhn wrote:

> I think this is mainly a point of communication.
>
> If explained well as an "indication" and not as a "guarantee" - online
> and live while teaching - I think we'll get the message out.

agreed, but I'm still unsure we'll be able to convey the right message.
I have see social networks taking strange directions easily, regardless
of the efforts by the transmitter. Of coourse, GH has already a bit of a
barrier for casual users, so we might be sheltered.

> It's an interesting idea, but I am afraid we'll put the project in a bad
> position. In particular, it brings the project into a situation where it
> acts as a service provider proxy,

agreed, this is a real issue

> where it's easy to interpret the
> project as the one to take responsibility for those bugs being fixed
> (just like you wrote above "why the hell has issue X not been solved
> yet", but with money involved this time), and last, it's hard to come up
> with a good process (should there be estimates first? or money first and
> when there's enough someone picks the issue?).

again, it's a matter of communication ;)
I don't think we should expect for the users to pay fully for the fix,
but rather use the money donated as an honest indication of interest,
more reliable than a cheap click.
this approach wouold also alleviate or solve the previous point.

Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

Matthias Kuhn 🌍
In reply to this post by Giovanni Manghi
Hi

On 8/24/19 10:39 AM, Giovanni Manghi wrote:

> Thanks Matthias, thanks for this, as of course it *is* the eright
> thing to do,
>
> I only hope that next time this will be at least announced a little
> bit more in advance other than a Saturday morning, during August, at
> the start of the dev meeting.
>
> I did in the past several "priority lists" and it takes a while to
> decide, togther with you developers, what is worth prioritizing and
> what not.

Please continue this list. I see the two things as complementary and
wouldn't want to sacrifice one for the other! I even think that if the
thumbs up work nicely you can take it as input for your list too.

>
> SpeakingΒ  about that, and just to clear air about a thread on a
> similar subject in the PSC list:
>
> There is no "paranoia" (I kindly ask stop using this word around this
> matter) about/around regressions. Regressions *always break someone
> workflow*, and it is not about you or me to decide if not fixing them
> (who are me/you to decide that someone else workflow is not
> important?). They should be always fixed, at least in our LTR release
> (and also thanks to Sandro Santilli for basically saying the same thing).
>
> 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).

Can we move this discussion to a different thread?

I fear this does not help to bring the discussion here forward.

>
> have fun there

Are you not coming?

Thanks anyway, we'll send some pictures :)

Matthias

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Issue priorization for bugfixing: go flag your favorite issues

Jonathan Moules-4
In reply to this post by pcav
 >Β  * thumbs up is cheap, and does not necessarily reflect real interest.

I disagree. Yes a thumb-up is a "cheap", but the only people who find
the issue in the first place to thumb it are those it affects. For this
sort of thing Cheap is a virtue not a problem (I very much doubt there
are any troll-farms out there targeting bug lists (yet...)).


I think this is a great way of communicating how much certain issues
affect people and then the limited resources can be directed appropriately.


On 2019-08-24 08:21, Paolo Cavallini wrote:

> Hi Matthias,
>
> On 24/08/19 09:16, Matthias Kuhn wrote:
>> 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.
> I find the idea interesting and positive, but I see a couple of problems:
> * this may generate frustration among users (why the hell an issue with
> tens of "likes" has not been solved already? You crappy developers don't
> listen to us!)
> * thumbs up is cheap, and does not necessarily reflect real interest.
> I would be more in favour of an honest expression of interest: I put my
> money where my mouth is. Can we have a mechanism of donations attached
> to a articular ticket?
> Cheers.
>


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer