<div dir="ltr"><div>Hi Nyall,</div><div><br></div><div>I generally completely agree with all the points you raised, some comments below</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 26 mai 2019 à 18:06, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">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">Hi all,<br>
<br>
Once again, many many thanks to the individuals behind the the recent<br>
issues migration. Fantastic job all round!<br>
<br>
I'd like to do some post-migration cleanups, but would like wider<br>
opinions on how to handle these:<br>
<br>
- We have two labels "bug" and "bug fix" which apply to issues and<br>
pull requests respectively. Can we combine these, and just use "bug"<br>
for bug fixing PRs? (There's a LOT of labels now)<br>
<br>
- "Database" label: should this be renamed "db manager", to<br>
disambiguate from postgis/spatialite/etc issues, which instead belong<br>
under "data providers"?<br>
<br>
- Can "CAD" be merged into "Digitising"? There's only a handful of<br>
open issues, and I don't think it warrants a separate category. In<br>
QGIS these two concepts are basically merged now anyway. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- "Easy fix". Does anyone actually use this? Many of these are not<br>
"easy fixes" -- e.g. I've been chipping away at<br>
<a href="https://github.com/qgis/QGIS/issues/28195" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/issues/28195</a> since last year... it's<br>
probably about the hardest fix I've ever done in QGIS. No idea how<br>
this one gained the label!<br></blockquote><div><br></div><div>I'm +0 here. I liked the idea of easy fixes for new comers. On the other hand, it's a bit weird to keep "easy" fixed issues. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- "Editing": This label is very vague -- it's being used for<br>
digitizing issues, project editing issues, copy/paste issues, and even<br>
data provider issues. I'd argue we could drop this label and use other<br>
existing, more specific labels instead<br>
<br>
- "Feature request" / "Feature": I'm not sure how we'd go about<br>
merging these two categories, but it seems strange to have the two<br>
separate.<br>
<br>
- How should we handle milestones now? We've been using them up till<br>
now to tag PRs with their target version, and closing off milestones<br>
as each release is made. Now we've got a whole lot of outdated<br>
milestones (e.g. 2.14) because we have issues which were tagged to<br>
these milestones from the old "affected version" property. I don't<br>
think this is correct use of the milestone functionality, and would<br>
like to see it used only for release management (i.e. if a bug has a<br>
milestone, it's being targeted for fixing in that version*, so bug<br>
reports should always have ONLY future version milestones, not past<br>
versions). This would mean we'd need to change the affected version<br>
handling to labels. Is everyone OK with this?<br></blockquote><div><br></div><div>+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. </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>
* 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></blockquote></div></div>