Improve issue templates

[LeeLenaleee]

Improve issue templates so there are imput fields so you cant accidentally put things in the commented out blocks that are there for info.

Working examples of the new issue format can be seen in my fork here: https://github.com/LeeLenaleee/Chart.js/issues

Edit: This way also provides it so reproducable examples should always be present because otherwise the submit issue button cant be pressed (you can still type a random char to make it valid but I think this will make it a lot less comon)

[kurkle]

Nice!
Only thing I doubt whether it's good or not, is the requirement of example for documentation issue?

[LeeLenaleee]

Aah yes thanks, didnt notice that one after copying it. Removed it

Edit
Thought I copy pasted it and forgot to remove it but seems in the current docs issue template there is also a part about a reproducable sample.

Looking through the first 25 documentation issues I see not a lot of people use it but some people use it for clarification of their problem. Either with a ts playground link or codepen that shows what they mean.

So I think its still valuable to have it there but not require it so let it be optional.

[LeeLenaleee]

Re added the example for the docs as an optional element.
Also added a default basic config for with TS playground for TS issues to the bug report and example for docs

[kurkle]

I had one doubt about grammar.

On a related note, I think we should encourage reporting issues to wrapper repositories when those are in use and required in the reproducible sample. (by wrapper I mean react-chartjs-2 for example). This could be done for example by adding links to templates for those libraries and suggesting there to try to reproduce the issue without the wrapper and if not possible then positing the issue to the wrapper repository directly.

[LeeLenaleee]

I think it should be better instead to not add links to sandboxes for wrapper libs since you will encourage people to use them to submit there issue to us. And I know from my own experience that I don't always read further if I see the thing that applies to me, so when I see a sandbox link for the react wrapper I might not read further in all cases to not use it and try to do it in plain js.

I think it would be better then to only place the text like if you are using a wrapper around chart.js please try to reproduce the issue in the above given plain js template. If this is not possible please report the issue to the wrapper maker instead.

[kurkle]

I think it should be better instead to not add links to sandboxes for wrapper libs since you will encourage people to use them to submit there issue to us. And I know from my own experience that I don't always read further if I see the thing that applies to me, so when I see a sandbox link for the react wrapper I might not read further in all cases to not use it and try to do it in plain js.

Exactly why I thought the explanation should be in the sandbox, because that is what the user is going to click.
But then the sandbox should also make it easy to convert your use case to plain JS, and that could be challenging.

I think it would be better then to only place the text like if you are using a wrapper around chart.js please try to reproduce the issue in the above given plain js template. If this is not possible please report the issue to the wrapper maker instead.

I don't disagree on that point either. But I think we can leave it as is for now and act later if "wrapper issues" start to be annoying.

[LeeLenaleee]

Noticed the vue sandbox is bit bugged, will fix that tommorow

Edit
Seems like a codesanbox issue, it doesnt want to install the modules on initial load but after your refresh the page it seems to work fine