Triage Checklist

1. Does the issue apply to this repository?
   • If not open new issue on appropriate repo and then close this one (and link to new issue), only if issue is clearly meant for and written for another project use the "Transfer issue" feature.
   • If not clear which project ping @holoviz/triaging-team
2. Check if it's an actual issue
   • If it's clearly a user question close and refer user to Discourse
3. Assign label(s)
   • Almost all issues will fall under bug or enhancement
   • If the bug is critical (i.e a showstopper), consider adding a hotfix level milestone
   • API discussions get discussion label and then ping @holoviz/triaging-team for opinions
   • If issue is blocked by work that needs to be done in another project add upstream label
4. Reproduce
   • If a bug try to reproduce as is during the meeting (one reason to have no more than two people triaging a project at once)
   • If example doesn't run try to fix it and update the user code or comment with the fixed code
   • If example still doesn't run ask for more information and add needs-info label
   • If example is very complex and you have trouble reproducing ping another team member to reproduce
   • Add versions you tested with in your comment whether you can reproduce or not
   • If you can't reproduce, either find PR that fixed the issue, try to reproduce with version specified in the issue or ping other team member to try to reproduce. If it cannot be reproduced after you've tried these steps close and ask user to reopen if they can reproduce the issue with latest versions.
5. Assign milestone
   • Bug goes in next micro release (x.x.X), unless release is imminent
   • Small enhancements with a high probability of being worked on soon go in next minor release (x.X.x), or (if next minor release is imminent) the following minor release (x.(X+1).0). The enhancement can easily get bumped to a later release during the release process, and eventually to the wishlist if we keep not getting to it, but at least that way it will get considered.
   • Enhancements representing a larger feature that requires sustained development go in wishlist as either open (something to try to get funding for or set aside time for) or as closed (meaning still on the wishlist, nice to have, but unlikely to be addressed by the core team). Items should be removed from the wishlist milestone if they are implemented, since both open and closed wishlist items are possible tasks to do.
   • Items on the wishlist or minor releases should be marked goodfirstissue if they seem tractable to people not on the core developer team