github: Add simple issue templates & configuration

[neiljp]

What does this PR do, and why?

This converts the basic issue filing system to use the GitHub template chooser.

The main feature at this point is to focus reporters on the scope of the issue:

• major bug (bug: crash)
• bug (bug)
• missing Zulip feature (missing feature)
• general feature/improvement (enhancement)

These should apply a corresponding default label to the issue, with the idea that this would provide an initial structure to fine-tune the labels, eg. a specific parity label to add to missing feature, which could also gain one of the user or admin sub-labels.

This already feels like an improvement over the current single blank 'template', though it may take time to see how it works in practice.

This takes some ideas from zulip/zulip#26000 and followups.

Outstanding aspect(s)

• How do these categories look like, if you were filing an issue?

External discussion & connections

• Discussed in #zulip-terminal in Issue types #T1488
• Fully fixes #
• Partially fixes issue Adding Issue + PR Templates #830
• Builds upon previous unmerged work in PR #
• Is a follow-up to work in PR #
• Requires merge of PR #
• Merge will enable work on #

How did you test this?

• Manually - Behavioral changes
• Manually - Visual changes
• Adapting existing automated tests
• Adding automated tests for new behavior (or missing tests)
• Existing automated tests should already cover this (only a refactor of tested code)

Self-review checklist for each commit

• It is a minimal coherent idea
• It has a commit summary following the documented style (title & body)
• It has a commit summary describing the motivation and reasoning for the change
• It individually passes linting and tests
• It contains test additions for any new behavior
• It flows clearly from a previous branch commit, and/or prepares for the next commit

[Niloth-p]

Looks pretty neat!
I was thinking that we needed issue templates too.
This will make a great improvement.

May I know why we choose to make no mention of CZO?
a) I understand we wouldn't want to lose bug reports getting submerged in CZO and that users don't need to have a CZO account, but can't we mention CZO ZT stream as an option if they're not sure about how to reproduce their bug?
b) I noticed zulip/zulip seems to have a separate template for issues discussed in CZO. But, yeah, there's no associated label and it only contains a hint/reminder to link a CZO message instead of a topic and to link back the created issue, but that could be useful too?

nit: Regarding the categories,
sometimes and for some users the border between a major and a minor bug may not be very distinct (despite the description).
But, I guess that margin of error would still be fine.

[Niloth-p]

Maybe we can also add the shortcut (Meta + ?) for the About Menu?

[neiljp]

Yeah, sounds reasonable - though we'll need to update this once we know how we're going to express Meta consistently.

Suggested change

	If possible, please provide details from the `About` menu:
	If possible, please provide details from the `About` menu (<kbd>Meta</kbd>+<kbd>?</kbd>):

[Niloth-p]

Would we also want to ask for the Python version and implementation?

[neiljp]

Some of these are listed in the About menu, so it's difficult to know whether to include these in the top part or beneath that.

The reason I included these separately is

• in case users cannot access the about menu
• if we later add a 'copy' option to the about menu for this kind of reporting :)

The python details could probably go here, but may want to be freeform - maybe multiple versions have been tested?

[Niloth-p]

oh yeah, we could mention that these details can all be found in the About menu, at the starting of that section. Since one can't assume that, if they do not know.
Nice ideas! I didn't account for these possibilities.

[Niloth-p]

I noticed that you chose to drop the checkbox list for Zulip server versions.
I'm not quite acquainted with the server versions yet.
But, would the same checkbox not apply for ZT?

[neiljp]

See the 'parity' file, which links to the API changelog for some server versions.

I will add chat.zulip.org as one of the Zulip server suggested version options.

[neiljp]

We could add each server version, but we've historically aimed to support from 2.1 onwards. That doesn't mean we support every feature that web has, but we've not dropped support for older server versions. For that reason the list of server versions to select from wouldn't be 8/7/6/5(orless), but more like 8/7/6/5/4/3/2.1. That's only two more options, but it might make the list a little long, and even longer with new releases ;)

[neiljp]

@Niloth-p Does the fixup commit address your suggestions?

[Niloth-p]

@neiljp That's a lot more improvements than I was able to imagine 😃

[Niloth-p]

Oh yeah, this is a great idea to just add it to all of the templates.
Do we also want to mention that it's better for them to link the message instead of the topic, as they could be moved?

[neiljp]

I did consider this, but I didn't want to get too technical for issue filing - ie. a link is a good starting point if not familiar with Zulip.

For ZT in particular, we could even simplify it back to something like 'name of topic', since we don't have a 'copy link to message' (or topic, or stream) as yet.

I'm inclined to leave this as a followup for now.

[Niloth-p]

We might want to mention or clarify that the part in the brackets is the hotkey to access it.
It may not be obvious, as 'meta' and '?' are not just keys.

[neiljp]

I dropped the <kbd> tags from the text as discussed previously, since they are only visible when previewed/submitted, so are a bit messy when filling out the original box.

Just added a hotkey: prefix before the keys.

[neiljp]

Pushed a few more minor changes. Will look at this again later, but I'd like to squash and merge this to get some real-life testing going, so we can iterate further if necessary.