Hi, Le lun. 27 mai 2019 à 01:06, Nyall Dawson <[email protected]> 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
