Skip to content

Perform milestone cleanup on the milestone due date

Brian Williams requested to merge bwill/change-milestone-cleanup-schedule into main

Why is this change being made?

💡 Provide a detailed answer to the question on why this change is being proposed, in accordance with our value of Transparency.

Please add the details saying why, not just what in this section. Example: We have discussed the topic in Slack - (copy of Slack conversation). The current process is not efficient, this MR makes the description of X more clear, and helps move Y forward.

Relates to: gitlab-org/quality/triage-ops#1484 (comment 1771882987)

Issues and merge requests should be carried over on the milestone due date instead of the day before release.

The triage-ops changes to support this proposal are already prepared: gitlab-org/quality/triage-ops!2677

Why?

  1. Planning for the next milestone happens at this time.
  2. The release candidate is selected on the due date. Merge requests which have not been merged at this point are most likely slipping to the next release.

With how things work currently, planning is a bit troublesome because:

  1. We begin planning for the next milestone a week before
  2. At this time, work from the previous milestone has not been carried over yet and doesn't show up if you're looking at what's assigned to the next milestone.
  3. This work then gets carried over after planning is done, which leads to a lack of visibility for carry-over work

If we make this change, then work that was not completed in the previous milestone will show as allocated to the upcoming milestone when doing planning. This will increase visibility of carry-over work and help prevent over-allocation.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
  • Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
    • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
    • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
    • The when to get approval handbook section explains the workflow in more detail
  • For transparency, share this MR with the audience that will be impacted.
    • Team: For changes that affect your direct team, share in your group Slack channel
    • Department: If the update affects your department, share the MR in your department Slack channel
    • Division: If the update affects your division, share the MR in your division Slack channel
    • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR

Commits

  • Perform milestone cleanup at the end of the milestone due date

Edited by Brian Williams

Merge request reports

Loading