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