Define how triaging process is done

[mx-psi]

Once the triaging process is defined, we should also have a description of when and how it happens concretely. This could be on a triaging-only meeting, on the usual Collector SIG meeting with a fixed time, just async but with some coordination among triagers to split the work...

[mx-psi]

We discussed this on the CNCF Slack: https://cloud-native.slack.com/archives/C083LN3PLQN/p1733399832986159

The general consensus seems to be to go with an async solution. Some specifics to resolve are:

• When there are questions/disagreement/discussion needed regarding triaging, what channel should we use? (#otel-collector-dev seems like the obvious choice, a dedicated channel is also an option to consider)
• How does the autoassignment work? How many people do we assign and how is this governed?

Async does not mean we cannot do ad-hoc meetings or use spare meeting time for this.

[atoulme]

As part of triaging, but also our commitment to our SIG meetings, I would like to make sure we also take this opportunity to tie triaging and SIG meetings as we are about to revisit the 3 timezone rotation we have tried for a bit.

My proposal would be that we ask for a triager to manage through a SIG meeting on a rotation basis.
To make it easy on the triager, we would ask them to prepare the meeting with several canned items:

1. Review the latest report issue, an issue we currently generate in contrib weekly that contains valuable information about the state of the project. The issue typically contains disclaimers and information that must be communicated to the community at large, such as the issues waiting for codeowners, the components that are unmaintained, and so on. The triager should go exhaustively over the report and shape the data to create context. I expect quantitative statements connecting the number of issues in a category to previous reports to help gauge the health of the project. If we are falling behind on issues to triage, the triager can call it out there for example.
2. Review all the issues tagged with "Needs discussion". The triager should add all of those issues to the SIG meeting agenda, and make sure to comment with whatever the SIG meeting commented. A link to the SIG meeting notes is fine. It's possible the SIG didn't have input ; that's also noteworthy and worth adding.
3. Any request for new components ; this is where triagers should mention any new component requests and make sure others are aware. This is a good opportunity for approvers and maintainers to declare themselves sponsors. In all likelihood, the issue will be discussed just like a "Needs discussion" issue, where the SIG can acknowledge the request, and may ask for more information.

At the end of the SIG meeting, the triager should close the report issue and tie it to the SIG meeting date and notes in a comment.

Here is an example of report issue: #36739