On Sun, Mar 10, 2019 at 07:20:48PM +0100, Patrick Storz wrote:

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

Great, was just looking at bugs and noticed the improved organization.

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

Agreed.

Btw, there's a mobile app for gitlab.  Handy for reviewing stuff in
Inbox when you're out and about.

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.

Excellent, it's always good seeing more people getting involved in triaging.

Btw, on the topic of feature requests, Ted, Martin, Tav, me, and others
had a discussion at hackfest on this in relation to keeping the roadmap
better updated, post-1.0, and sketched in some conceptual ideas.
Essentially, we'd build a gitlab issue board with the larger feature
plans, or "Big Ideas" as I think Ted called them.  We speculated
experimenting with using the gitlab kanban for organizing them, but
however we do it this would replace (or at least augment) the current
Roadmap in wiki.

We also recognized that with a volunteer organization where we encourage
devels to work on what interests them, rather than giving top-down
directives, our "roadmap" is more akin to a "forecast".  You may have
noticed a "ToForecast" label was added to the bugtracker; this concept
is where that term is coming from.

For planning purposes, we discussed establishing a regular monthly
meeting cycle to review feature proposals and scope out development
priorities.  This would be the "Forecast Party" that Martin mentioned in
email last week.  We also recognized that for UI/UX sometimes the
blocker on even easy things is to just have a decision made, so a
thought was that this event could include reviewing the month's UI/UX
change proposals that want to have decisions made, and make them.

Hit me with any other ideas.  I'll post a kickoff email for the first
meeting, for some time this month.

Bryce

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

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel