wiki: document Github Issue labels #18413
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, ah, great. Much less work to do than I thought. |
|
While we're at it, should we add one more state, namely |
|
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. |
|
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.
|
|
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. |
|
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 can also use the dashboards to find open issues for the current
release.
https://dev.golang.org/
…On Fri, 23 Dec 2016, 08:00 Minux Ma ***@***.***> 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
<#18413 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA8ZdZWBjjFwhc64Na3xd5cmzE_KRks5rKuTugaJpZM4LT9mt>
.
|
|
Yeah, perhaps we should mention dev.golang.org more prominently
in golang.org/project.
|
|
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 ***@***.***> 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
<#18413 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA-KFy2uBekJT_4RrHot4yBsbvMslks5rKu5dgaJpZM4LT9mt>
.
|
|
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).
|
|
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 (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. |
|
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. |
|
Removing HelpWanted and replace with Suggested (for simple issues)
and ExpertNeeded (for my proposed definition) SGTM.
|
Please do. You're in a much better position to guesstimate than most (if not all) beginners in the project. And if |
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. |
|
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?)
|
|
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. |
|
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.
|
|
What about an opt-in |
|
I created https://golang.org/wiki/IssueLabels the other day but it needs fleshing out. Help wanted! |
|
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 |
People don't understand the Github issue labels we use, or our general issue lifecycle.
Document it.
The text was updated successfully, but these errors were encountered: