Create AUTOCUT issues without "untriaged" label

[AmiStrn]

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.

opensearch-build-libraries/vars/createGithubIssue.groovy

Lines 15 to 22 in d88c840

	@param args.label <optional> - GitHub issue label to be attached along with 'untriaged'. Defaults to autocut.
	@param args.daysToReOpen <optional> - Look for a closed Github issues older than `daysToReOpen`.
	@param args.issueEdit <optional> - Updates the body of the issue, the default if not passed is to add a comment.
	@param args.issueBodyFile <optional> - GitHub issue body from an `.md` file
	*/
	void call(Map args = [:]) {
	label = args.label ?: 'autocut'

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

[AmiStrn]

@dblock fyi

[AmiStrn]

this was really small. im pretty sure the 2-liner i wrote fixes this

[prudhvigodithi]

Thanks @AmiStrn In my opinion having an untriaged label is good, doing the same for Core repo Gradle Check Flaky Test Report issues (example opensearch-project/OpenSearch#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

[peterzhuamazon]

I also agree with @prudhvigodithi here as untriage label helps bring attention to maintainers to address newly fresh autocut issues.

[AmiStrn]

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.

[AmiStrn]

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?

[peterzhuamazon]

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.

[AmiStrn]

@dblock this kind of sounds like we should just ignore autocut in the catch all triage meetings. Wdyt?

[prudhvigodithi]

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

[AmiStrn]

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.