Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add "Backlog" milestone #34376

Closed
andybons opened this issue Sep 18, 2019 · 27 comments
Closed

add "Backlog" milestone #34376

andybons opened this issue Sep 18, 2019 · 27 comments

Comments

@andybons
Copy link
Member

@andybons andybons commented Sep 18, 2019

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):

@andybons andybons added the Proposal label Sep 18, 2019
@andybons andybons added this to the Proposal milestone Sep 18, 2019
@ALTree

This comment has been minimized.

Copy link
Member

@ALTree ALTree commented Sep 18, 2019

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

This comment has been minimized.

Copy link
Contributor

@cespare cespare commented Sep 18, 2019

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

This comment has been minimized.

Copy link
Member Author

@andybons andybons commented Sep 18, 2019

@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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Sep 18, 2019

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

This comment has been minimized.

Copy link
Member

@ALTree ALTree commented Sep 18, 2019

@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

This comment has been minimized.

Copy link
Member Author

@andybons andybons commented Sep 18, 2019

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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Sep 18, 2019

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

This comment has been minimized.

Copy link

@networkimprov networkimprov commented Sep 19, 2019

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

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented Sep 19, 2019

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

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Sep 19, 2019

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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Sep 19, 2019

@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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Sep 19, 2019

@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

This comment has been minimized.

Copy link

@beoran beoran commented Sep 24, 2019

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

This comment has been minimized.

Copy link
Member Author

@andybons andybons commented Sep 24, 2019

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

@neelance

This comment has been minimized.

Copy link
Member

@neelance neelance commented Sep 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@kortschak kortschak commented Sep 25, 2019

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

This comment has been minimized.

Copy link

@networkimprov networkimprov commented Sep 26, 2019

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.

@bigmikes

This comment has been minimized.

Copy link
Contributor

@bigmikes bigmikes commented Sep 26, 2019

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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Sep 26, 2019

@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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Sep 26, 2019

@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

This comment has been minimized.

Copy link
Member

@neelance neelance commented Sep 26, 2019

@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

This comment has been minimized.

Copy link
Member Author

@andybons andybons commented Sep 26, 2019

@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.

@bigmikes

This comment has been minimized.

Copy link
Contributor

@bigmikes bigmikes commented Sep 26, 2019

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

This comment has been minimized.

Copy link
Member

@neelance neelance commented Sep 26, 2019

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

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Oct 2, 2019

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

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Oct 9, 2019

No final comments. Accepted.

@rsc rsc modified the milestones: Proposal, Go1.14 Oct 9, 2019
@rsc rsc changed the title proposal: add "Backlog" milestone add "Backlog" milestone Oct 9, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@rsc rsc closed this Oct 9, 2019
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Oct 9, 2019

And done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.