Clarity around "untriaged" issue handling

[jmazanec15]

For OpenSearch, all issues are created with the "untriaged" label by default. Number of "untriaged" issues is tracked by project leadership as a repo health metric. However, I dont think we define the expectations around triaging issues (please correct me if I am wrong).

I think there was a similar issue in the security plugin: opensearch-project/security#3022. However, it seems like the main purpose of triaging in this context is just making sure it is not a security vulnerability - not necessarily assigning the work. CORRECTION: looks like security defines it in a MD file: https://github.com/opensearch-project/security/blob/main/TRIAGING.md. Should this be project wide?

What are the expectations around triaging issues? Should they be documented somewhere?

[peternied]

[Bias - I'm one of the maintainer of Security repo] I think its a good way to document our process and create an invitation for the broader community to get involved. We've developed this process organically, and we've continued to iterate. It works well for us. I think there is an opportunity to call out best practices, and maybe the Security project is an example of how that can be done.

@jmazanec15 What do you think about making a pull request to help define what you see is too vague?

[jmazanec15]

Looking more, I found this documentation which answers my question: https://github.com/opensearch-project/.github/blob/main/RESPONSIBILITIES.md#triage-open-issues:

Manage labels, review issues regularly, and triage by labelling them.

All repositories in this organization have a standard set of labels, including bug, documentation, duplicate, enhancement, good first issue, help wanted, blocker, invalid, question, wontfix, and untriaged, along with release labels, such as v1.0.0, v1.1.0, v2.0.0, patch, and backport.

Use labels to target an issue or a PR for a given release, add help wanted to good issues for new community members, and blocker for issues that scare you or need immediate attention. Request for more information from a submitter if an issue is not clear. Create new labels as needed by the project.

So triaging is labeling and potentially asking for more info. With that, I think I can close this.

@jmazanec15 What do you think about making a pull request to help define what you see is too vague?

No, I dont think this makes sense yet.