add "Backlog" milestone

[andybons]

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:

• Soon label: "This should be fixed very soon" (used rarely)
• Go1.14 milestone: "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):

• Create the milestone
• Update https://golang.org/wiki/HandlingIssues#milestones

[ALTree]

You write that Backlog means "This should be done, but won't happen in this release", but the same thing is also true for anything in Unplanned, right?

• "This should be done" -> yes, otherwise it wouldn't be in Unplanned, it would be closed
• "but won't happen in this release" -> yes, otherwise it would be in the next release milestone

So what's the difference between Backlog and Unplanned?

[cespare]

With the current regime, it seems to me that each of these repeatedly-punted issues is likely to get some kind of cursory review once per cycle. Even if most of the time the issue is just moved to the next release milestone, this touch point may lead to it being better-labeled (turning it into a proposal), deprioritized (Unplanned), closed as a duplicate of another issue, or in some cases turned into a real release blocker.

Will there be a comparable regular review of the Backlog issues, either once per cycle or on some other schedule?

If not, then is there a practical difference between Backlog and Unplanned?

If nobody has attached their name to an issue, and it's not tied to a particular release, and it doesn't have another label that causes it to be regularly reviewed (like Proposal), then I don't see it getting worked on with any particular urgency beyond what Unplanned issues see today.

Additionally, I expect that Backlog will become the new catch-all label for anything we don't think is important enough to schedule for the current release -- that is, it will become the new Unplanned. So over time the old low-priority issues will be Unplanned and the newer low-priority issues will be Backlog. (That's assuming there's no regular Backlog review process.)

[andybons]

@ALTree I updated the definition of Backlog to be "Someone has plans to work on this, but it won't happen in this release.”

Does that make it more clear?

[bcmills]

So what's the difference between Backlog and Unplanned?

Backlog would be: “Given enough time, someone on the Go team will eventually address this, but not in the current release cycle.”
Unplanned would be: “If you want this to ever happen, you will need to do it yourself.”

[ALTree]

@andybons @bcmills Now is more clear, thanks.

I'm mostly interested in understanding how would I distribute new issues among the two. Basically, if this goes in, the default would still be "Unplanned", unless you plan to fix it yourself (like 6 months from now), or you know for (almost) certain that someone in the Go team is planning to do it.

[andybons]

With the current regime, it seems to me that each of these repeatedly-punted issues is likely to get some kind of cursory review once per cycle. Even if most of the time the issue is just moved to the next release milestone, this touch point may lead to it being better-labeled (turning it into a proposal), deprioritized (Unplanned), closed as a duplicate of another issue, or in some cases turned into a real release blocker.

I have not observed any concerted effort to reevaluate all issues that have been kicked from milestone to milestone. This proposal is the first step in becoming more aggressive in re-triaging issues so that we can plan more effectively.

Will there be a comparable regular review of the Backlog issues, either once per cycle or on some other schedule?

The number of issues is quite large, so every six months may be a bit too often, but yes. Ideally everyone in the community would participate in regular re-triage/reprioritization. This new structure would somewhat force this behavior (tooling could move/ping/take action on an issue from Backlog to Unplanned if it’s been there too long).

[bcmills]

each of these repeatedly-punted issues is likely to get some kind of cursory review once per cycle.

Note that the person tasked with the issue-punting is often not someone with enough context to decide whether it should be reprioritized for the next cycle.

(Re-triage is important, but — in practice — punting milestones is not an effective way to do re-triage.)

[networkimprov]

If "someone has plans to work on this" shouldn't that person be assigned the issue?

If there's a need to re-evaluate issues that are Unplanned or being kicked across milestones, maybe a working group should be formed to do this? Presumably composed largely of folks outside the core team, since they're already overcommitted.

[mvdan]

I agree with this proposal in the sense that many of the issues milestoned to 1.14 don't belong there.

I was also initially a bit confused between Backlog and Unplanned. Hopefully we can add descriptions to the milestones to clarify their intent.

Also, Backlog reads:

but it won't happen in this release

Most of the issues that are assigned to me fall under "I want to do this soon, probably this release, but maybe not". That's just how it is with one's free time. Before this proposal, this usually meant the current release's milestone. What should I do if this proposal is accepted? Add my issues to Backlog by default, and move them to the current milestone only when I'm positive I'll finish them this release?

[FiloSottile]

I see the main difference between Backlog and Unplanned being that the Backlog will be retriaged (into a release milestone, still in Backlog, or down to Unplanned) in the next cycle. This would work well with my crypto issues. Go 1.14 for things I think I can and want to do this release, Backlog for things that I think need to happen but just didn't make the cut, Unplanned for things I'm not sure should happen but are open for feedback or things too big to be likely to get done by me.

If "someone has plans to work on this" shouldn't that person be assigned the issue?

I see assigned issues as "taken" meaning we don't want anyone else to work on it, while we would still take contributions for Backlog or even unassigned Go 1.14 issues.

@mvdan I think it's up to you and how you want to schedule, it's not a strict commitment. Maybe put them all in Go 1.14 at the start of the cycle, and if the freeze is approaching and you realize you won't get to something, move them to Backlog later?

[bcmills]

@mvdan, re Go1.14 vs. Backlog: if you're actively working (or at least actively thinking) on some issue but not sure whether the fix will make the cut, either milestone seems fine.

Mostly I want to be able to communicate clearly in the other direction: “we do intend to do this, but don't be surprised if nobody works on it this cycle.”

[bcmills]

@networkimprov

If "someone has plans to work on this" shouldn't that person be assigned the issue?

I would like to reserve the Assignee to mean “this person is actively working on the issue”.

There are a lot of issues (especially in cmd/go) that could be done by one of many people. If the issue is important enough for the Go team to work on eventually but somebody in the community wants to do it now, I don't want to discourage them from claiming the issue and starting work.

[beoran]

While this proposal could be helpful, I'm worried that the quality of the go compiler and run time is slowly degrading. Perhaps in the near future, a single release should be made, with no new features at all, but where the focus is on fixing as much as possible outstanding bugs?

[andybons]

@beoran that's outside the scope of this proposal and should be brought up in a separate forum.

[neelance]

Backlog would be: “Given enough time, someone on the Go team will eventually address this, but not in the current release cycle.”
Unplanned would be: “If you want this to ever happen, you will need to do it yourself.”

What about a maximum number of releases that an issue can stay in the backlog? If it doesn't make the cut several times in a row, then it is unlikely to do so in subsequent cycles. It effectively turns into "you will need to do it yourself."

[kortschak]

If there is automatic relegation, then it would be good if the gopherbot could note in a comment that this has happened since changing milestone is not, AFAIK, something that a notification is sent for by github.

[networkimprov]

Should most (all?) items in "Backlog" also be tagged "help wanted"? It seems like the latter is underutilized...

I would like to reserve the Assignee to mean “this person is actively working on the issue”.

@bcmills that makes sense, but it would be helpful to see who's got plans for the issue, so a) someone else who wants to work on it knows who to ping, and b) maybe the planner should get a reminder periodically that they meant to tackle it.

[gmichelo]

I like this proposal even if I think issues marked as Backlog might risk to be forgotten.

The number of issues is quite large, so every six months may be a bit too often, but yes. Ideally everyone in the community would participate in regular re-triage/reprioritization. This new structure would somewhat force this behavior (tooling could move/ping/take action on an issue from Backlog to Unplanned if it’s been there too long).

This periodic review is a must if we want to see Backlog's size going down eventually.

[bcmills]

@networkimprov

it would be helpful to see who's got plans for the issue, so a) someone else who wants to work on it knows who to ping,

Someone who wants to work on an issue can comment on that issue. (The right person or people to ping should already be subscribed, and if they aren't that seems like an orthogonal problem.)

and b) maybe the planner should get a reminder periodically that they meant to tackle it.

That's what re-triage is for, but that's generally more effective as an audit or queue than a scattering of individual messages.

[bcmills]

@neelance

What about a maximum number of releases that an issue can stay in the backlog? […] It effectively turns into "you will need to do it yourself."

An issue being in the backlog should not prevent anyone interested from fixing it earlier.
(It's not a fine-grained prioritization, but it still seems helpful to at least be able to communicate the fairly large gap between “probably eventually” and “probably never”.)

[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).

[andybons]

@neelance there will likely be tooling that punts issues from Backlog to Unplanned if they remain there for too long without any activity. How we plan to coordinate issue re-triage with the community is something we’re thinking about as well, but we can talk more about that part outside this issue if you like.

[gmichelo]

Perhaps we would also need a NeedsTriage or NeedsReTriage in order to flag stale issues. Those that are about to be moved from Backlog to Unplanned could be first flagged with this label.

[neelance]

@andybons Thanks for the clarification. Sounds good to me.

[rsc]

I don't see any objection here to a Backlog milestone. (A few suggested tweaks, but no objection to the idea.) It sounds like we've reached consensus and that this is a likely accept.

Leaving open for a week for final comments.

[rsc]

No final comments. Accepted.

[rsc]

And done.