Automatically schedule most S1 bugs based on SLO
Problem to solve
Some S1 bugs are not getting attention within the resolution SLO. As a result, we see 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
- It will assign a due date of
- 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
This change should be high-impact for S1 OBA, overall S1 counts, and meeting our SLO.
Notes
For bugvulnerability, work with AppSec escalation engine https://gitlab.com/gitlab-private/gl-security/engineering-and-research/automation-team/escalator/appsec-escalator to set milestone.