<div dir="ltr"><div>Hi</div><div><br></div><div>"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).</div><div><br></div><div>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.</div><div>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 <a href="http://qgis.org">qgis.org</a>. 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.</div><div><br></div><div>just my 2cts</div><div>Harrissou  (a non dev that is often happy to fix code and want the process to be easy for him)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 27 mai 2019 à 06:30, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com">denis.rouzaud@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>May I also suggest to create a "wontfix" label?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 26 mai 2019 à 21:46, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 26 mai 2019 à 21:38, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 27 May 2019 at 11:43, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> wrote:<br>
<br>
> +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.<br>
<br>
I think it should only be defined by someone actually assigned to the<br>
bug. E.g. if I self-assign a bunch of bugs I'm actively working on,<br>
I'd like to be able to use milestones to self-manage these...<br></blockquote><div><br></div><div>I see, I'm just afraid to see too many issues left-open with a past milestone.</div><div>But we can give it a try I guess.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Nyall<br>
<br>
<br>
>><br>
>><br>
>> Nyall<br>
>><br>
>> * Ideally, we'd block non-core-contributors from setting milestones<br>
>> for issues, to avoid reporters just tagging their issue with an<br>
>> upcoming milestone as a rude way of saying "fix my stuff for me"<br>
>> _______________________________________________<br>
>> QGIS-Developer mailing list<br>
>> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div></div>
</blockquote></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>