Skip to content

Only add missed labels for deliverables

Nate Rosandich requested to merge nrosandich-master-patch-75b1 into master

What does this MR do and why?

Only add ~missed::xy and missed-deliverable labels to issues when the Deliverable label is present.

One of the reason for this change was the missed labels that were automatically added to issue at end of a milestone was causing anxiety in engineers that they were not meeting expectations, a big red missed label added to their assigned issues. We wanted to remove this anxiety and only focus on the ~deliverable labelled issues as major talking points.

Recently in the Compliance group we introduced ~goal:: scoped labels to our issues to clearly indicate expectation during a milestone, gitlab-com/www-gitlab-com!128671 (diffs). Some issue will be assigned and certain things expected in a milestone (planning or begun development or simply a stretch to even get to it), but not all are expected to be closed. With this model there is some issues that will naturally rollover to the following milestones (plan in one milestone, build in the next, close in the following). Only when we plan on closing it and dont do we want to add the missed labels.

In Update Compliance deliverable process (!2692 - merged) the Compliance group update the missed process for itself. This MR updates it for all groups.

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 Nate Rosandich

Merge request reports