I've went ahead, cleared up some labels and implemented the Importance labels we were discussing.
I've already gone through the list of open bugs and applied the scheme, so they can be conveniently sorted by "label priority" now: https://gitlab.com/inkscape/inkscape/issues?sort=label_priority
Obviously there's still a lot of work which I hope we can tackle together. Most importantly we need to urge ourselves to keep our tracker clean and update bug status whenever possible (I've found a lot of untriaged or only partially triaged bugs already, and even some that have been fixed, but not updated accordingly).
On the upside we're receiving some invaluable help by Nathan Lee (https://gitlab.com/nathanal) who does not only do a great job at confirming and testing new reports, but also submitted various patches already!
Also Qantas94Heavy (https://gitlab.com/Qantas94Heavy) started to sift through the reports on Launchpad (even ahead of the nbug migration game!) and is doing some amazing progress.
Cheers, Patrick
Am 19.02.2019 um 01:25 schrieb Bryce Harrington:
Some additional bug management questions needing decided are included in this infra bug report:
https://gitlab.com/inkscape/infra/services/issues/4
More comments inline below:
On Mon, Feb 18, 2019 at 08:27:26PM +0100, Patrick Storz wrote:
Having worked with the tracker fo some time here's my list of items (in no particular order) that I feel need attention.
- *Milestones:* On Launchpad (LP) we used Milestones for targeting bugs (only occasionally, though) but more importantly for tracking in which release a fix landed. The latter seems of particular importance, as release notes rely on it heavily. I suggest to continue this practice and expand it to merge requests. However this requires us all to make sure to actually set milestones properly. Currently we often just close bugs without giving it further thought (GitLab even does that automatically for us if a suitable commit message is used), which would make it almost impossible to keep track of the issues fixed in a particular release. Even more so for MRs...
Yes, the workflow here is less structured than we had with Launchpad.
I agree that adding milestone labels is a good practice that we should recommend.
Linking to a MR, or even just pasting in the git commit message + SHA can be vital not only for communicating that the issue is fixed, but also where to find the fix (handy for packagers needing to cherrypick).
I'm a little unsure of how much we are going to be able to rely on people remembering to do this, though. Are there other ideas for how we could either enforce it, or implement something that'd do it mechanically for us?
- *Importance:* I feel that we need some mechanism to prioritize bugs. What is your take on creating a set of prioritized labels of the form "Importance: High" to replace LPs importance field? I propose to use "Critical -> High -> Medium -> Low". Even above critical I'd put the already existing label "Blocker". At the end of the list I'd rank "Feature request". Does this sound reasonable? Or is it too fine grained? Is handling "Blocker" and "Feature request" as additional importance labels fine or should they be separate?
"Blocker" should not be used here; it's more something that should be reserved for the discretion of the release management team. It shouldn't be designatable by reporters or bug triagers.
Every bug is of utmost importance to whomever reports it, and so it's natural to want your ticket to move to the head of the queue. Having a "Blocker" state settable by bug reporters is awfully tempting to achieve this.
However, in most cases I think what people really want is to note that they feel their issue is "Urgent", and maybe a "Regression". Those might be more practical, useful tags.
(We may also want to have an escalation process, separate from labeling, for the truly horrendous problems. However, between RocketChat and the mailing lists I suspect we're ok for now. This is already mentioned in inkscape/infra/services/issues/4).
Beyond that, I think "Critical" + Milestone (+ Assignee) should be adequate for identifying ultra-severe bugs. If we have so many Critical bugs that we need yet another state... well I think we must have bigger problems. ;-)
So, I think your four state list of importances is good, and will be straightforward to match with incoming Launchpad bugs. In SourceForge we had a 10-point level for importance, but honestly that was too fine grained and we mostly just used 3,6,9 iirc.
My guess is that developers care less about the importance level assigned to a bug (unless its marked Critical), and more about if the issue is a recent regression, or is against the section of code they've been focusing on lately, or has an active user to engage with, or needs an urgent fix.
I'm not sure labels are effective for tracking any of those, although I've noticed some bug trackers (Bugzilla I think) have importance and urgency as separate fields. Personally, for Inkscape, I think tracking urgency gets a bit fiddly. We don't have a strictly managed bug workflow, so it's very much a judgment call and won't map very well to reality. And, if we did want a stricter workflow we'd probably best look at the existing kanban functionality in gitlab first.
For Feature Requests we have this break out bug for reaching a decision:
https://gitlab.com/inkscape/infra/services/issues/22
From past discussions I've gathered the consensus is to hold feature requests separately from actual bugs.
"Feature requests" actually comprise a spectrum from highly detailed development plans, down to off-the-cuff random ideas and suggestions. Part of what needs decided is what slice(s) of that spectrum we wish to track, and where we want to track them.
My guess is if we allow some feature requests to commingle with the bugs, it will be hard to judge what should and shouldn't be included, so we could end up with a lot more piled into the tracker than we want. "Only Actual Bugs in the Issue Tracker" is a clear distinction that will be easier to control, I think. But I think we do need someplace for them to end up.
- *Labels:
- o A general question is what labels we want to apply and how many there should be. I'm a bit torn here, as a short list makes it easier to keep track of the existing labels and avoids similar issues being tagged differently, especially if there are multiple similar choices or one tag is a sub/superset of another. A longer list would help us categorize issues better though. (For example: Do we want a tag for every packaging option we have, e.g. AppImage, Flatpak, msi, exe, Windows Store, ...? Do we want a tag for every Linux distribution or just a single "Linux" tag?).
Yes, this is a good question.
As a general philosophy, it may help to think, "Will this label help towards getting the bug closed?"
I could see how having labels for issues specific to particular packaging systems would be helpful - they'd enable those maintainers to search for their bugs, and enable developers to ignore them. However, I also wonder if it would be better if the packagers themselves had their own separate bug trackers that focus on problems specific to that package. For Ubuntu, Fedora, etc. there are already external bug trackers (Launchpad and Bugzilla), and no need to duplicate efforts there; but for non-Linux packages it might make more sense.
Where this may crop up in particular is for serious bugs that are fixed in master, but need to be cherrypicked and hotpatched into the packaging. We'd want those types of bugs marked Closed in our main tracker since they are, indeed, resolved, but the packager would want to have an open bug until they've had a chance to tackle it.
Beyond that, and in general, there is probably a balance between "adequately categorized" and "over categorized", which is going to depend a lot on the workflow of developers. For example, labeling Gtk2, Gtk3, and Gtk4 issues distinctly would likely be useful, whereas labels for what part of the UI the issue appears in may be less helpful.
So, using the general philosophy mentioned above, I think labels should be added where they enable developers to filter large classes of issues they do or do not care about. I imagine this could include crashes, regressions, SVG spec problems, file I/O, etc.
o Another question is if we want to categorize them (e.g. "OS/Linux", "OS/Windows", "OS/Mac") or if we strip the category? The former ensures similar tags are sorted together (otherwise they're sorted alphabetically) and *if* one remembers the category name it makes it easy to get all relevant tags by simply typing "OS", but then again tagging with just "Windows" seems more natural and the category might add noise. Also it obviously requires some thought in order to create useful categories (in contrast to just applying "random" tags that fit and creating new ones on-the-fly). As I'm somebody who likes order I tend to prefer categorization, but this is something I'd like your opinion on. (Important note: The search is clever enough to give you "OS/Windows" if you search for "win").I've been using the web interface for adding labels, so if they are prefixed with "OS/" that seems not to be a problem there. Being able to organize them alphabetically seems really handy, and adopting a consistent scheme will aid predictability. Once one got used to the convention, then even tagging via slash commands or via email (if that's possible) should be sufficiently convenient.
- *Status *On LP we had a detailed status field (new, confirmed, triaged, in progress, fix commited, fix released - also: incomplete, opinion, invalid, won't fix). Which of those do we want to replicate in GitLab (and how?). We could obviously create a label for each of them, but I have a feeling without a dedicated field it'd not be used consistently. One idea: o "new/confirmed" should be covered by "inkscape/inkscape" vs "inkscape/inbox". Only confirmed issues should ever end up in "inkscape/inkscape" (everything else should be confirmed or moved to the inbox for triaging).
+1 agreed
o "triaged" would be replaced by the presence (or absence) of an "Importance:" label should we choose to use them.Yes, WFM.
o "in progress": We already have a corresponding label and could use it. Alternatively we could define that all assigned bugs are "in progress" (i.e. only assign bugs if the assignee is going to work on them eventually; un-assign otherwise)In my experience developers are horrible about remembering to toggle this state when they're actually working on a bug. It is usually pretty obvious in context since they'll be commenting on it or have an attached MR under way.
There are probably situations and development workflows where it makes sense to have this. It may be useful if we're utilizing kanban, for instance.
If developers feel it helps them organize their bugs they're currently working on vs. ones they plan to do later, it may be worth having this or similar tag. If not, then it's a superfluous tag we should drop.
o "fix commited/fix released": I don't know how to replicate this reasonably. Is it even required?I don't know how to replicate it either. I'd call it a nice-to-have rather than required.
o "incomplete": We have "Need info" but such bugs should usually not be kept in "inkscape/inkscape" for extended periods of time (if the info is not given, close or move back to "inbox")Yes, agreed in general.
However, there are many situations where the bug is pretty well defined, and easily reproducible, but there still isn't enough info for the developer to work on it. E.g. they may need the user to run a special build, or test out a diagnostic patch, or something.
o "opinion": should never exist in "inkscape/inkscape" o "invalid": Do we need a label? Or shall we just close in this case and forget about it? o "won't fix": should usually not make it into "inkscape/inkscape" - do we want a label or shall we just close (i.e. same question as as for invalid?)There are so many different reasons why a bug might get closed. In addition to those three is also "Not our bug" and "Not actually a bug".
I don't think we need labels for each contextual reason.
Better practice would be to include a message at time of closure indicating a) the fix (e.g. git commit msg + SHA), or b) a short explanation of the reason why it is being closed.
- *Assignee* As suggested above we could use the assignee field to put devs who are going to work on an issue eventually (i.e. indicate "this issue is being looked into / will be looked into shortly"). Alternatively we could use it to indicate devs who are likely to be able to fix the issue and are most suited for detailed triaging and further investigation (i.e. indicate "we know somebody who might be able to help, please wait until they find the time to check"). This could be used to distribute and direct the workload a bit. However we can likely do that with simple @mentioning?
I tend to prefer letting developers assign themselves bugs, except for specific situations (like if they've created a regression, or if the release team needs to direct attention on an urgent matter).
So, I really like the @mentioning approach. It flags attention without committing them to owning the issue.
Sorry for the long text (I hope you all read up to this ;-)), it certainly got longer than intended... I'm looking forward to your opinions, though!
Thanks, all good issues I have been wondering about too.
Where do you think we should document these bug management guidelines? A file in the inkscape/doc directory? Or wiki?
Bryce