Create issue templates

[ferdnyc]

Add templates for bug, feature, and doc issues, based on GitHub's standard templates.

Also create an issue_template.md file for issues of other types, and configure the template selector to allow "blank" issues (which will use that template).

The templates suggest the title prefixes documented in CONTRIBUTING.md, but they'll also apply the relevant issue label (bug, enhancement, or documentation), which makes the prefixing sort of unnecessary/redundant really.

[kvid]

This might be something I would really like! What is the easiest way to test this functionality before merging? Do I have to e.g. cherry-pick your commit into the master branch of my personal fork, and create issues there?

[ferdnyc]

@kvid That's one option, but because I've already merged the branch to my own fork and enabled issues there, you're welcome to also experiment at ferdnyc/WireViz/issues.

[ferdnyc]

GitHub also supports issue forms, a more-complex type of guided issue creation that uses a YAML-defined HTML form; those are also an option. The feature is still technically in beta, but hasn't really changed in years so it seems pretty stable.

[ferdnyc]

Hi @kvid @tobiasfalk, just wanted to ping on whether there's still any interest in this PR? I know it was discussed some in the context of #251, and I see that there was a lot of work going on to shepherd that PR to completion until it finally became #447 and got merged a couple of months back. Totally understandable if there hasn't been time for much else, and maybe still isn't.

No real timeframe here, neither the PR nor my fork is going anywhere so it's still available for testing pre-merge. Just think of this as a once-yearly (or thereabouts) checkin, really. 😉

[tobiasfalk]

I think it is a good idea and merging it would improve hopefully the quality of issues

[kvid]

I'm sorry that I've been offline and not available for contributing for many weeks.

As I wrote earlier, I do like this idea, but unfortunately I've not had time to try it out as I wanted to. Maybe @tobiasfalk, @amotl and others have some time to try it out and describe their experiences (including advantages/disadvantages) in comments here?

Please also suggest a procedure for each developer to test later suggested improvements of the templates.

[ferdnyc]

Totally understandable, as we say at Wikipedia There Is No Deadline.

When it comes to testing suggested changes, the templates are just Markdown documents. Once the basic flow is enabled on the repo and people are familiar with it, just reading them is usually enough to evaluate changes.

With issue FORMS (which the files in this PR aren't) things are somewhat more complex, although again once they're in place, most changes can be evaluated by simple inspection.

To be tested, the templates/forms need to be placed on the default branch of any repo with issues / PRs / Discussions enabled. (There's support for PR and Discussion templates as well.) That can either be the submitter's fork, as I've done, or it could be a separate test repo created for the purpose.

But like I said, in my experience once a repo is over the initial hurdle of setting up templates/forms, inspection & review of future changes is usually sufficient prior to merge. (Any change will only affect the creation of new issues past that point, so worst case they can be tested after merge and reverted or tweaked if anything was overlooked.)

[ferdnyc]

because I've already merged the branch to my own fork and enabled issues there, you're welcome to also experiment at ferdnyc/WireViz/issues.

And in fact, doing so just now I spotted something I'd overlooked — I left the word "template" in the title of the "Documentation issue template", not realizing or forgetting that title is how it shows up in the New Issue template-selection list. So it was offering a choice of creating:

1. Bug report
2. Feature request
3. Documentation issue template
4. Blank issue

...I've now fixed that (to read just "Documentation issue"), both here and in my fork.