GitHub issue types -- should we use them?

Core Workflow
1

On January 3, GitHub introduced a new feature: Issue Types.
These are now turned on for the python organizations, and in the cpython repository they duplicate existing type-* labels.
Since existing issues use labels, that’s what one needs to use for searching. To make label searches work, labels need to be used on new issues as well (optionally with a redundant type).

I see no advantage of using issue types over labels yet.

I’ve asked python org owners to disable issue types. None of the repos use them (see the link for details). [edit: They’re now disabled.]

We can discuss here whether to enable them. IMO, if we do that, we should migrate from labels, not just enable a parallel new classification scheme.

4 Likes
2

For now, I agree and would vote to keep our custom labels—we have more granularity over the types rather than simply ‘bug’ or ‘feature’.

A

3 Likes
3

Issue types are now disabled, thanks to ee!

We can add new issue types. But it’s an organization-wide setting, affecting all repos in the org – mypy, typeshed, docs translations, etc.

2 Likes
4

I think the only benefit would be if we had labels that we only wanted on issues as the issue types don’t work on PRs.

2 Likes
5

I suspect that means it’s going to be a poor fit for orgs like ours where lots of different kinds of projects are hosted under the same org.

If there’s enough commercial demand for allowing the available issue types to vary by repo, there might eventually be more flexibility on that front, at which point it could be worth revisiting the question.

1 Like