Create a new issue template for non-VS Code editor users

[st0012]

Motivation

To make sure we can properly report and investigate issues for the Ruby LSP project, we need to create two different templates: one for VS Code and another for non-VS Code editors. Here's why:

1. Maintainer Expertise: Our maintainers mainly use VS Code and don't have setups for other editors. This means we can give better guidance and support for issues in VS Code but not as much for other editors.

2. LSP Compatibility: Different editors and their LSP plugins might not always be up-to-date with the latest LSP specs. This can cause differences in how issues show up between VS Code and other editors.

3. Reporting Tools: Our VS Code extension has specific tools for reporting issues, like a status panel and an addons list, which aren't available in other editors. These tools are super helpful for diagnosing and fixing issues in VS Code.

By having separate templates, we can make the issue reporting process clearer and get the most relevant info for each setup.

Implementation

Automated Tests

Manual Tests

[vinistock]

I understand the goal behind this, but I do have one concern. When we had different repositories for the VS Code extension and the server, it became clear to us that users don't really know when a bug is in one or the other (nor do they have to know).

If we create two separate bug templates (VS Code vs other editors), a similar situation may occur. For example, if someone using an editor other than VS Code discovers a bug in the server (which impacts all editors), this will increase the likelihood that it will be reported as a non VS Code bug.

How do we handle that scenario? Is the idea that we will still triage issues reported about other editors to ensure that they're not server bugs? And if that's the case, in what way is that different than our current triage?

[st0012]

@vinistock The main goal here is to set a clearer expectation and steps to follow to users who want to report issues.

If a problem is on server and is reported by non-VS Code users, there are 2 scenarios:

1. It's affecting VS Code users too
2. Somehow it doesn't affect VS Code (like the problem described in Fix Ruby LSP formatting range to comply with LSP specification #2438?)

For 1, we should receive issue report from VS Code users anyway so we won't miss any signal.
For 2, if users do follow the instructions to have discussions on Slack or other issue trackers first, that additional information should help us investigate issues.

Is the idea that we will still triage issues reported about other editors to ensure that they're not server bugs? And if that's the case, in what way is that different than our current triage?

So yes, we still triage all issues but prioritize issues with vscode labels. And in the meantime, if users do follow the instructions, non-vscode issues should be reported a bit less frequently but also has richer context when it's opened.

[vinistock]

Let's give it a try and see how it works