### Problem to solve Some S1 bugs are not getting attention within the [resolution SLO](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity-slos). As a result, we see [S1 OBA](https://about.gitlab.com/handbook/engineering/quality/performance-indicators/#s1-oba) much higher than it should be. ### Action Change the default from quad team members needing to take action to schedule S1s within their SLO, to **S1s being automatically scheduled to a milestone within their SLO**. S1 bugs without an appropriate X.Y milestone will be assigned one through a triage policy. Tasks: - Create a triage policy that will be used on S1 bugs that do not have an appropriate X.Y milestone. - It will assign a due date of `<SLO LENGTH>` days out - It will assign the corresponding milestone - It will ping the appropriate quad team members - Triage policy is executed nightly This implementation should exclude security, availability, and corrective actions as those have tighter SLOs than the standard S1. ### Impact Impact to milestone planning should be relatively small. On an ongoing basis, the number of S1 bugs opened per month has historically been fairly low (5-20 per month). [Sisense source](https://app.periscopedata.com/app/gitlab/856737/S1-Open-Bug-Age-(OBA)?widget=14650330&udv=1637046) This change should be high-impact for S1 OBA, overall S1 counts, and meeting our SLO. ### Notes For ~"bug::vulnerability", work with AppSec escalation engine https://gitlab.com/gitlab-private/gl-security/engineering-and-research/automation-team/escalator/appsec-escalator to set milestone.