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

wiki: document Github Issue labels #18413

Closed
bradfitz opened this issue Dec 22, 2016 · 22 comments
Closed

wiki: document Github Issue labels #18413

bradfitz opened this issue Dec 22, 2016 · 22 comments

Comments

@bradfitz
Copy link
Contributor

People don't understand the Github issue labels we use, or our general issue lifecycle.

Document it.

@bradfitz bradfitz added this to the Unreleased milestone Dec 22, 2016
@bradfitz bradfitz self-assigned this Dec 22, 2016
@ALTree
Copy link
Member

ALTree commented Dec 22, 2016

There's a page with a description of the issue lifecycle on the wiki:

https://github.com/golang/go/wiki/HandlingIssues

I'm not sure about the other labels.

@bradfitz
Copy link
Contributor Author

@ALTree, ah, great. Much less work to do than I thought.

@JayNakrani
Copy link
Contributor

While we're at it, should we add one more state, namely FixInProgress, between NeedsFix and Fixed? I've seen a few CL collisions between contributors. We can make gopherbot add that label when it adds comment CL mentions this issue. WDYT?

@ALTree
Copy link
Member

ALTree commented Dec 22, 2016

Gopherbot already posts on the issue after a Gerrit mention, I'm not sure what a new label would add.. If you see a change mentioned at the end of the thread it should be obvious that someone is working on a patch.

@minux
Copy link
Member

minux commented Dec 22, 2016 via email

@JayNakrani
Copy link
Contributor

That would make easier to search for issues that needs fix and for which a CL hasn't been proposed yet; with is:issue is:open label:NeedsFix -label:FixInProgress. Right now, you'd need to open each issue to see if someone has already sent out the fix.

@minux
Copy link
Member

minux commented Dec 22, 2016 via email

@davecheney
Copy link
Contributor

davecheney commented Dec 22, 2016 via email

@minux
Copy link
Member

minux commented Dec 22, 2016 via email

@davecheney
Copy link
Contributor

davecheney commented Dec 22, 2016 via email

@minux
Copy link
Member

minux commented Jan 6, 2017 via email

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 6, 2017

By your definition, I overuse "HelpWanted", because HelpWanted is basically all I ever use.

I don't like deciding whether something is for beginners or not, so I never "Suggest" anything.

If we keep them, I'd like to re-color them:

Suggested -- green
HelpWanted -- yellow
ExpertNeeded -- red

(Yes, I know some experts are red/green colorblind.)

But really I'd like to delete "HelpWanted" (it's redundant; we want help with everything!), and maybe rename one or both of the other two.

@ALTree
Copy link
Member

ALTree commented Jan 6, 2017

You could re-label all the old HelpWanted issues (back then when it meant "this is hard platform-specific stuff we need help with") to "ExpertNeeded", and re-label the newer HelpWanted issues (the ones where it was used like a "yeah this would be nice to have") to "Suggested", and then delete HelpWanted.

@minux
Copy link
Member

minux commented Jan 6, 2017 via email

@msiebuhr
Copy link
Contributor

msiebuhr commented Jan 6, 2017

I don't like deciding whether something is for beginners or not, so I never "Suggest" anything.

Please do. You're in a much better position to guesstimate than most (if not all) beginners in the project.

And if suggested is simple/small-ish, mostly uncontroversial, can't it be renamed to something along those lines? Say, beginner, trivial, easy, ...

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 6, 2017

Please do. You're in a much better position to guesstimate than most (if not all) beginners in the project.

It's not a possible task. Even with some very capable being on the Go team, what qualifies as easy for us varies drastically from person to person. It all depends what experience you already have.

@minux
Copy link
Member

minux commented Jan 6, 2017 via email

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 6, 2017

Size is not always possible to estimate for the same reasons that difficulty isn't easy to estimate.

Does size mean lines of code, design time, time spent bikeshedding English, some mix of all? It'll never be accurate.

@minux
Copy link
Member

minux commented Jan 6, 2017 via email

@msiebuhr
Copy link
Contributor

msiebuhr commented Jan 6, 2017

What about an opt-in size-small? Things you positively know will be quick-ish to fix. Yes; you could fix the bug in five minutes, but you may end up on-boarding a new contributor. I daresay optimising for the latter is a better long-term investment.

@bradfitz
Copy link
Contributor Author

I created https://golang.org/wiki/IssueLabels the other day but it needs fleshing out. Help wanted!

@bradfitz
Copy link
Contributor Author

GitHub natively supports documenting your own labels now, so I've modified https://golang.org/wiki/IssueLabels to just refer people to https://github.com/golang/go/labels

@golang golang locked and limited conversation to collaborators May 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants