Issue Prioritization and Triage

Triage process

Generally all issues in the same category will be triaged by the same core developer, so this will hopefully make it easier to identify duplicate issues
The issue may be closed and linked to a duplicate
There is an issue disambiguation page at: https://github.com/spack/spack/wiki/Issue-Disambiguation

Examine each tag that the user assigned to the issue and decide whether you think it applies.
- E.g. sometimes people say that something is a bug when actually it's a feature request
They may also add the help wanted and good first issue labels (see https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels)
You can decide to add other labels that summarize the nature of the issue (e.g. if it appears to be an issue with fetching source)

If the person doing the triaging feels there isn't sufficient information, then they may request more information before assigning the bug

Assign a tag which indicates the impact/severity of the issue. The impact tags are:

Which tag to assign is up to the discretion of whoever does the triage but generally reflects an estimation of (a) severity and (b) reproducibility.

Is it an issue with Spack core?
- If a bug in Spack is preventing the build from proceeding, that significantly increases the impact
Does it affect the package build, or does it affect modules?
- If the package can build, that lowers the impact
Does it affect one build or multiple?
Is it a feature request or a true bug?
- If we claim to do something and it doesn't work, that's a bug
- If Spack doesn't claim to do something then it's a feature
Is the issue reproducible?
- If it can be reproduced on a stock docker ubuntu or fedora image, then that increases the impact
- If there is a script to reproduce the error without doing installs, that increases the impact
If there is a workaround (e.g. a config.yaml change) then that lowers impact
If the reporter of the issue suggests a fix then that increases the impact