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

Nyall Dawson nyall.dawson at gmail.com
Sun May 26 16:06:35 PDT 2019


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!

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

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"


More information about the QGIS-Developer mailing list