[QGIS-Developer] Post github issues migration clean ups - some proposals

[DelazJ]

Hi

"Easy fix" is what introduced me to the QGIS code (and maybe to GH). It
makes things less intimidating, particularly when you are not a developer
(not all the issues require to be a master in coding) and this is what i
from time to time use to check in redmine. And TBH, this is the first
filter I applied to the new list in GH. The issue is that in Redmine, the
easy status was often decided by the reporter and I'm not sure they always
knew the internals of the code before tagging (though i might admit that
it's not simple to identify what is easy for others).

About the weirdness to keep bugs that are easy to fix, yes it's weird but
it's the price to pay to attract new contributors. And there are issues
that don't really hurt the project if kept unfixed. In docs we have an easy
label that we spend as much time to label and add guidance than we'd spend
to fix the issue but from time to time (unfortunately not as frequent that
i wish) there's a new contributor who picks one and fix it. And at that
moment, you see the benefit.
One thing we can do, or maybe did I miss it for the recent releases, is to
make a real call when we move to feature freeze. I did not see a call for
this one and got the information in irc; not all potential contributors
follow the countdown at qgis.org. Without a clear call inviting testers,
extending bug fixes time would not have more benefit. But other than
testers, we can add a focus on the "easy fix" label inviting people that
want to contribute to give them a shot. And if a week before the release
there still are "easy fix" issues, core devs can clean them if they want.

just my 2cts
Harrissou (a non dev that is often happy to fix code and want the process
to be easy for him)

Le lun. 27 mai 2019 à 06:30, Denis Rouzaud <denis.rouzaud at gmail.com> a
écrit :

> Hi all,
>
> May I also suggest to create a "wontfix" label?
>
> Le dim. 26 mai 2019 à 21:46, Denis Rouzaud <denis.rouzaud at gmail.com> a
> écrit :
>
>>
>>
>> Le dim. 26 mai 2019 à 21:38, Nyall Dawson <nyall.dawson at gmail.com> a
>> écrit :
>>
>>> On Mon, 27 May 2019 at 11:43, Denis Rouzaud <denis.rouzaud at gmail.com>
>>> wrote:
>>>
>>> > +1. But, we should indeed have a strict definition of when adding the
>>> milestone (someone is taking care of the fix or every time it's just
>>> considered as important). I'd rather keep milestones for PRs and maybe
>>> bring back the idea of "blocker" tag.
>>>
>>> I think it should only be defined by someone actually assigned to the
>>> bug. E.g. if I self-assign a bunch of bugs I'm actively working on,
>>> I'd like to be able to use milestones to self-manage these...
>>>
>>
>> I see, I'm just afraid to see too many issues left-open with a past
>> milestone.
>> But we can give it a try I guess.
>>
>>
>>>
>>> Nyall
>>>
>>>
>>> >>
>>> >>
>>> >> Nyall
>>> >>
>>> >> * Ideally, we'd block non-core-contributors from setting milestones
>>> >> for issues, to avoid reporters just tagging their issue with an
>>> >> upcoming milestone as a rude way of saying "fix my stuff for me"
>>> >> _______________________________________________
>>> >> 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
>>>
>> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190527/cd7da701/attachment.html>