New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update issue templates #2441
base: master
Are you sure you want to change the base?
Update issue templates #2441
Conversation
.github/ISSUE_TEMPLATE/bug.yml
Outdated
@@ -3,6 +3,7 @@ name: Bug Report | |||
description: Report a bug | |||
labels: | |||
- status/triage | |||
- kind/bug |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we originally had this, but then removed it? cc @tonistiigi
I remember a discussion (I think in the build team internal docker slack) about wanting to ensure that all issues with the label were confirmed bugs, which requires a level of triage before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 @jedevc - I had a chance to read the old thread you mentioned, and the scenario described is crucial (being able to find confirmed bugs).
The goal with this was to try and help pre-sort as the issue entered into triage and be able to identify when the issue had been responded/handled in any way. In this case, a response could include requesting more information, putting the issue into a "blocked" state but no longer requiring initial sorting. This idea stemmed from status/triage being the default state for all inbound bugs and feature requests and an assumption that the first response would get it out of that triage state to something else to avoid recycling issues. Would the addition of a verified (or using the existing accepted label) still address your use case?
I am hoping for simplicity above all else on this front - any and all ideas would be amazing 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kind/maybe-bug
until confirmed? 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM 🎉 Essentially anything that helps filtering!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in the kind/maybe-bug
5212ec9
to
1909d68
Compare
Signed-off-by: Shaun Thompson <shaun.thompson@docker.com>
Signed-off-by: Shaun Thompson <shaun.thompson@docker.com>
Signed-off-by: Shaun Thompson <shaun.thompson@docker.com>
6fc3ef7
to
b73fea0
Compare
Signed-off-by: Shaun Thompson <shaun.thompson@docker.com>
- type: textarea | ||
attributes: | ||
label: Docker info | ||
label: Builders list | ||
description: | | ||
Output of `docker info` command. | ||
Output of `docker buildx ls` command. | ||
render: text | ||
validations: | ||
required: true | ||
|
||
- type: textarea | ||
attributes: | ||
label: Builders list | ||
label: Docker info | ||
description: | | ||
Output of `docker buildx ls` command. | ||
Output of `docker info` command. | ||
render: text |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why we want to change the order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When reading the attributes, I was just attempting to group docker buildx
commands together -- no strong preference either way.
Summary
This PR has a few changes around existing issue templates
Template updates
Bug Report Template
kind/maybe-bug
label by defaultFeature Request Template