Adapt to closing the milestones only after expired for 3 months

During the discussion over gitlab-org/quality/triage-ops#366 (closed), we reached to a conclusion that, only close the milestone after it's expired for 3 months will currently work best for us. Here are a few reasons:

  • The burndown chart is only looking at milestone date, not the state of being open or not: !36709 (comment 263659460) This means closing the milestone or not doesn't affect burndown chart at all.
  • Our security release workflow is based on milestones. Previously, we're doing it on dev.gitlab.org therefore the milestones defined on GitLab.com doesn't affect it. Now we moved the workflow to GitLab.com, sharing the same milestones: gitlab-org/quality/triage-ops#366 (comment 265311271) We can change the scripts we're using, but that requires some more works and we're not clear yet how we might want to decouple them: gitlab-com/gl-infra/delivery#610 (comment 266847081) Therefore, just not close the milestone so early is the easier approach, which also makes sense if we're still maintaining them (same idea as stable branches).

This leads us to !36709 (merged) to update the policy, but there's a few consequence and we need to follow up, too:

@joshlambert I am not fully sure about what we need to change. Could you please be more specific, like showing the line like:

  • Insights
  • Website pages
  • Burndown charts
  • Triage scripts

On the other hand, I don't understand what we need to change for the kickoff page. It doesn't seem to look at the milestone state for me.

As far as I know, we don't need to change insights either. Burndown charts should be fine unless it's not the built-in burndown charts.

For the triage scripts we're already in the process of updating it.

Required changes:

/cc @kencjohnston @ebrinkman @fseifoddini @kwiebers @meks @gweaver @marin

Edited by Lin Jen-Shin