# Triage party process for the cert-manager project

We have a section on "Triage Party" in https://cert-manager.io/docs/contributing/contributing-flow/#triage-party but it doesn't explain how to run it, how frequently, and so on.

## Frequency

We haven't been able to frequently do triage parties. We do them when we feel the need for it.

## How to run the triage party (organiser)

First, share the following link to the group:

<https://triage.infra.cert-manager.io/s/daily>

The organiser lets everyone know what the number for each person will be. For example, if we are 4, the organiser shares the following in the chat:

erik = 1
richard = 2
tim = 3
mael = 4

## What to do as a player

As a player, start from the top items and go towards the bottom, section by section:

- Unprioritized issues older than 7 days
- Uncommented older than 7 days
- Important soon, but no updates in 90 days
- Important longterm, but no updates in 180 days
- Pull Requests: Review Ready
- Unkinded Issues
- Unprioritized Recent Issues
- Uncommented Recent Issues

For each issue or PR, open the PR and do the action explained below; once done, refresh your triage party page and the issue should be gone from the list (triage party might take time to refresh itself).

### Unprioritized issues older than 7 days

We start with the "Unprioritized issues older than 7 days" items:


The only thing to do is to set one of the following labels:

priority/critical-urgent
priority/important-soon
priority/important-longterm
priority/backlog
priority/awaiting-more-evidence

If you aren't able to set these labels, try using the Prow commands in a comment instead:

/priority critical-urgent
/priority important-soon
/priority important-longterm
/priority backlog
/priority awaiting-more-evidence

Here is their meaning:

| Priority labels (from higher to lower priority) | Description |
|-----------------|-------------|
| priority/critical-urgent | Highest priority. Must be actively worked on as someone's top priority right now. Stuff is burning. If it's not being actively worked on, someone is expected to drop what they're doing immediately to work on it. Team leaders are responsible for making sure that all the issues, labeled with this priority, in their area are being actively worked on. Examples include user-visible bugs in core features, broken builds or tests and critical security issues. |
| priority/important-soon | Must be staffed and worked on either currently, or very soon, ideally in time for the next release. |
| priority/important-longterm | Important over the long term, but may not be staffed and/or may need multiple releases to complete. |
| priority/backlog | Higher priority than priority/awaiting-more-evidence. There appears to be general agreement that this would be good to have, but we may not have anyone available to work on it right now or in the immediate future. Community contributions would be most welcome in the mean time (although it might take a while to get them reviewed if reviewers are fully occupied with higher priority issues, for example immediately before a release). |
| priority/awaiting-more-evidence | Lowest priority. Possibly useful, but not yet enough support to actually get it done. # These are mostly place-holders for potentially good ideas, so that they don't get completely forgotten, and can be referenced /deduped every time they come up. |

- Is this fixed? Is this a configuration mistake? Is that a thing we want to fix long term.
-