Summary

Add 3 very common troubleshooting steps to the issue template to help both users and maintainers/contributors

• Hopefully addresses the most common pattern that I noticed in the issues per fix(github): improve formatting of issue template spoilers #311 (comment)

Details

• these steps should help in 2 ways:

  1. hopefully avoid common misconfigurations from being repeatedly opened as bug reports
  • some of these have labels on them now to get a sense of how often they pop up
  2. help contributors and maintainers diagnose issues quicker as well as figure out if an issue is indeed a bug
  • the diagnosis questions are really common things we ask in an issue already, so think it would work out better to get that up-front
    • we have labels for some of these too
    • especially as issues can often get no response / go stale, and if it's truly a bug, it's better to know that earlier than later

• condense the CONTRIBUTING.md a bit now that some of the most common debugging steps are in the issue template

  • didn't put in npm prune or clean: true yet, as don't want to make the issue template too big overnight
    • those also aren't as common an issue and people seem to figure out that an issue is due to caching bugs pretty often already

Next Steps

In somewhat of an order:

• get a repro environment functioning and add it to the issue template repro question
• probably want to move to GitHub's new beta Issue Forms moving forward, but thought it'd be best to get the details into Markdown first, then can migrate
  • and also creating Issue Forms seems to require moving to the multiple Issue Templates format where users select a "type" of issue (e.g. bug report vs. feature request etc), but we don't have multiple templates yet, so that could be confusing
• write up a small PR template, basically the main sections I use in my PRs like everywhere ("Summary", "Details", and maybe some optional sections like this one)
• write up a small feature request template (mentioned in Add schema checking for plugin options #312)

If needed, in the future we can add the npm prune, clean: true parts of the CONTRIBUTING.md to the troubleshooting steps. Similarly, we can ask if people have read the CONTRIBUTING.md as well if needed (in issue forms, that's a common checkbox and is an example in the docs). "Search terms" like the TypeScript repo has could be useful in the future as well and are gaining some traction in repos nowadays too.