loading...
Cover image for The “good first issue” myth

The “good first issue” myth

dzhavat profile image Dzhavat Ushev Originally published at dzhavat.github.io ・4 min read

More and more people are getting involved with open source. Some would like to contribute code, other improve documentation, third test new features and report bugs, fourth build developer tools, etc. Whatever the intention, being part of an open source project gives a sense of belonging, can be fun, can have a positive impact on ones career and gives a feeling of contributing to something meaningful.

It’s not a surprise, then, that there are many articles, guides, videos, events, etc., on this topic. Initiatives like Hacktoberfest are also great at motivating people to create their first pull request. I’ve participated as well during the last two years.

Also at conferences, people would often ask “How do I get started with open source?” or “How do I get involved with the project?”

The answer quite often is “Look for Issues tagged with the ‘good first issue’ label”.

This answer sounds quite promising. It gives hope that there are in fact Issues tagged with such label and they can pick one of them and slowly make their first contribution.

The reality, however, is quite different. Many of the popular open source projects either don’t use such label(s) or the Issues are so few and so old, that no one wants to take them.

Let’s say I’m a front-end developer wanting to make my first contribution. I’m using one of the popular frameworks these days and I know that the project is on GitHub. I can fork the project and make it work locally. What should I do next? Can I fix something? What would be a good first issue to work on?

I open the Issues tab and start looking through the list. Is there something for me? I remember X mentioning the “good first issue” label. Let’s see.

Angular

There are currently 2,685 open issues. Only one of them is tagged as “good first issue”. It’s also from 2018 so I wonder whether it’s still relevant.

React

There are currently 494 open issues. 4 of them are tagged as “good first issue”. Two of those are from two years ago or older. They also have a “good first issue (taken)” label. Unfortunately, these issues, as the name suggests, are already taken.

Vue

There are currently 324 open issues. 10 of them are tagged as “good first issue”. By looking closely, all of them also have a “has PR” tag, which means that the issue is effectively solved. It’s only a matter of merging the related PR before the issue is closed.

Ember.js

There are currently 262 open issues. Only one of them is tagged as “Good for New Contributors”. It’s also from a year ago. Could it already be fixed?

Svelte

There are currently 419 open issues. 7 of them are tagged as “good first issue”. Most of them are from this year.

Node.js

There are currently 844 open issues. 13 of them are tagged as “good first issue”. Most of them are from this year.

Bootstrap

There are currently 315 open issues. They don’t use the “good first issue” tag.

jQuery

There are currently 65 open issues. They don’t use the “good first issue” tag.

VS Code

There are currently more than 5,000 open issues. 31 of them are tagged as “good first issue”. Most of them are from this year.


So is the “good first issue” a myth?

We know the label exists, we mention it on different occasions but it’s not really used.

Maybe there are issues that are suitable for first time contributors which are not tagged yet? Or people take them so fast that there’s no time for the first time contributor to get involved?

If that is the case, can we restrict the “good first issue” to first time contributors only? Nowadays GitHub shows a nice “Opened this pull request (their first in @repo)” label whenever a first-time contributor makes their first PR in a repo. So if anyone else opens a pull request for an issue labeled as “good first issue” and they are not a first-time contributor, can we politely reject it? Will this make it more likely for new contributors to work on the issue?

Welcoming first-time contributors to a project is important because that gives them the opportunity to join the community, grow as developers, learn new things and meet new people. And who knows, some of them might become regular contributors, maintainers or even core members. It might all start with the simple “good first issue” label. Please use it.


Photo by Danielle MacInnes on Unsplash.

Posted on by:

dzhavat profile

Dzhavat Ushev

@dzhavat

Front-end developer trying to make useful stuff.

Discussion

markdown guide
 

We're making an effort to use good first issue and difficulty tags more effectively in DEV's repo.

github.com/thepracticaldev/dev.to/...

There are definitely some older issues in there, but if you are struggling to find places to contribute DM me and I'll help. :)

 

What if we had a weekly post on DEV where we plucked a bunch of "good first issues" and added a few sentences about why each might be a good first one and who it might be good for?

Having that extra editorial step might be a decent way for people to skim and discover, and also know that the issues are not stale because we're publishing about them today.

 

That sounds fantastic! ❤

I will also encourage the idea of restricting somehow these issues to "first timers" only. It could be by politely rejecting the PRs of people who are not first time contributors (unless the issue is somehow critical). It could also be by saying that an issue can be taken by a first-time contributor within a month of its creation. Afterwards it's open for everyone.

I think that a post like that will have a positive effect. You can give it a try a few times and see if it works :)

 

That great sound Ben, I would for help for sure, I tried helping you guys out a few times, but never found a relevant issue for me. This would make it a lot easier for people like me.

 

I didn't actually realise that Dev.to was open source until your email came through. Now I love it even more 😍

 

Thanks for making the effort to accommodate first-time contributors.

I wrote this post mostly because I remembered how it was when I first started contributing to open source. I would open the Issues page on some repo and look for the good first issue label. Often times the results were either issues that sounded too complicated or there were already related PRs.

We sometimes talk about how we want more people to get involved but don't really provide guidance and/or tasks to get them started.

 

didi.land has only one good first issue, I am trying to build a community from the ground up so everything must involve all levels of experience. But at this stage all the issues are around making the repository "habitable" for others and stabilizing the complexities, so a good first issue actually means, good if you have specialist knowledge on a certain area, I really want that to change and bring in beginners and experts. Thanks for raising this post.

 

Good luck with didi. I hope it will grow to a welcoming community.

It's tricky in the beginning of a project. There are still many moving parts and things are constantly changing. So it might be hard to specify what exactly is a good first issue. But even though there are still some rough edges, the overall complexity is simpler in the beginning. So it's usually a lot easier for a completely new person to get involved with the project. The questions during that stage are more like Why should I get involved? What's so valuable about the project/community?

It's definitely hard for maintainers to find a balance between development and attracting of new contributors. I don't have much experience with it personally but I hope you'll find a solution :)

 

The link to your blog at the top is broken ;)

 

Thanks for letting me know. It's fixed now :)

 

It can be kinda wacky - because a good first issueis often something that can be fixed with the same amount of time as deciding it's a good first issue and placing the tag. Then, when you fix it - (it's your first issue) - so, often - you'll get a message like: "Thanks: make a better pull request and x and y - and we'll look at it." "OK great, so - just change this other things and make another pull request and I think we might be able to merge this." There might be a lot of back and forth between 5 people. It's hard - even when you are actually a nice person, to sound human. (so many messages and stuff!)

Open source is great! and encouraging people to get started is great. Maybe there are some other ways to facilitate this. Would a short video chat with 10 little fixes once a month and a little background on what to do, and why to do it clarify things better than a tag.

We don't have the answer - but we do have the question: is there a better way? What is the goal? What are the steps to that goal?