Go: x/build/cmd/gopherbot: auto-Subscribe owners to reported issues based on directory

[kevinburke]

We now have an owners file which assigns various Gophers as owners/cc'd on issues for different directories.

It would be good to match incoming issues and auto-subscribe the relevant people, e.g. to do in an automatic fashion what @bcmills is doing manually here. https://github.com/golang/go/issues/27524#issuecomment-419147447

[mvdan]

I assume this won't be done for the entire backlog of issues - it could mean hundreds of notifications for quite a few people :)

It would also be good if this was only done for issues that are still open after an amount of hours. Sometimes, issues are closed as invalid or duplicates after a few hours, and in those cases there's little point in pinging the owners.

Lastly: should this be skipped if any of the owners has already replied to the thread, or been pinged in it?

[agnivade]

The challenge is to automatically figure out whom to ping from the issue title (which does not always have the package: prefix) and the issue body.

[josharian]

I think gopherbot should wait for the issue to be manually retitled. This also helps with the issue raised by @mvdan.

[kevinburke]

Lastly: should this be skipped if any of the owners has already replied to the thread, or been pinged in it?

I'm not sure there's an API for subscribing other people to issues so yeah my idea was just to have gopherbot mention the owners, which subscribes them, if they're not subscribed already.

I think if you are currently subscribed and then unsubscribe, Github is smart enough to know you shouldn't be resubscribed just because someone at-mentioned you.

I assume this won't be done for the entire backlog of issues - it could mean hundreds of notifications for quite a few people :)

Yeah agree that would be a bad idea.

[bcmills]

I think gopherbot should wait for the issue to be manually retitled.

I don't think we need to wait if there is already a valid path in the title: folks who know to add the path prefix usually also have a pretty good idea which one.

[bcmills]

Sometimes, issues are closed as invalid or duplicates after a few hours, and in those cases there's little point in pinging the owners.

I've been thinking about this a bit.

There's not much point in waiting if a human has already looked at the issue and decided that it is valid. In practice, the NeedsInvestigation, NeedsDecision, NeedsFix labels indicate that a human has looked at the issue, and WaitingForInfo indicates whether the human has decided that the issue is complete enough for further discussion.

So I would say that GopherBot should auto-add owners if:

• the issue is still open, and
• the issue _is not_ labled WaitingForInfo, and one of:
  
  
  
  • the issue _is_ labeled NeedsInvestigation, NeedsDecision, or NeedsFix, or
  
  
  • the issue does not have a Needs label, and has been open and without the WaitingForInfo label for some interval of time (one business day?)
  
  

CC @golang/osp-team

[bcmills]

And we should probably only apply the “open and without label” condition to issues created after some epoch, or use a formula to limit the rate at which older issues are CC'd.

[bcmills]

I'm on issue-triage interrupts this week and I'm tired of manually CC'ing owners, so I'm planning to implement this.

[ianlancetaylor]

Note that I find the CL auto-reviewers to be more spammy than useful. There's no point to CCing rsc on everything. But perhaps the idea can be more useful for issues as they are less likely to spread across multiple directories.

[bcmills]

I suspect that we can prune down the CL auto-reviewers significantly: they're currently based on source code paths rather than CL-titled paths, whereas each issue generally only has a single path.

For issues in particular, I'm planning to auto-CC owners only after the issue has been triaged by a human, and to skip CC'ing issues that already have an assignee (since the assignee can contact anyone they want for assistance).

If we can stick to one path (or a small number of paths) per issue or CL, then the problem of a small number of people getting CC'd on everything boils down to one of distributing and focusing ownership: if one person is a primary owner for a significant fraction of issues or changes, that makes them a bottleneck for discussions and reviews, not just an unfortunate target for spammy updates.

[bcmills]

My current plan for keeping the spam level down is to avoid adding the Secondary reviewers unless there are fewer than two Primary, and to use a one-year rolling window to add mentions to existing issues.

(Two seems like a good number, because we need one author and one reviewer to write a fix, and in general we need two knowledgeable people to be able to meaningfully discuss a potential solution.)

[bcmills]

I'm also planning to start with a one-week idle window for issues that lack Needs labels. That way, we won't start pinging every issue filed over a holiday weekend, and don't need to hard-code Google's vacation calendar in gopherbot.

[gopherbot]

Change https://golang.org/cl/171036 mentions this issue: devapp/owners: add new owners on the Go team at Google

[gopherbot]

Change https://golang.org/cl/170863 mentions this issue: cmd/gopherbot: CC triaged issues to owners

[gopherbot]

Change https://golang.org/cl/171242 mentions this issue: devapp/owners: use path prefixes instead of string prefixes for matching

[gopherbot]

Change https://golang.org/cl/171358 mentions this issue: devapp/owners: remove catchall entry for the 'go' repo

[gopherbot]

Change https://golang.org/cl/172278 mentions this issue: devapp/owners: add owners for build, debug, gccgo, tools, and go/src/cmd/asm

[gopherbot]

Change https://golang.org/cl/217539 mentions this issue: devapp/owners, internal/gophers: add owners for {pkg,learn,}.go.dev