Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
> * 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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
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: https://github.com/qgis/QGIS/issues/31251 which is clearly something that was overlooked when re-writing/re-designing that edit tools -- G -- ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
On Sat, 24 Aug 2019 at 18:40, Giovanni Manghi 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@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
> 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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Issue priorization for bugfixing: go flag your favorite issues
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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
