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

[Régis Haubourg]

Hi,

Le lun. 27 mai 2019 à 01:06, Nyall Dawson <nyall.dawson at gmail.com> a écrit :

> Hi all,
>
> Once again, many many thanks to the individuals behind the the recent
> issues migration. Fantastic job all round!
>
+1 !

>
> I'd like to do some post-migration cleanups, but would like wider
> opinions on how to handle these:
>
> - We have two labels "bug" and "bug fix" which apply to issues and
> pull requests respectively. Can we combine these, and just use "bug"
> for bug fixing PRs? (There's a LOT of labels now)
>
+1

>
> - "Database" label: should this be renamed "db manager", to
> disambiguate from postgis/spatialite/etc issues, which instead belong
> under "data providers"?
>
+1

>
> - Can "CAD" be merged into "Digitising"? There's only a handful of
> open issues, and I don't think it warrants a separate category. In
> QGIS these two concepts are basically merged now anyway.
>
+1

>
> - "Easy fix". Does anyone actually use this? Many of these are not
> "easy fixes" -- e.g. I've been chipping away at
> https://github.com/qgis/QGIS/issues/28195 since last year... it's
> probably about the hardest fix I've ever done in QGIS. No idea how
> this one gained the label!
>
Let's keep the label as an attempt to help new contributors to board in.
Core dev's shouldn't be shy about removing the "Easy fix" tag when they
know it's not easy :)

>
> - "Editing": This label is very vague -- it's being used for
> digitizing issues, project editing issues, copy/paste issues, and even
> data provider issues. I'd argue we could drop this label and use other
> existing, more specific labels instead
>
+1

>
> - "Feature request" / "Feature": I'm not sure how we'd go about
> merging these two categories, but it seems strange to have the two
> separate.
>
+1 . the label list was discussed only using the redmine candidates and we
forgot to check duplicates already in the QGIS github repo.. Let's solve
this.

>
> - How should we handle milestones now? We've been using them up till
> now to tag PRs with their target version, and closing off milestones
> as each release is made. Now we've got a whole lot of outdated
> milestones (e.g. 2.14) because we have issues which were tagged to
> these milestones from the old "affected version" property. I don't
> think this is correct use of the milestone functionality, and would
> like to see it used only for release management (i.e. if a bug has a
> milestone, it's being targeted for fixing in that version*, so bug
> reports should always have ONLY future version milestones, not past
> versions). This would mean we'd need to change the affected version
> handling to labels. Is everyone OK with this?
>
>  milestone is a target, affected version is a descriptive information for
a bug. I don't see any milestone define in the repo. Did you already clean
this up? I'm not sure I get your point in fact, the affected version is
only a text comment in the issue body from what I see. Did I miss something?


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190527/6ac7e131/attachment.html>