"good first issue" vs "beginner"


I noticed this comment on the beginner label in github. I use this beginner label and the “good-first-issue” label and I consider them subtly different.

In clang-format, I’m using this beginner label to differentiate that contributors should know something about the project and its structure and the way it works. This type of issue I reserve for “may not be trivial” and I’d expect it to be likely used for people first 2-5 commits, I’d expect the reviewers to have an inkling of how to do it but it’s not cut and dry.

But for “good-first-issue” I’m expecting them to be 100% new, so I’m expecting the issue to be likely 100% trivial, and frankly something one of the more experienced contributors would likely already know what the likely solution would be.

When you have a 500+ bug backlog, It can help to triage issues into buckets by labelling them based on possible complexity. New users often come with an issue in mind, sometimes it good to have an assessment of how hard it’s going to be, rather than just saying “Knock yourself out!”,

if they tackle something extremely complex first they could lose their enthusiasm and we could end up losing that person as a future contributor, I’m all for small incremental wins and so would like new contributors to do issues which they can make an impact and feel good about it.

We don’t have enough “complexity” buckets as labels

would people have objections to me perhaps adding some more labels, (maybe we should align on common wordage)

beginner issue - as above, should be ok… but may be non trivial
intermediate issue - this is going to take some time and likely rounds of reviews
complex-issue - ok expect this to take 6 months of your life!
almost-impossible-issue - This is an bug/enhancement, but it might be almost impossible (maybe don’t attempt it!)



These are really the inverse of my intuition based on the names: “beginner” is where you start, and “good first issue” would be something to sink your teeth into once you have started to learn your way around. That interpretation seems more consistent with what the “beginner” Discourse category is for, and maybe renaming “good first issue” to “advanced beginner” would make for a clearer distinction between the two. Certainly whenever I tagged Bugzilla reports as “beginner” I wasn’t looking at them as “good second issue.”

I can’t help commenting on one other remark:

This morning project-wide we have almost 17,500 open issues…

… but I don’t think there’s a whole lot of triaging going on. It takes someone with experience in an area to make a complexity assessment without really diving in, and based on a straw poll at an LLVM dev meeting a few years ago, not a lot of people subscribe to llvm-bugs and look for new issues to triage. It’s great that you’re doing this for clang-format, and if we could get more different area experts to look at new issues with an eye to this kind of classification that would be VERY helpful, but I don’t have any ideas for how to encourage that.

1 Like

500 backlog alas is JUST clang-format issue (sorry about that!), myself and @mkurdej at least have been trying to chip away, closing already fixed issues and closing out duplicates (we can only do a few a day at most), This is something that feels a little easier to do in github issues (for which I’m thankful for the transition). But also we are classifying bug/enhancements so we can target items but its also a good time to identify items for people to select at issues to begin their journey.

As for the “good first issue” naming, I think that a default github thing I think, I believe it is one of the labels that is created by default.

1 Like

500 backlog alas is JUST clang-format issue (sorry about that!),

Oh, that makes sense. I should have tried searching on just clang-format to see if that was what you meant.

As for the “good first issue” naming, I think that a default github thing I think, I believe it is one of the labels that is created by default.

Yeah, and “beginner” propagated from Bugzilla. So we have two labels that mean pretty much the same thing.

I still think we should not have both, because they feel too similar and are clearly subject to confusion (both mine, and whoever made the comment that prompted you to start this topic). Something that’s unambiguously “start here” and something else that’s obviously “a bit more involved” to keep the confusion down and allow using them project-wide without having to engage in a lot of explanation. But as they say, naming is hard.

some possible label pairs, just to start things off:

  • beginner / advanced beginner
  • beginner / good second issue
  • good first issue / good second issue
  • starter / entree


This same discussion has started here: ⚙ D117832 Update the Bug Life Cycle docs for the switch to GitHub issues

Thanks! I’ve put a comment there.

Here are few bits of history: “good new issue” is a standard GitHub label. It was already in the repo and apparently it does present in many github docs as an example of label for newcomers. “beginner” is a label that was converted during bugzilla migration from :“beginner” keyword.

We tried to delete / rename “good new issue” label, but objections were raised as this is something documented in many GitHub docs and new users are expecting to find / use it.

Actually, I wanted to keep “good first issue”, I was just asking if people mind if we add some other labels to we can identify more complex issues