Document an issue triage workflow for the repository #3394
Conversation
| @@ -0,0 +1,15 @@ | |||
| name: Blank issue | |||
There was a problem hiding this comment.
This mimics the blank issue for github as well as possible while also adding the expected label.
| @@ -12,7 +12,7 @@ jobs: | |||
| steps: | |||
| - uses: actions/stale@5bef64f19d7facfb25b37b414482c7164d639639 # v9.1.0 | |||
| with: | |||
| days-before-stale: 30 | |||
| days-before-stale: 90 | |||
There was a problem hiding this comment.
I'm open to changing this back to 30, I wanted to focus on reversing the mechanism - all things need attention (triage) until they have been reviewed.
|
I'm going to update templates to add the ability to select a component from a dropdown if relevant. |
| * These issues should retain the `needs-triage` label until the codeowner has responded | ||
| * Ready to implement/fix/document | ||
| * An issue is ready to implement or fix if the scope is well understood, and if it is an issue it should be replicatable | ||
| * These issues should be tagged `bug`, `enhancement`, `type/docs`, or `flaky-test` |
There was a problem hiding this comment.
Does the concept of "docs bug" or "docs enhancement" make sense?
i.e. Labels: bug type/docs.
Maybe this could be more general? Saying that each should have a "type" (bug or enhancement), an "area" (area/*), and any other optional labels
Does the process of going from triage to ready to implement essentially mean removing the needs-triage label? The assumption being all issues should have been given appropriate areas/categories as a part of triage.
There was a problem hiding this comment.
I agree, I like the overall concept, but I think we should do those larger changes in a separate conversation.
I do think there's some updates to the wording that make sense based on this comment, too, will tinker.
| There are a variety of other labels that can be applied to issues and pull requests to help provide context to the issue. Wherever possible, relevant labels should be applied. | ||
|
|
||
| * The `component-request` label can help identify requests for new components. | ||
| * The `os:windows` should be used when changes are relevant to the Windows OS. |
There was a problem hiding this comment.
We definitely have a few conventions label-naming-wise. What do you think about consolidating around slashes and kebab-case?
component/request or component/new✨
os/windows
status/keepalive
v2/breaking-change
help-wanted
good-first-issue
And probably other's I'm missing
There was a problem hiding this comment.
I like your overall ideas on label standardization, IMO that's not in the scope of this PR but I'm in favor of doing it. I'll leave existing ones as previously used in this PR, then we can update in a follow up as needed.
| * Ready to implement/fix/document | ||
| * An issue is ready to implement or fix if the scope is well understood, and if it is an issue it should be replicatable | ||
| * These issues should be tagged `bug`, `enhancement`, `type/docs`, or `flaky-test` | ||
| * If the issue should be in the next release, it should be tagged `release-blocker` |
There was a problem hiding this comment.
release-blocker
This would be cool to build automation around if we don't already have it.
There was a problem hiding this comment.
Definitely agree, I don't think we have it at the moment.
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Co-authored-by: Joe Harvey <[email protected]>
Co-authored-by: Joe Harvey <[email protected]>
PR Description
In order to better manage the landscape of issues raised against the Alloy repository, I'd like to propose an issue triage workflow to help define the triage process. A more consistent triage process will make it easier for team members to step in and do a small amount of triage and leave the issue landscape in a better place than they found it. It should also enable us to identify long-term trends on issues.