GitHub issue types vs labels

Development
1

It seems that GitHub now has issue types, see the docs. By default the ones set up for the OpenChemistry organization (issue types are cross-organization) are Bug, Feature, and Task, and custom ones can be created (e.g. one for Security Vulnerability).

@ghutchis, would you prefer to embrace these new type classifications for triage or stick to using the old labels?

There’s only 6 issues with the Bug label currently, so we aren’t particularly invested in the labels interface yet – if we are going to switch to types, now would be a good time, before I start classifying all the current issues!

Some of the advantages and disadvantages of the new issue types have been discussed here. The key ones being, so far as I can tell:

  • they are unified across an organization
  • there are new filters etc. that work with them
  • they can be automated in various ways
    • as an example of what we could do with this: when a user currently opens an issue they are prompted to choose from bug report, feature request, blank issue, and report a security vulnerability, and at the moment this just changes the issue template, but we could set it up so that GitHub automatically assigns the correct issue type based on the user’s choice
  • unlike labels, types are mutually exclusive i.e. only one type can be assigned at a time
  • there are no matching “PR types”, PRs can only have labels

Presumably there will also be more advantages in future as the feature matures, and maybe PR types would come later, I don’t know.

2

I guess I don’t see the advantage. I haven’t triaged all the issues with labels partly because I just don’t have the time. I think people would rather me fix bugs or write code. I generally try to tag the issue (and definitely the PR) before merging.

The advantage of keeping with labels is that we have a lot of back issues / pull requests with labels, and label tags are shared between issues and pull requests. (And in fact GitHub pull requests are just another kind of issue.)

But I don’t feel strongly. As I said, I feel like my main goal is pushing forward with fixes / features. If you or someone else can help with the issue tracker, that would be greatly appreciated.

1 Like
3

In that case, let’s stick to labels for now.

For my part, I have zero preference or opinion at all, it’s just that I spotted it in the interface for the first time.

1 Like
4

To be clear, I’m not tied to the labels - I just don’t see a big advantage from the new issue type. I guess it allows issues across multiple repos in an org? (Which does happen somewhat with avogadrolibs / avogadroapp.)