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

[Denis Rouzaud]

Hi Nyall,

I generally completely agree with all the points you raised, some comments
below

Le dim. 26 mai 2019 à 18: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!
>
> 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)
>
> - "Database" label: should this be renamed "db manager", to
> disambiguate from postgis/spatialite/etc issues, which instead belong
> under "data providers"?
>
> - 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.


> - "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!
>

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.

>
> - "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
>
> - "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.
>
> - 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?
>

+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.

>
> 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/20190526/b6975844/attachment.html>