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

github: delete the GoCommand label #27394

Open
FiloSottile opened this issue Aug 30, 2018 · 11 comments

Comments

@FiloSottile
Copy link
Member

commented Aug 30, 2018

GoCommand was added by @rsc is 2016 to be used in 2017. It doesn't seem we are using it much anymore, so we should probably delete it.

I propose we keep accumulating these kinds of go command issues and try to take a coherent look at them in the first half of next year.

I'll create a new GoCommand label. Feel free to label other (proposal or non-proposal) issues with that too.

#15513 (comment)

If we are keeping instead and applying it to all cmd/go issues we should make gopherbot apply it.

/cc @bradfitz @andybons @dmitshur @bcmills

@FiloSottile FiloSottile added this to the Unreleased milestone Aug 30, 2018

@ALTree

This comment has been minimized.

Copy link
Member

commented Aug 30, 2018

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

@ysmolsky

This comment has been minimized.

Copy link
Member

commented Sep 4, 2018

What about Unfortunate?

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 5, 2018

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.

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 5, 2018

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 5, 2018

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.

@bcmills

This comment has been minimized.

Copy link
Member

commented Sep 5, 2018

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.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 5, 2018

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.

@FiloSottile

This comment has been minimized.

Copy link
Member Author

commented Sep 5, 2018

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.

@dmitshur

This comment has been minimized.

Copy link
Member

commented Jan 13, 2019

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.

@bcmills

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

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.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

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)

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