Proposal: Beginner issues

[msiebuhr]

I propose that a beginner label is added to issues deemed suitable for people dipping their toes in developing golang itself.

Currently, as a novice, it can be quite difficult find an appropriate issue to work on. Partly due to unfamiliarity with golang internals as well as (speculation on my part) old-timers doing "drive-by" commits that while trivial to them, would be suitable for beginners to start out with.

In all, begin adding beginner-label to suitable issues.

If that's not successful, remove the tag agin (say, 500+ open beginner issues). If successful, possibly have frequent committers show some restraint in doing drive-by commits and do beginner-issues instead. Same can possibly be done for CL reviews with beginner-review.

[ALTree]

I think (I may be wrong) that the project uses the HelpWanted label for this (maybe it's more like an "up-for-grabs" tag, but it's generally not used on really complex bugs, so I think it also somewhat works as a "suitable-for-beginners" label).

There's also the Suggested label.

Maybe it should be documented somewhere that the HelpWanted, Suggested, and Documentation labels could be a good place to start for new contributors.

Also, my personal opinion is that reliably identifying "beginner issues" is much harder that it sounds.

[bradfitz]

A "Beginner" label has been suggested and rejected in the past.

For two reasons: what people are good at varies. And it were totally trivial for everybody, we would've just fixed it immediately and not kept a bug open for a long time.

Really, we need to figure out and document the difference between "Suggested" and "HelpWanted". That is #18413.

I'm going to close this in favor of #18413.

[rakyll]

IMHO, documentation bugs might be very hard and require knowledge about the historical decisions. Behaviour clarifying doc issues might be easier to begin with.

Similar to other open source projects, most easy/trivial issues are fixed immediately. Long standing issues are often the ones that requires investigation and consensus. Watching the issue tracker daily and fixing the trivial looking new issues would be a way to begin.

Another good way is to Go is to go through the issue tracker daily and contribute to the discussion. Over time, you develop knowledge to do more.

[minux]

I think 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.

[bradfitz]

@minux, then what is "ExpertNeeded"? But this discussion should be on #18413.

[msiebuhr]

For two reasons: what people are good at varies. And it were totally trivial for everybody, we would've just fixed it immediately and not kept a bug open for a long time.

But when you're new to the project all the other stuff (CL, magic-git-stuff, gerrit) can be pretty overwhelming on it's own. Having to figure out non-trivial Go internal on top of that doesn't help.

I posit that leaving some trivial bugs open will lower the barrier significantly. At least on level with, say #18517.

At least my most recent stab at contributing (https://go-review.googlesource.com/c/19720/) left me quite disheartened about putting too much effort into future contributions. Figuring out process took some time; getting stuck between two reviewers having quite different opinions about where to go didn't help.

[bradfitz]

At least my most recent stab at contributing (https://go-review.googlesource.com/c/19720/) left me quite disheartened

Looks like you got it submitted, though.

getting stuck between two reviewers having quite different opinions about where to go didn't help.

Not all patches go in immediately with zero feedback. Sorry?

Touch low-level stuff that affects everybody and a prolonged discussion is not uncommon.

I don't like having discussions on closed issues. If you're proposing a meaning for what these labels are about, please add your comments to #18413. It sounds like you want a way to search for "not controversial, no design decisions needed, just a fix and it'll go in easily". There might be room for that somehow.

[minux]

On Fri, Jan 6, 2017 at 3:32 PM, Brad Fitzpatrick ***@***.***> wrote: It sounds like you want a way to search for "not controversial, no design decisions needed, just a fix and it'll go in easily

But in that case, it's probably more work to label an issue as such than to actually fix immediately. And sometimes, you don't know the complexity of the issue until you started working on it.

[msiebuhr]

getting stuck between two reviewers having quite different opinions about where to go didn't help.

Not all patches go in immediately with zero feedback. Sorry?

Touch low-level stuff that affects everybody and a prolonged discussion is not uncommon.
I don't like having discussions on closed issues. [...]

I wasn't looking to re-open any discussions. I merely tried to account for my experiences. Picking an easy bug isn't easy when you're not into the details :/ Would've loved some label to help figure that out...

[...] If you're proposing a meaning for what these labels are about, please add your comments to #18413. It sounds like you want a way to search for "not controversial, no design decisions needed, just a fix and it'll go in easily". There might be room for that somehow.

That does indeed sound like what I was looking for. Thanks!