Update issue templates

[styfle]

This adds templates so users are prompted when they create a new issue.

[joshbruce]

I like the idea but not sure about these as options. Wondering if we could reformat the issue template we have into two or three types from GitHub.

The quality of issues in my opinion since creating the template we're using now.

Bug report, feature request, and proposal??

[UziTech]

could we also add the demo links to a bug report.

[styfle]

@UziTech I added demo links

@joshbruce What is the difference between Feature Request and Proposal?
And can we add that in a later PR?

[joshbruce]

@styfle: I think

• Issue: Marked says it does this thing but doesn't.
• Feature Request: Marked doesn't do this thing and I think it should
• Proposals: Kind of an "other" bucket with direction could be and might have nothing to do with the code, "I think badge X is awesome, you should add badge X to the README" or "I think we should operate things a bit differently"..."have you seen this tool"...that sorta thing. We as the core have other channels, this is the public channel.

The most vibrant communities I've seen have a way to hold public discourse on all sort of topics. I've seen giving folks a way to report a defect, requesting a feature, and "other" (propose something) as beneficial...some of the tickets I closed fell into this category and I personally tend to use that channel myself.

[joshbruce]

ps. I definitely think our current issue template has proven itself worthy. These don't seem like us and maybe overly generic.

[styfle]

@joshbruce I updated the descriptions like you suggested and made the template shorter.

Do you have an idea for the contents of the Proposal template?
Can the Proposal template be added in a later PR so we can get an idea of how this works?

[joshbruce]

@styfle:

Do you have an idea for the contents of the Proposal template?

Sure. See current issue template. ;)

**Proposal type:** project operations | other

## What pain point are you perceiving?

## What solution are you suggesting?

Can the Proposal template be added in a later PR so we can get an idea of how this works?

I suppose - it's already there though and has been used by people other than me: #1108.

Again, my concern is that we seem to be heading into new feature world and thinking we have to replace the content we already have to get there. Again, our current template seems to work for our users and we can modify the content and put in the front matter which seems to be how GitHub knows what's going - no need to reinvent the content. Adding the feature request, which is currently part of the proposal type options in our current template.

[joshbruce]

Are we concerned that we don’t fully know how it works? We can always update later...just curious about any urgency for testing purposes. Sorry, again, just got back up with my laptop; so, I’m behind on Marked conversations.

[styfle]

@joshbruce Ok I added the proposal template.

The first two templates "Bug" and "Feature" were generated by GitHub and I like the simplicity of them. Our current template has too much going on in my opinion...43 lines is kind of off-putting if you're a first time contributor.

Here's what it was before:

**Marked version:**

**Markdown flavor:** Markdown.pl|CommonMark|GitHub Flavored Markdown|n/a

<!-- The NPM version or commit hash having the issue --> 

<!-- 

	If submitting something other than a defect with Marked itself, please use the following:

**Proposal type:** new feature | project operations | other

## What pain point are you perceiving?

## What solution are you suggesting?

-->

## Expectation

**CommonMark Demo:** [demo](https://spec.commonmark.org/dingus/)
<!-- You can replace the link above with a permalink from: https://spec.commonmark.org/dingus/ -->

<!-- Describe the output you are expecting from marked -->

## Result

**Marked Demo:** [demo](https://marked.js.org/demo/)
<!-- You can replace the link above with a permalink from: https://marked.js.org/demo/ -->

<!-- Describe the output you received from marked -->

## What was attempted

<!-- Describe what code combination got you there -->

<!-- 
	If error is thrown add the following:

## Call stack & console log

-->

[styfle]

Are we concerned that we don’t fully know how it works?

Yes, I'm not sure how it works and it would be good to see it in action. I don't know of a way to try it out this without merging to master.

[joshbruce]

Can we put the marked version and markdown flavor? Think it's been a beneficial addition and a good recommendation.

[styfle]

The marked version is in step 1 below but I can make it a separate question so it's more clear.

[styfle]

Now I remember why, I decided to tell them to use the demo to see if they can reproduce, that way we can easily see the bug with one click. I then suggest more specific steps to repro if the bug doesn't show up in the demo (that might mean they're not using the latest version).

I'm open to suggestions with how to reword this one.

[joshbruce]

Funny enough I got thinking we could have two bug reports - one using the demo and one without...still debating that one. If this PR is mainly for testing the concept of buttons and not focused on the templates then we can probably do the merge and I might come in behind with a PR using UX-based considerations.

One of the things we've been doing with the previous template was to make the desired template easy to access and let people opt in to alternative templates and complexity the less users have to do themselves the better is the general rule. Then, from journalism, using the inverted pyramid to present more general information to more detailed: What version? What options? What did you do? What did you expect? What did you get? (Believe these are out of order in our current template actually.) Then fewer words.

[joshbruce]

I tend to agree that there's a lot going on in the current template; however, that's also partially because we couldn't do something like this. For the most part there are three headers just like here.

[styfle]

Yeah you're right, it was making the user delete a bunch of text before. Now they'll get to choose with buttons

[joshbruce]

Not feeling this set...it has some potential overlap with a bug report. If it's cool with you, once we merge and verify I might submit another PR as follow up. (To the line count comment combined it's the same count. :) )

Don't think the marked version makes sense here.

[styfle]

Yeah there's room for improvement. But after reading through it a couple times, I think it makes sense. A feature request should be rooted in a problem that needs to be solved.

Maybe we can change this question to say something like "Why is this feature valuable?"

[joshbruce]

Definitely think language choices can be made better from those given to us by GitHub. (See previous comment.) Think "why is this feature valuable" is an improvement. A feature request, in my opinion, is less about solving a problem (makes me think of bug) and more about ideas...I recommended iTunes offer a way to purchase rented movies, for example...not a problem, just an idea that could improve UX.

[styfle]

Yes, but in your example about iTunes offering a way to purchase rented movies, you do have an implicit problem that has not been stated. Maybe the problem is that you can't watch rented movies more than once, so buying it solves that problem.

I'll change this to "why is this feature valuable" so we can at least get a Why from the person requesting it.

[joshbruce]

This one is where having the marked version made the least sense - but that was the limitation of having to put all three in one.

[styfle]

I'm confused. There is no version requested for the Proposal template.

[joshbruce]

I know. I was pointing out the duplicity required by the current issue template solution. :)

[joshbruce]

To the reference of the current one, thinking we could divide it into three without having to change verbiage or formatting (because it does serve three disparate purposes because it used to be the only way.

Bug

**Marked version:**

**Markdown flavor:** Markdown.pl|CommonMark|GitHub Flavored Markdown|n/a

<!-- The NPM version or commit hash having the issue --> 

## Expectation

**CommonMark Demo:** [demo](https://spec.commonmark.org/dingus/)
<!-- You can replace the link above with a permalink from: https://spec.commonmark.org/dingus/ -->

<!-- Describe the output you are expecting from marked -->

## Result

**Marked Demo:** [demo](https://marked.js.org/demo/)
<!-- You can replace the link above with a permalink from: https://marked.js.org/demo/ -->

<!-- Describe the output you received from marked -->

## What was attempted

<!-- Describe what code combination got you there -->

<!-- 
	If error is thrown add the following:

## Call stack & console log

-->

Proposal

**Proposal type:** project operations | other

## What pain point are you perceiving?

## What solution are you suggesting?

Feature request

<!-- describe the desired functionality and any alternatives you have attempted -->

Dividing them this way gives us clarity into what might be the problem child of complexity - the defect one...but people seem to be doing okay even with that complexity.

[joshbruce]

Appreciating the updates to the feature request. Gonna be catching up on some things elsewhere but want to drop by as I'm going through emails.

[styfle]

@joshbruce Any other changes requested?

[joshbruce]

Not at this time. I do prefer headers over just making things bold - improved distinction. Let's see if it works.