Setup issue templates with checklist for history and other things

[daprahamian]

From #85 (comment), this is for setting up an issue template.

[daprahamian]

Thoughts on this:

• Probably want to have separate fields depending on if the issue is a bug/question or a feature request. For example, bugs / questions should have:
  • Expected Behavior
  • Actual Behavior
  • Steps to reproduce: Might be good to specify that this can be a code snippet and/or a repo, so long as someone can install them and immediately have it work.
• I think an Environments section should have specific sub-fields for:
  • OS
  • Js Environment (ex: Node 12.13.1, Electron 7.1.2)
  • Package manager version (ex: npm 6.1.0)
  • express Version
  • Any relevant extensions that are being used

[gireeshpunathil]

+1 to the format to begin with. However, in my experience people hesitate to fill-in so many details. May be we could omit OS, node and npm versions? I am not very sure whether there are os-dependent control flow exist in the project. May be @dougwilson and @wesleytodd will know better

[wesleytodd]

I agree, more simple is better to start. If we find that people are following the template and there is a specific type of error people run into which could be added to the template, great! Otherwise, KISS (keep it stupid simple).

[jonchurch]

Somewhat related, PR to create a PR template in Express: expressjs/express#4217

[jonchurch]

I've just learned that you can have issue templates auto apply labels, which sounds pretty rad. (I'm assuming that submitters don't need permissions in order for these labels to apply, but haven't tried it myself)

Even if we had super lean templates, forcing users to choose from Bug?, Question, Feature Request, Other would be a big step towards having things auto labelled into our biggest buckets.

I'd like to see us use these as initial states. Bug? specifically is important, because the majority of bug report aren't bugs until verified, but it gives you a pretty clear goal. Look at possible bugs, if you can repro, relabel as Confirmed Bug.

One option can be Security Issue which can prompt folks to report outside the issue tracker (which is current policy). Github has a method for directing folks to an outside place for certain types of issues in the issue chooser.

[wesleytodd]

So in looking at that pr, I am concerned that it is just more structure than is optimal. If someone has to fill in all that I am not sure it will actually add value and it just makes them do more work. If the structure is just thrown out when half the parts are not applicable it really doesn't help. I do like the idea of asking just type would add value if we auto applied the labels like you mention.

For bugs, how do you like bug report? I was a bit confused what you meant with the ? at first until I read more of your description.

For security, I think the answer is clear, just link them to the reporting docs and tell them not to open an issue. So this would be a separate template right?

[ghinks]

I would like to raise this issue again at the TC meeting 05-20-2020. I believe that even a modest template noting that the repo is maybe not the first place to start off with general app issues would cut down on the number of first time user questions.

From experience we know that asking for a small working piece of code that reproduces the issue often solves many application errors as the author is asked to step back and write a small piece of code to reproduce the issue.

[dougwilson]

I don't see it discussed yet, but should we put this in a .github repo so it shows up everywhere at once, or duplicate it across every repo by hand? I believe if we do have it central, it can still be overridden by a repo, but not sure. The trade off would probably be the central repo-based template would likely be generic in order to apply to all of the repos.

[jonchurch]

@dougwilson Yes I believe you're understanding is correct. A .github repo in an org will apply these types of files to all repos where the file doesn't already exist in a .github folder within the repo. I think a file being committed to a specific repo will override the org level ones.

[jonchurch]

I played around with this today, here are some examples. Checking the raw file content shows the comments that users will see when filling out an issue.

There's a config.yml file in there which allows you to specify links that show up in the issue template choooser. I.E. There is a button for "Security report" that links you to the Express Security.md file. The config file also allows you to disable opening blank issues, forcing folks to choose one from the template.

[dougwilson]

Oh, that is cool, @jonchurch ! I like how you can make buttons that go somewhere else and not an issue as well, that is very useful! Security is a great example. I bet we could even have one for how to do thing X go somewhere too.

I'd suggest that these types of links head out to our expressjs.com site. The security one, for example, has a section on a page on the site, but we could (and probably should) just have a page for each of these things on the site. I'm suggesting the site for the link out mainly because since that would show on all the repos, that probably seems the lest jarring (vs suddenly ending up in a different repo).

I wonder if (this is not needed, but curious for the future) if a repo could override that config.yml as well, perhaps to use a different security policy as an example. The global security link is really going to be the biggest win (imo) of it all, but all the rest are going to be useful as well.