Milestone assignment and deliverables/stretch labels

Herewith begins a nice healthy debate.

Milestones are the primary indicator as to when something is due for delivery and when it will ship. It's a field that stands out all on its own. Labels are generally meta information and in many cases can be heavily labelled to the point where it's just a wall of ignorable coloured pills.

There are many issues that get moved from one release to another, below find a few of examples:

https://gitlab.com/gitlab-org/gitlab-ce/issues/26360 was moved just a single milestone and you will even find the comment

Milestone 9.0 now. Rapidly losing faith...

https://gitlab.com/gitlab-org/gitlab-ce/issues/20303 Started life out in 8.14 and has gone through every milestone to date without being shipped.

https://gitlab.com/gitlab-org/gitlab-ce/issues/19396 Started at 8.11 got moved numerous times and is now lingering in the backlog - whatever that means.

I don't think we can expect our community and our customers to have to know that if something is a gitlab-ce~992792 then it may not be in the release. Having to read a manual in order to follow an issue seems disingenuous when you have fields specifically designed for time-based delivery.

My proposal would be to have a prioritised Bucket o' Stretch, perhaps we can use an ordered issue board once we have the ability to order issues by priority. When all of the deliverables for a milestone have been reached and a developer has time to spare in the release, they can reach into the bucket, knowing that what's on top is the most important (taking into account time remaining and weight) and work on a stretch issue. At that point, the issue gets given the appropriate milestone.