During a recent standup, we discussed the triaging process and its usefulness. It was agreed that in its current form, triaging an issue brings little value other than removing it from the triage party board. Maintainers admitted to not really considering the priority tags assigned during triage when planning features for the next release.

Another issue is that the current process makes it difficult for newer contributors to add value and participate in triaging due to a lack of context. Moreover, the ad-hoc nature of triaging has led to a significant buildup of open issues for cert-manager.

To solve these issues, I propose the following:

1. **Triaging should be a scheduled, recurring event (weekly or bi-weekly) and take place during the current standup timeslot on a given day.**
* Starting with a weekly cadence (e.g., every Thursday) would be beneficial until the backlog of open issues is addressed.

2. **A list of approximately 10 issues should be curated ahead of the triage day in a Slack thread or a GitHub issue. Anyone can nominate a ticket for triaging.**
* Knowing the list of issues in advance allows participants to familiarize themselves with the context. Some may have more expertise in a particular area and can leverage that to triage the ticket effectively.
* Maintainers are free to pick an issue and notify others that they will investigate it. Later, they can share their findings and make a case for action on the issue.

3. **Instead of randomly splitting the issues among participants, one person should lead the meeting and present one item at a time. All participants will then discuss that item and aim to reach a decision.**
* This approach taps into the collective expertise of all members and enables knowledge sharing. Newer members can learn from previous discussions, existing issues, and documentation.

4. **The end goal of the triage process for each issue should be a clear action captured in a comment, such as:**
* Requesting more information or clarification if a decision cannot be reached.
* Closing the issue with an explanation of why it will not be implemented, which serves as a useful point of reference for similar future issues.
* Marking the issue as a duplicate and linking to the original issue or pull request. The authors could also be notified.
* Tagging the issue as "ready for development," "good first issue," or similar to indicate it is a worthwhile piece of work.
* Prioritizing the issue immediately if it is deemed a critical problem.

5. **When planning features for a future release, maintainers can refer to issues tagged as "ready for development," review the comments from the triage session, and make a more informed decision about their inclusion.**