Automatically schedule most S2 bugs based on SLO, for a subset of product groups

Problem to solve

Some S2 bugs are not getting attention within the resolution SLO. As a result, we see S2 OBA higher than it should be.

Additionally, some product groups have a tidy S2 backlog and incoming S2s can thus be automatically pulled in to upcoming milestones without needing to compare their priority against any backlog of S2s.

Action

Change the default from quad team members needing to take action to schedule S2s within their SLO, to S2s being automatically scheduled to a milestone within their SLO. S2 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 S2 bugs that do not have an appropriate X.Y milestone, for a subset of product groups.
  • 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 S2s.

Additionally, this implementation should only include product groups that do not have a backlog of S2s. Product groups not included in this initial iteration will be added in the future as they burn down their S2 backlogs.

Impact

Impact to milestone planning should be relatively small. On an ongoing basis, the number of S2 bugs opened per month across these groups has historically been fairly low (10-25 per month). Sisense source, please select appropriate groups in the filters

This change should be high-impact for S2 OBA, overall S2 counts, and meeting our SLO.