Track missed deliverables automatically

Problem to solve

In our own process, we schedule gitlab-ce~992791 issues before the beginning of the cycle. So teams commit to ship everything that is marked with that label. It happens that at the end of the cycle some of those issues are not completed, and are not part of the final release. We want to track this flow in order to provide metrics about how many "misses" we have.

Further details

There is a trending process that requires developers to add gitlab-ce3804821 labels to issues. So issues are kept as gitlab-ce992791 until the end of the cycle (or even the release date), and then are marked as missed.

This introduces a bigger problem: we are not showing the current status of issues. Anyone looking at the issue will expect that we will ship that feature/fix in that specific milestone, even if we already know it will not be done. This is something we should avoid, since we want to be transparent and consistent in our communication.

Proposal

Keep issues up to date with our current understanding.

• if we are sure the issue will not be done, we should remove the milestone and the gitlab-ce~992791 label and reschedule
• if we already know the issue is "unlikely to be done", we could consider to move it as gitlab-ce~992792
• if there are good chances the issue will be done, we can keep the gitlab-ce~992791 label

This introduces a problem: we cannot rely on labels at the end of the cycle to check how many issues were done, how many were missed, based on the original plan. Because the original plan is not available anymore in issues.

The quick solution is to "freeze" the plan in a Google doc at the beginning of the cycle (8th) with the list of gitlab-ce992791 and gitlab-ce992792 items. This list will be compared with the "done" list at the end of the cycle.

The proper solution is to have a way to do it with GitLab. At the moment, I don't see a simple way to do it without adding another label, that may be overwhelming. So ideas are really welcome!

If this will become a new "feature", we'll give more planning and tracking capabilities to all our users.

What does success look like, and how can we measure that?

How many EMs are using GitLab to track how the release cycle went based on an original plan, but still keeping expectations in issues up to date with the current understanding.