Switch issue templates to use new-style issue types #13289
Conversation
Qiskit is part of the new-style GitHub issues beta[^1], which gives us
access to a special kind of "super" label: the issue "type". We've
previously used two special labels ("bug" and "type: feature request")
to categorise the resulting issues from the issue template. This commit
leans into this new system, setting the issue type, rather than the
custom labels.
The new issues also specifies that the templates will be displayed in
sorted order by file name. This commit makes that ordering more
explicit for us.
[^1]: https://github.blog/changelog/2024-10-01-evolving-github-issues-public-beta/
jakelishman
added
type: qa
|
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 11217189473Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
|
I think with the sub-issues feature it also makes sense to add a template and support the Epic type. |
|
Eli: is there going to be any advantage to that over just using the "blank issue"? I think of the issue templates as being for external contributors to use slightly more than the core team doing internal tracking, and I can't imagine a situation where an external contributor would be / should be empowered to set us an epic. I'm also not sure there'd be any standard structure to an epic that the form would help with. |
|
My main motivation is to facilitate organizing tasks in a more hierarchical fashion now that we have the sub-issues feature available. So given a template like the below, I think that having a template Epic issue type in the Background In any case and regardless, I agree with your statement about epics being more of the core team responsibility to set up. |
|
I don't feel strongly, and I feel like we could adjust the documentation of the template to make it clear that an "Epic" template is not intended for general use. If you think that structure's useful, I can write up a template for it (maybe a separate PR, then we can play with it more separately?). |
|
Sounds good. |
|
Eli: do you want to approve / review this PR as-is, then, then I'll get to updating the issue metadata for the repo and make the new template? |
| @@ -1,6 +1,6 @@ | |||
| name: 🚀 Feature request | |||
| description: Suggest an idea for this project 💡! | |||
| labels: ["type: feature request"] | |||
| type: Enhancement | |||
There was a problem hiding this comment.
We currently have in the label space type: enhancement and type: feature request, each with different meaning, namely "improve existing functionality" and "suggest or ask new feature", respectively. Assuming we want to have those 2 concepts captured in issue types (I would vote for it) It would be good to preserve this separation by naming the type here with Feature or something similar, but not Enhancement.
There was a problem hiding this comment.
We have to set the allowed types at the organisation level (if I understand the docs correctly), but that seems easily doable.
Summary
Qiskit is part of the new-style GitHub issues beta1, which gives us access to a special kind of "super" label: the issue "type". We've previously used two special labels ("bug" and "type: feature request") to categorise the resulting issues from the issue template. This commit leans into this new system, setting the issue type, rather than the custom labels.
The new issues also specifies that the templates will be displayed in sorted order by file name. This commit makes that ordering more explicit for us.
Details and comments
If we choose to merge this, I can bulk update all our issues to use the new "types" rather than the magic labels, so we'll have a more consistent experience across our tracker. The new "subissues" system is pushing us towards using these types, so it feels cleaner to centralise.
Footnotes
https://github.blog/changelog/2024-10-01-evolving-github-issues-public-beta/ ↩