New Issues Template

[virkt25]

I think the current issues template is super complicated and cluttered, making it harder to create an issue. See below for the original template.

<!--
Questions:
  https://groups.google.com/forum/#!forum/loopbackjs
  https://gitter.im/strongloop/loopback
Immediate support:
  https://strongloop.com/api-connect-faqs/
  https://strongloop.com/node-js/subscription-plans/
-->

# Description/Steps to reproduce

<!--
If feature: A description of the feature
If bug: Steps to reproduce
-->

# Link to reproduction sandbox

<!--
Link to an app sandbox for reproduction

Note: Failure to provide a sandbox application for reproduction purposes will result in the issue being closed.
-->

# Expected result

<!--
Also include actual results if bug
-->

# Additional information

<!--
Copy+paste the output of these two commands:
  node -e 'console.log(process.platform, process.arch, process.versions.node)'
  npm ls --prod --depth 0 | grep loopback
-->

Expected Result

Issues template should be simple and easy to understand. Example / Proposed version below.

## Type
- [ ] Question
- [ ] Feature
- [ ] Bug / Issue

<!--
Bug / Issue => Include: Actual Result, Expected Result, Versions, Link to Sandbox (if available)
For Versions => Copy+Paste the output of these commands:
  node -e 'console.log(process.platform, process.arch, process.versions.node)'
  npm ls --prod --depth 0 | grep loopback
-->

## Description / Steps to Reproduce

Related to #47

[virkt25]

With the new CONTRIBUTING doc, I now see a message before making an issue. Wonder if new users see that and if it can mean a simpler template

[dhmlau]

I wonder if we want our users to include the package name / function area: https://github.com/strongloop/loopback-next/blob/master/MONOREPO.md#packages.

Just an example.. If someone is trying out the example-getting-started and having problem, it would help us by putting the pkg name on the title or the issue description. For obvious things, we can encourage them to put this info.

[raymondfeng]

Let's create a PR to capture the proposed template. It will make the commenting/reviewing simpler.

[dhmlau]

I'll leave it as part of the task for #47 then.

[bajtos]

I agree the current template is too complex and should be simplified 👍

## Type
- [ ] Question
- [ ] Feature
- [ ] Bug / Issue

Please don't use checklists as a replacement for radio buttons. GitHub shows completed + total number of items from checklists in GitHub issue list (see list of pull requests to see yourself). We don't want every user-reported issue to say "1 of 3" in the listing.

Regarding issue type in particular, we used to have a checklist like that in the past and it did not work well. In my experience, users often don't know what is the type of their report. Things that look like a bug to them may be considered as a missing feature by us. Discussions that start like a question can often evolve into a bug report or a feature request.

IMO, the issue template should ask the people to provide the information that is needed to meaningfully reproduce the issue on our side. This typically includes:

• Steps to reproduce, including a sandbox app or at least code snippets
• Actual result - what happened?
• Expected result - what is the user expecting instead?
• Version - LoopBack version, Node.js version, etc.
• What workarounds has the user tried? What were the results?

I was filling a TypeScript issue recently, I found their template pretty nice and helpful even for myself as an issue reporter: https://raw.githubusercontent.com/Microsoft/TypeScript/master/issue_template.md

[bajtos]

Regarding issue type in particular, we used to have a checklist like that in the past and it did not work well. In my experience, users often don't know what is the type of their report. Things that look like a bug to them may be considered as a missing feature by us. Discussions that start like a question can often evolve into a bug report or a feature request.

IMO, the issue template should ask the people to provide the information that is needed to meaningfully reproduce the issue on our side.

The decision whether an issue is considered a bug, feature or a question should be left up to us, maintainers/triagers to decide. We should use issue labels to mark an issue as a bug or a feature.