Ask questionsadd "Backlog" milestone
There are too many open issues in the Go1.14 milestone (and historically). This causes milestones to be considerably less useful as a planning mechanism.
Moving issues that likely won't be fixed in 1.14 to the
Unplanned milestone (defined as "might be fixed at some point, but nobody is planning to do it.") isn't sufficient as it will appear as if we are deprioritizing the issue to a bucket that we don't pay attention to (plus we do actually plan to fix the issue, just not in the current milestone).
Kicking all issues to the following milestone (1.15 in this case) makes it difficult to plan that milestone due to the same problems stated above.
I propose we add a new milestone
Backlog to mean "issues that really should get fixed, but will not happen in this release".
Taking the current cycle as an example, this would result in the following priority levels:
Soonlabel: "This should be fixed very soon" (used rarely)
Go1.14milestone: "This really should get done in this release"
Backlog: "Someone has plans to work on this, but it won't happen in this release"
Unplanned: "No one has plans to work on this"
If approved, the following things would need to happen (will update this list accordingly):
Answer questions neelance
@bcmills Did I phrase it badly? I was not trying to say anything about fixing it early. I'm just saying that with every release that passes with an issue in the backlog not being fixed, the probability of "probably eventually" becomes lower. If it wasn't important enough for several releases, it is unlikely to be important enough to be included in future releases. So the issue shifts from "probably eventually" to "probably never". I'm just suggesting that a default expiry of issues from backlog to unplanned would mitigate the concern that the backlog can grow without bounds (which may or may not be a problem).