Github for issue tracking

Development
1

Now that we have moved to github, we need to update our process to capabilities of github’s issue tracker.

I’ve collected all the fields that were stored in Mantis and a proposal for how we could manage them from now on. I’ve tried to keep things simple (we can always make things more complex if needed) and be similar to Github’s defaults/recommendations, and other projects that our community uses (such as ITK).

Nothing to do (equivalent feature is available in github):

  • Reporter: (automatic username)
  • Assigned to: (username)
  • Target version: backlog, Slicer-4.11.0, Slicer-5.1.0 => in github milestone
  • Fixed in version: Slicer-4.11.0, Slicer-5.1.0, Slicer-4.10.2, … => in github milestone (if issue is fixed but then it turns out to be not fixed after all then a new issue should be created in the new milestone)

Move to issue reporting template:

  • Platform: (free text)
  • Product version: backlog, Slicer-4.11.0, Slicer-5.1.0, Slicer-4.10.2, …
  • OS version: (free text)
  • OS: (free text)
  • Reproducibility: always, sometimes, random, have not tried, unable to reproduce, N/A
  • Description
  • Steps to reproduce
  • Additional information

Move to labels (see github default labels: https://help.github.com/en/github/managing-your-work-on-github/about-labels#using-default-labels)

  • Priority: none, low, normal, high, urgent, immediate => priority:low, priority:normal, priority:high, priority:urgent
  • Severity: feature, trivial, text, tweak, minor, major, crash, block => this is a mix between type, priority, and severity; since we will have priority labels, probably it would be enough to use default labels: type:bug, type:enhancement
  • Status: new, feedback, acknowledged, confirmed, assigned, resolved, closed => use issue status (open/close) and github default labels: status:duplicate, status:invalid, status:question, status:wontfix + I would add status:in-progress (to indicate that the issue is not just assigned to someone but that person is actually working on that)

Discontinue:

  • Category: Core: Base Code, Core: Building (Cmake, Superbuild), Core: GUI, …. => this was used for automatic assignment of the issue. This was not very well defined, did not work very well (partially because email notifications were broken in Mantis), it would not be trivial to implement in github, and not that important anymore (since extensions are managed independently).
  • Resolution: open, fixed, reopened, unable to reproduce, not fixable, duplicate, no change required, suspended, won’t fix => these can be described in notes or associated commit comments

Any comments and suggestions are welcome. If we reach a general agreement then we can create labels and bug report and feature request templates accordingly.

2

Makes sense to me - thanks for working through this.

We want to use the issue reporting templates carefully. I find that unfortunately many of the templates are too long and full of instructions, but then users don’t fill them out. If you are watching the issues you end up with a long email that needs to be visually scanned in order to see if there is any non-template text it at all.

So let’s just use the fields you have laid out as the template.

We can also have multiple issue templates for different kinds of issue. I’m not sure yet how we can best make use of that feature.

3

Agreed. Long templates and many issue labels are quite annoying.

It makes sense to have different template for bugs and features (reproducibility, Slicer versions, etc. are not relevant for features). The issue template could be as simple as this:

Slicer version: Slicer-4.??.?-YYYY-MM-DD
Operating system: Windows / Mac / Linux + version
Description:

What you did, what you expected to happen, and what happened instead?
More information: https://github.com/Slicer/Slicer/blob/master/CONTRIBUTING.md#report-issues
4

One thing that needs to happen is to go through the backlog and triage / close issues on the git repo. A large number are currently already fixed / invalid (extension issue, etc)

1 Like
5

I’ve added bug report and feature request templates - see https://github.com/Slicer/Slicer/issues/new/choose

Feel free to submit pull requests or discuss here if you have any suggestions how to improve them.