The package-management label, too. It was superseded by modules.

What about Unfortunate?

I think we should get rid of Unfortunate too. Everything that previously would have had that label either should be possible as a Go2Cleanup or should be filed as an upstream issue against some other project.

I expect that the GoCommand label was added to make searches work better, but now that we have maintner we can bolt on our own arbitrary search functionality (e.g. rsc.io/github/issue).

It'd still be nice to keep GitHub searching usable, which means keeping labels even if they're not needed with our own searching systems.

For instance, I used to have a "Builders" label, then Russ deleted it, then I asked for it back, specifically because I couldn't search GitHub for "x/build" in a title.

If anything, I'd add more labels, having Gopherbot auto-add package labels from titles. So a bug filed for "net/http: foo bar" would auto-add the "pkg-net/http" label or similar.

I don't want to teach everybody to use maintner for the same reason we started moving to accept GitHub PRs and moved to GitHub (issues) in the first place. That's where users are & what they know, so let's try to make it work for GitHub-only users.

I'd be fine with more labels too, but the current state where we have only a few labels is awkward.

One simple(?) option might be to have Gopherbot auto-add (and auto-create) labels for each prefix in https://dev.golang.org/owners/, or add similar table entries for labels.

One simple(?) option might be to have Gopherbot auto-add (and auto-create) labels for each prefix in https://dev.golang.org/owners/, or add similar table entries for labels.

SGTM. Should be simple.

I believe a good dev dashboard would spare us from a endless constellation of labels, but I'm not particularly opposed. I think we should keep Unfortunate though, it's a relevant final state that acknowledges an issue and the fact that we can't fix it.

https://groups.google.com/d/msg/golang-dev/nVS0dutRTy0/32Gq9omVCwAJ may be relevant.

For example, it's now possible to view all x/build issues via goissues.org/golang.org/x/build/... (/cc @bradfitz), and analogously for other subrepos.

All issues for cmd/go and contained packages can be viewed via goissues.org/cmd/go/..., or more specific import path patterns if desired.

Just net/http issues are shown at https://goissues.org/net/http, but that's not new.

Given the improvements in goissues.org and the availability of dev.golang.org, I'm ok with removing the GoCommand label. At this point I've basically given up on using GitHub search to triage cmd/go issues, but we've got enough other tooling that I'm ok without it.

In particular, it turns out to be really easy to use maintner to export the list of all Go issues to CSV, and from there I can use whatever spreadsheet voodoo I like (and I like spreadsheet voodoo!) to reorganize it.

Even with maintner I still use GitHub search regularly. And I suspect the majority of our users use GitHub search instead of maintner.

So I think GitHub search should still be usable, so I'm still in favor of #27394 (comment) (gopherbot auto-adding/removing package-specific labels to bugs based on issue titles)