Add minimal issue templates

[AlexWaygood]

A first step towards:

• Use issue templates for python/cpython core-workflow#437

These are largely derived from the mypy issue templates, which I think are pretty effective (more effective than what CPython has currently, anyway 🙂)

[AlexWaygood]

(It's the first time I've tried setting up issue templates, so please review carefully.)

[hugovk]

Looks good!

To compare with Mypy, will be something like: https://github.com/python/mypy/issues/new/choose

[hugovk]

One last thing.

We can also skip "please" for brevity.

The Google style guide is pretty good, and says:

https://developers.google.com/style/tone?hl=en#politeness-and-use-of-please

[hugovk]

Thank you!

[ezio-melotti]

Looks mostly good to me, at least as a first iteration.

A few comments:

• I'm not a big fan of templates with a lot of text and comments, even though I guess they might be more useful for people that are reporting issues for the first time
• If we automatically add labels, it will be more difficult to distinguish triaged and untriaged issues (that currently have no labels) -- do we need to automatically an untriaged or new label for all new issues and remove it once a triager checks them?
• We could disable free-form issues, but core-devs might want to use them

[erlend-aasland]

Nice!

[AlexWaygood]

It looks like there are 179 open issues that have the "build" label, but don't have any of "type-bug", "docs", "type-security" or "type-feature".

I think I'd rather not create a build.md template, as I think if we have too many options it will just complicate things unnecessarily -- but I thought I'd mention it.

[AlexWaygood]

I'm not a big fan of templates with a lot of text and comments

Neither am I, tbh, but as you say -- they're not really for us; they're for people who are new to CPython :)

If we automatically add labels, it will be more difficult to distinguish triaged and untriaged issues (that currently have no labels) -- do we need to automatically an untriaged or new label for all new issues and remove it once a triager checks them?

We could do that -- I've seen other projects do that. I don't think that's essential, though. CPython has a fairly active group of triagers and core devs who will generally be sifting through recently opened issues anyway. Most of the time, invalidly applied labels will be spotted fairly quickly; and if not, I don't think it's that big a deal anyway.

[ezio-melotti]

A couple more nits and then it's good to go:

• I tried to clarify when to use the "crash" template
• I included "enhancements" in the "feature" template

[AlexWaygood]

Thanks everybody for the reviews!

[ezio-melotti]

Thanks for the PR!

It looks like we have 3 security-related entries now: https://github.com/python/cpython/issues/new/choose
I suspect the one with the green "View policy" button is added automatically, probably because we have a .github/SECURITY.md file. I think we can just remove the link from the config.yml.

[ezio-melotti]

It might actually be better to remove the .github/ISSUE_TEMPLATE/security.md file too, and just leave the default security entry. What do you think?

[AlexWaygood]

It might actually be better to remove the .github/ISSUE_TEMPLATE/security.md file too, and just leave the default security entry. What do you think?

Yup, I think that's best! I had no idea having the .github/SECURITY.md would mean we'd have the duplicate entries. One is enough.

[AlexWaygood]

It might actually be better to remove the .github/ISSUE_TEMPLATE/security.md file too, and just leave the default security entry. What do you think?

Yup, I think that's best! I had no idea having the .github/SECURITY.md would mean we'd have the duplicate entries. One is enough.

• Issue templates: Remove duplicate links to security policy #91590

[ezio-melotti]

It looks like their are 179 open issues that have the "build" label, but don't have any of "type-bug", "docs", "type-security" or "type-feature".

This is because "build" used to be a type on bpo, and now it's a label on its own, since you can have both build-related features and bugs.