Bug management for inkscape/inkscape

Hi all,

it seems the message of our move of issue tracking to GitLab is slowly 
spreading and we're seeing a steady flow of new reports in our 
inkscape/inkscape issue tracker on Gitlab 
(https://gitlab.com/inkscape/inkscape/issues).

As most of us had the opportunity to get some first-hand experience with 
the new issue tracking by now and with the amount of bugs still being 
manageable, it seems to be a good time to discuss and decide on some 
guidelines for this tracker, so we can make most efficient use of it.

Having worked with the tracker fo some time here's my list of items (in 
no particular order) that I feel need attention. Please add to it as 
needed and most importantly discuss, so we can find solutions that work 
well for all of us. (We can obviously break individual topics out into 
GitLab issues eventually, once we have set a rough direction).

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

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

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

  * *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).
      o "triaged" would be replaced by the presence (or absence) of an
        "Importance:" label should we choose to use them.
      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)
      o "fix commited/fix released": I don't know how to replicate this
        reasonably. Is it even 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")
      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?)

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


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!

Cheers
Patrick

_______________________________________________
Inkscape-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel