Skip to content

Avoid setting on track when issue slipped previous milestone

John Hope requested to merge jh-update-health-status-adjustment-missed-deliverables into master

What does this MR do and why?

See gl-retrospectives/plan#110 (closed)

During the 16.9 retrospective, a concern was raised regarding the Health Status feature being used to monitor progress and risks in deliverables. Despite missing several scheduled milestones, some issues were marked as "On Track," potentially misleading those depending on related deliverables. This was often due to automation marking issues as "On Track" when an assignee was present, regardless of missed milestones.

This change avoids resetting the health status to on track if a missed-deliverable label is present. That would also leave the issues in on track state, so an additional policy is added to set to needs attention instead.

In other words, after this change the following will happen at the start of a new milestone:

  1. Issue slips milestone as don't track health status - no change (regardless of HS)
  2. Issue slips milestone with no health status - set to needs attention
  3. Issue slips milestone as on track - downgrade to needs attention
  4. Issue slips milestone as needs attention - retain as needs attention
  5. Issue slips milestone as at risk - retain as at risk

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-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

Edited by John Hope

Merge request reports