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:
  
• 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?).
• 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:
• "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).
• "triaged" would be replaced by the presence (or absence) of an "Importance:" label should we choose to use them.
• "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)
• "fix commited/fix released": I don't know how to replicate this reasonably. Is it even required?
• "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")
• "opinion": should never exist in "inkscape/inkscape"
• "invalid": Do we need a label? Or shall we just close in this case and forget about it?
• "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