People don't understand the Github issue labels we use, or our general issue lifecycle.
Document it.
bradfitz
All 22 comments
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.
ALTree
on 22 Dec 2016
@ALTree, ah, great. Much less work to do than I thought.
bradfitz
on 22 Dec 2016
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?
dhananjay92
on 22 Dec 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.
ALTree
on 22 Dec 2016
I don't think that will help much.
If you don't see the gopherbot notification comment, then it's also
likely you won't see the updated status either.
(I'm speaking from my perspective, I subscribe to all issue
emails, and work from email client. I don't usually click the
issue link to check its label changes.)
Also, the reason two or more contributors all pick the same
issue is usually because when they started, none of them
has pushed a CL to gerrit yet. A new label set by gopherbot
won't solve this race.
minux
on 22 Dec 2016
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.
dhananjay92
on 22 Dec 2016
But gopherbot will also need to remove the label when the CL is abandoned.
Right now, you can approximate that by using -commenter:gopherbot:
is:issue is:open label:NeedsFix -commenter:gopherbot
minux
on 22 Dec 2016
You can also use the dashboards to find open issues for the current
release.
On Fri, 23 Dec 2016, 08:00 Minux Ma notifications@github.com wrote:
But gopherbot will also need to remove the label when the CL is abandoned.
Right now, you can approximate that by using -commenter:gopherbot:
is:issue is:open label:NeedsFix -commenter:gopherbot—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/18413#issuecomment-268889505, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA8ZdZWBjjFwhc64Na3xd5cmzE_KRks5rKuTugaJpZM4LT9mt
.
davecheney
on 22 Dec 2016
Yeah, perhaps we should mention dev.golang.org more prominently
in golang.org/project.
minux
on 22 Dec 2016
Is it linked from the contributions page and or wiki? That might be a
concrete step towards resolving the motivation behind this issue.
On Fri, 23 Dec 2016, 08:40 Minux Ma notifications@github.com wrote:
Yeah, perhaps we should mention dev.golang.org more prominently
in golang.org/project.—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/18413#issuecomment-268896587, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-KFy2uBekJT_4RrHot4yBsbvMslks5rKu5dgaJpZM4LT9mt
.
davecheney
on 22 Dec 2016
In #18539, I made the following comment regarding HelpWanted and Suggested
labels:
the Suggested label has the closest meaning to the proposed Beginner label.
HelpWanted is for issues that the core members don't have enough experience
or energy to track down, and it's usually for pretty hard platform
dependent issues.
However I didn't know that we also have an ExpertNeeded label, which
doesn't exist at least in the Google Code Issue Tracker, and it clashes
with my suggested definition of HelpWanted.
I reviewed the list of issues with label HelpWanted, and it seems they fit
my definition, and we don't need ExpertNeeded label (which as for now,
doesn't label any issue).
minux
on 6 Jan 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.
bradfitz
on 6 Jan 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.
ALTree
on 6 Jan 2017
Removing HelpWanted and replace with Suggested (for simple issues)
and ExpertNeeded (for my proposed definition) SGTM.
minux
on 6 Jan 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, ...
msiebuhr
on 6 Jan 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.
bradfitz
on 6 Jan 2017
In the old Google Code issue tracker, we have Size-Small,
Size-Medium, Size-Large, Size-XLarge tags. Perhaps we
can resurrect those as an indication of hardness. People
looking for simple things to do can check all the Size-Small
ones. (Perhaps we even had a Size-Tiny class?)
minux
on 6 Jan 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.
bradfitz
on 6 Jan 2017
The original Size tag seems to indicate estimated time spent
designing+coding+testing.
(I believe Russ is usually doing the labeling.)
I totally agree that it's really hard to estimate this without actually
trying to fix the issue.
Perhaps we just remove Suggested and HelpWanted, and only leave
ExpertNeeded.
minux
on 6 Jan 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.
msiebuhr
on 7 Jan 2017
I created https://golang.org/wiki/IssueLabels the other day but it needs fleshing out. Help wanted!
bradfitz
on 24 May 2017
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
bradfitz
on 29 May 2019
Related issues
derekperkins
·
180Comments
jessfraz
·
154Comments
rsc
·
242Comments
miekg
·
314Comments
bradfitz
·
158Comments
Most helpful comment
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.