Proposal: When a milestone ends, close expired milestone and bulk reschedule unfinished work (Issues& MRs) to the next milestone

Followed up from https://gitlab.com/gitlab-org/gitlab-ee/issues/8816 and also from the recent Engineering Staff meeting.

Problem statement

We currently do not have a standard practice of following up on unfinished work.

• Milestones are left expired.
• Work associated with expired milestones is left unfinished.

We are now already at the end of 11.6 but there are opened issues and merge requests in 11.4 and 11.5.

• 11.4, due Oct 22nd.
  • 15 open issues in 11.4 https://gitlab.com/groups/gitlab-org/-/issues?milestone_title=11.4
  • 30 open MRs in 11.4 https://gitlab.com/groups/gitlab-org/-/merge_requests?milestone_title=11.4&state=opened
• 11.5, due Nov 22nd
  • 46 open issues in 11.5 https://gitlab.com/groups/gitlab-org/-/issues?milestone_title=11.5
  • 115 open MRs in 11.5 https://gitlab.com/groups/gitlab-org/-/merge_requests?milestone_title=11.5&state=opened

11.4	11.5

Upon a deeper look, these are mostly work in GitLab CE, GitLab EE, GitLab QA and Workhorse.

Consequences

• This is causing confusion with capacity planning and milestones set in issues/MRs.
• Our metrics are not accurate. Our burndown chart for 11.4 continues to get updated well into the development period of 11.7.
• Issue boards that use Upcoming milestone or started milestone still show work from expired milestones.
• Frankly this is a bit of a mess 🙂

Proposal

We should reschedule all unfinished work to the next milestone once a milestone has expired and close the milestone. This would happen once a month on the 7th (or a bit earlier). For example: on Jan 7th, we will close 11.6 which has expired and move all remaining work to 11.8 which is the next milestone in planning.

The mechanism here would be similar to closing a sprint in Jira & moving tasks to the next sprint.

• This would be a forcing function for a more accurate capacity planning.
• This would also result in capturing more accurate metrics per milestone.
  • See average MRs per developer per milestone https://quality-dashboard.gitlap.com/groups/gitlab-org/developer_productivity_metrics
• Help make boards that use Upcoming milestone or started milestone more usable.
  • 

Process documentation

After the initial discussions with @victorwu @rymai and @godfat in https://gitlab.com/gitlab-org/gitlab-ee/issues/8816 we don't have to wait for the close & clean up feature proposed and just use the bulk issue editing to move the milestones of issues and MRs.

• Close the milestone when it has expired after the development period of each month, on the 7th after documentation is done.
• Before closing the milestone, bulk reschedule the remaining work to the next started milestone.
  • This can be done via the issue editor
  • Search for issues on the expired milestone and bulk remove them
• Bulk reschedule for the following projects.
  • https://gitlab.com/gitlab-org/gitlab-ce
  • https://gitlab.com/gitlab-org/gitlab-ee
  • https://gitlab.com/gitlab-org/gitlab-qa
  • https://gitlab.com/gitlab-org/gitlab-workhorse
• Automate this process via a schedule in CI

Process changes

• Triage automation implementation gitlab-org/quality/triage-ops!83 (merged)
• Update to the engineering handbook !18889 (merged)
• Link from Process.MD

There maybe be a number of issues in a milestone that is still valid but gets incorrectly moved to the next. However, these should be minimal.

Regressions: Milestones in regressions should be used to schedule when the actual work will finish. If its past freeze date and no exception request needed the work here should be rolled forward. Outside of this, regression labels should be used to track regressions.

UX and Doc work: We do cleanup on the 7th which is after the release but before the kickoff

We are also limiting the number of projects in this iteration to the 4 above with the most offending staleness.

Reason for picking the 7th

By month M, 7th: Completed m issues with docs have been merged into master. Un-started or unfinished m issues are de-scoped from m, with m being removed from them.

Let's start with the EMs and RMs first, can all of you please provide input into this proposal?

BE EMs: @smcgivern @DouweM @lmcandrew @marin @rnienaber @DylanGriffith @erushton @sengelhard

FE EMs: @andr3 @ClemMakesApps @jhampton @dennis

RMs: @jarv @ahanselka

/cc @edjdev @tommy.morgan @dhavens @stanhu @kathyw