Ping the assignee(s) on merged merge requests when the milestone is missing
Problem
It's quite usual and easy to forget to add a milestone once you merge a merge request, especially when it's a Community contribution which usually doesn't resolve issue(s) that have a milestone attached.
This causes a) uncertainty on whether a merge request should be picked up in a release or not and b) innacurate metrics on throughput and other performance metrics (cc @meks @dhavens @clefelhocz1).
Besides that, a lot of time is put on figuring out which merge requests are missing a milestone, defining which milestone to add depending on when it was merged, pinging the right person to verify or add a milestone, and more. (cc @rpaik @dplanella)
Proposal
Add a policy rule for the @gitlab-bot to ping the assignee(s) one day after the merge request has been merged and there's no milestone attached for gitlab-ce
and gitlab-ee
projects.
Risks
The maintainer (assignee) usually, if not always, remains in the assignee list once the merge requests is merged. Now that merge requests support multiple assignees there's a chance that the assignee list contains more than one person.
- Thought: Pinging all the assignees could raise awareness on this issue.
- Suggestion: Mentioning instead of directly addressing people could make this subtly less urgent.
-
Suggestion: To avoid pinging community members, let's limit this to members of the
gitlab-org
group. -
Note: On some large merge requests there's a chance to end up with multiple
gitlab-org
members (from backend, frontend, and more) on the assignee list while some of them could also have Maintainer access, too. This could also limit the list to members with Maintainer access which again could be more than one person but let's skip this for now and come back if needed.
This could be optimized to take into account the auto-deploy transition but the proposal above should be effective even with the auto-deploy deployments. (cc @marin)