Closed AmiStrn closed 2 weeks ago
@dblock fyi
this was really small. im pretty sure the 2-liner i wrote fixes this
Thanks @AmiStrn In my opinion having an untriaged
label is good, doing the same for Core repo Gradle Check Flaky Test Report issues (example https://github.com/opensearch-project/OpenSearch/issues/15944). Having an untriaged
label will help teams ensure that newly created autocut
issues (the failures) are not ignored.
The expectation is during the triage meeting the autocut
issue is assigned to an owner or triaged with a solution or the RCA for the created issue, having this will ensure the addressing of the autocut
issue is not delayed till the release window.
Thanks
I also agree with @prudhvigodithi here as untriage
label helps bring attention to maintainers to address newly fresh autocut issues.
We saw many AUTOCUT issues in the catch-all triage meeting (3 week old untriaged issues). I am not sure that the untriaged
label is having the expected results with regard to the release window.
We check to see that the labels are correct, the issue is in the right repo, and described correctly. this is always the case for these issues, so from my point of view it is redundant. I see why you may want it for visibility in the other triage meetings. @dblock anything else you wish to add here?
We saw many AUTOCUT issues in the catch-all triage meeting (3 week old untriaged issues). I am not sure that the
untriaged
label is having the expected results with regard to the release window.
I feel like that means the maintainers should check the AUTOCUTs on time and not letting them piled up in untriaged for a long time.
Happy to discuss more tho our team still believes this should help bring more attention to the AUTOCUT issues being solved as opposed to pure noice during the triage. 😄
Would love to see better way of solving this if possible. Thanks.
@dblock this kind of sounds like we should just ignore autocut in the catch all triage meetings. Wdyt?
In my opinion, autocut
labelled issues should be treated like any other issues in the repository that need attention. We should not exclude them, though the order of triaging priority for autocut
issues can differ. If the autocut
issues have a untriage
label, it indicates that the component teams have not addressed them, potentially could be the release blockers.
We could introduce a new priority
label to add to autocut
issues. However, we have developed the habit of treating the untriage
label as important, and this approach would need to be carried forward with the priority
label as well.
Adding @getsaurabh02
Thanks @prudhvigodithi and @peterzhuamazon for the feedback.
So that you know, AUTOCUT issues that reach the catch-all meeting have the untriaged labels removed without assigning the issue.
I'm closing this issue for now since there is a desire to keep things as they are in this regard.
Is your feature request related to a problem? Please describe
The AUTOCUT tickets are generated with an
untriaged
label, this is redundant. There is nothing to triage here.Describe the solution you'd like
the labeling code already recognizes there is a difference between Autocut and other issues, I suggest making so these tickets are created without the untriaged label. this will reduce noise in the triage meetings. https://github.com/opensearch-project/opensearch-build-libraries/blob/d88c840ed78f2f190315c32aab5df96b79cfa529/vars/createGithubIssue.groovy#L15-L22
Describe alternatives you've considered
all other options are either manual or automating the manual work which is breakable and pointless.
Additional context
No response