[FEATURE] Document what untriaged label means and what typically happens during triage

[dblock]

Is your feature request related to a problem?

In https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#triage-open-issues we talk about triaging issues. But what is it?

What solution would you like?

Add to https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#triage-open-issues. I think we want to say that:

1. Triage is a regular thing that teams do (with an example like security - provide link - that does it in the open).
2. All new issues get an untriaged label.
3. Triage means looking at all issues that say "untriaged" are looked at. Confirmed as valid as feature requests or bugs, belonging to this repo, etc.
4. Untriaged label removed.
5. Doesn't mean anyone will ever promise to work on this issue.

[joshuarrrr]

@minalsha Are you still working on this? If not, I can make a PR for it.

[minalsha]

@joshuarrrr yes i am on it. Thanks.

[joshuarrrr]

In case it's useful, here's how we've expanded the above to be more of a checklist for the Dashboards team. @dblock I've also tried to summarize how I understand the current intent, so please let me know if I've misrepresented or misunderstood anything.

Purpose - The untriaged label and the triage process is a mechanism to ensure community issues are read and assessed by at least one person who is a member of https://github.com/orgs/opensearch-project/teams/triage. At the OpenSearch project level, we also collect metrics using that label across all repositories to measure an improve our responsiveness to community requests.

Checklist

1. Is this the correct repo for this issue? If not, transfer or request request transfer by tagging @opensearch-project/transfer-request. Leave the untriaged label in place when transfering and add a comment explaining why.
2. What type of issue is it?
   1. bug
   2. Is there enough info to verify or reproduce? Can you reproduce? In either case, add a comment about your assessment. If not, mention the requester and add the needs more info label.
   3. Is the bug label appropriate, or would enhancement be more accurate?
   4. Search for other similar issues and link as appropriate
   5. Add other more specific labels (feature, type of bug, etc.)
   6. enhancement
   7. Is the undelying need clearly defined so it can be prioritized and implemented? If not, mention the requester and add the needs more info label. Add clarifications as necessary in a comment.
   8. Search for other similar issues and link as appropriate
   9. Add other more specific labels (feature, type of bug, etc.)
3. If it's not a valid feature request or bug, explain why in a comment and close. Otherwise, make sure there's at least one comment that explains how you triaged it, and remove the untriaged label. (If the issue is actionable and clear, consider adding help wanted or good first issue as appropriate.

FAQ

Should maintainer/regular contributor-created issues be labeled untriaged Generally, no. Only if you're opening an issue in an unfamiliar repo.

Does triaging an issue commit us to working on or prioritizing it? No - it just means that it's a valid issue for this repository.

What if the issue requires visibility from other people (devs, maintainers, product, ux) Different teams will have different processes, but use a label other than untriaged. The Dashboards team is experimenting with the discuss label for his purpose.

[dblock]

I like this. Let's turn it into something org-wide @joshuarrrr?

Couple of thoughts:

• The triage team is an internal team that lets org members move issues around. I think we should say "maintainers" and not mention that this team exists in a public document. If GitHub allowed a level of permissions for all org members or all maintainers to transfer issues, we'd get rid of it.
• I'd add is asking triage folks to attempt some level of gentle nudging for the next step that the contributor can make themselves, since this is open-source. For example, for a bug I often ask whether the contributor would like to write a unit test that reproduces the issue. If I spot that some data may be missing (e.g. product version), I ask for more data. If the bug was reproduced on an older version, I'd ask to try on a newer one.
• For a public doc "we" is "maintainers of the project". I would consider saying what we do rather than what we don't do. For example the maintainer doesn't need to confirm that "this is a bug", but just that "this looks like a bug".

[dtaivpp]

@dblock do you think saying maintainers is too widely scoped? Anyone belonging to the OpenSearch-Project could be a potential for triaging issues no?

[dblock]

@dblock do you think saying maintainers is too widely scoped? Anyone belonging to the OpenSearch-Project could be a potential for triaging issues no?

That's a good point. In the end you do need triage permissions to assign labels, so that should be expressed somehow.