Create a triage policy to automatically schedule most S1 bugs
Objective
Automatically schedule severity1 typebug issues according to severity-based SLOs (30 days).
This technical implementation will provide the baseline for gitlab-org/gitlab#362985. It will then be built upon as the rollout of automatic scheduling continues.
Bugs that fall into the following categories should be excluded from this v1 triage policy because their SLOs are stricter than the default S1 SLO:
Proposal
For relevant S1 bugs that do not have an appropriate milestone assigned, create a triage policy that will:
- Apply a due date of 30 days from today.
- Apply the milestone that corresponds with the due date assigned.
- Ping the relevant quad members in a comment for awareness.
Appropriate milestone in this case means a current or upcoming milestone that starts before the SLO is breached. Examples of inappropriate milestones are:
- No milestone
- Milestone is expired
- Milestone starts more than
<SLO LENGTH>days in the future - Milestone is non-specific (e.g. Backlog, Next 1-3 releases, etc)
For future flexibility as this work is expanded to cover SLOs that are shorter or longer than 30 days, it would be ideal if:
- The code that checks if an issue has an appropriate milestone takes N as input, representing the SLO, rather than hardcoding "current or next milestone" in some manner.
- The milestone application method takes N as an input, representing the SLO, rather than hardcoding "next milestone" in some manner.
You probably would have coded it this way anyway, but I wanted to be explicit just in case.