Enable health status automation for all deliverables

What does this MR do and why?

See gitlab-org/gitlab#378348 (closed)

Following this change all issues given the Deliverable label in the current milestone will have their Health Status automatically adjusted. This adjustment can be overridden at any point by the assignee or other issue participants. Each adjustment will only be applied once per milestone for each rule.

The adjustment rules are as follows:

• on_track in the first 7 days of the milestone
• needs_attention if there is no assignee within 11 days of the end of the milestone
• at_risk if there is no assignee within 3 days of the end of the milestone
• needs_attention if not workflowin dev within 7 days of the end of the milestone
• at_risk if not workflowin review within 3 days of the end of the milestone

With the exception of setting on_track at the start of the milestone, no issue will have its Health Status upgraded. For example, if you have set an issue at_risk it will not be upgraded to needs_attention because there's is no assignee.

security issues are excluded as the timeline for those is different.

The automation is scoped to gitlab-org/gitlab only for now.

Trial

This change was trailed during FY24 Q4 by requiring the ~"Track Health Status" label. Approximately 10% of issues closed in %15.7 had this label. This change removes the requirement to add this label and enabled the automation for all Deliverable issues in gitlab-org/gitlab.

Why is this useful?

The Plan team have recently introduced the ability to filter issue boards and lists by Health Status as well as making Health Status visible on issue board cards.

This means that stakeholders can, at a glance, get an idea of the overall health of milestone progress at any time and identify problem issues.

Here's an example of the groupproduct planning %15.8 board on the 12th January:

Feedback issue

Please weigh in on gitlab-org/gitlab#378348 (closed) with concerns, bugs or suggestions for new rules.

Opt-out

Any issue can be opted-out of Health Status automation by adding the label ~"Untrack Health Status".

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-with-a-dry-run on how to perform dry-runs.

Action items

• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Engineering week-in-review