Onboarding New Contributors: Good First Issue Label

Published 2022-01-11 on Anjan's Homepage

People sometimes ask me “how do I get into contributing to Free software”. Contributing to Free software can be as difficult as starting a new job - you don’t know where to start, the abbreviations everyone uses are foreign to you, and you’re worried about embarrassing yourself 1. Your motivation might vary but I got into Free software to learn and because it is fun! Here is how I started contributing to Free software and maybe this post can provide Free software maintainers info on how to have a more welcoming project for newcomers:

For New Contributors

  1. Use Free software

    This should be self explanatory but you should start by using as much Free software as you can. Maybe the phone operating system that is easy to develop for and Free software cannot make phone calls. All software starts off with missing crucial features! If the software already worked and had everything you wanted, there would be nothing to add 2. So look at Free software with an open mind and think of creative ways to use Free software that isn’t really working.

    For example, with postmarketOS, alot of phones have wifi working but dont have calls working. As such, you can use an old phone that is just gathering dust in your drawer as a media server. While you use the software, you will find stuff you want to fix, add, and by using the software you will learn how it’s put together.

  2. Join the irc/matrix/xmpp chatroom

    This is where you can get real time help about what your working on. Most Free software projects use irc and it’s kind of hard to get into so I will cover it here: As long as you follow irc etiquette, no one will get upset with you. To use irc, I can recommend chat.sr.ht, simply navigate to that site and login with your sourcehut account 3. You can get a sourcehut account for free if you dont have one.

    The irc chatroom is helpful if you need help with sending your changes, implementing your fix, or getting the code to compile.

  3. Look at the issue tracker and stuff tagged as “good first issues”

    The “good first issue” tag is very important. Often, when I come across a fascinating new project and I want to poke around in the code, I check the issue tracker for “good first issues”. In the project description or comments, there might be a maintainer that explains how this problem should be solved. If you want your code to be merged into the main branch, you should follow these steps. Going into the code and trying to solve these issues encourages me to read the code critically rather than just skimming. Reading other people’s code is a crucial skill and a great way to learn how to become a better programmer 4. Additionally, you get a hit of dopamine when your change gets merged.

    The important thing to recognize here is to just get something mostly working and ask intelligent questions if you’re stuck 1. The goal is to not write perfect code on the first try alone. The goal is to write code that is good enough that others can build off. I have posted alot of patches that didnt work so I added a “WIP” with what doesnt work and a couple weeks later, someone managed to salvage my code into something work 5.

By doing enough good first issues (1-3), you get a good understanding of the codebase and are able to implement that feature you always wanted! In this case, the maintainers and people in the irc channel will be happy to help you since they know you are a determined hacker.

For Maintainers

These are the steps I usually take when finding a new project to contribute to. The main call to action for maintainers here is two-fold:

  1. Make sure your community is welcoming

    The community you have will follow the leadership. Although Free software is the most egalitarian form of computing, a lot of people in the community will still consider the behavior of the maintainer as what is acceptable. So set a good example: warn people who don’t follow the rules, and ensure people who violate your rules repeatedly are banned from your chatroom/issue tracker/etc. New contributors are hard to come by so treat them well!

  2. Document your issue tracker properly

    The goal of the issue tracker is not to have 0 issues. So if an issue is 7 years old, with documentation of workarounds and it’s still a problem, leave it open! Moreover, if you see an issue that would help on board a new contributor, set the “good first issue” label and write a description/comment on how it should be fixed. If you have an issue that is not for a first time contributor but you don’t have time to fix - set a “help wanted” label and write a description/comment on how it should be fixed.

    A good example of an issue tracker that does this well is the pmboostrap issue tracker.

Footnotes:

1

Sometimes you have to risk embarrassment to grow. Additionally, as someone who has sent a lot of embarrassing patches and read other bad patches, I can assure you, no one remembers your embarrassing moments. Moreover, sometimes a bad patch/attempt can spark an idea in someone else so even bad patches are appreciated.

2

And no fame to claim!

3

If you want to use a desktop client, see: quickstart

4

grep, git-bisect (for regressions), and git-blame (for finding who to email and commit history) are your best friends when looking for how to fix an issue

5

Even if you dont think it’s salvagable, it probably is. So send it! Someone can learn what has been tried.

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~anjan/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I follow around the net

These articles/blogs do not represent my own opinions or views.

What if We Replace Guns and Bullets with Bows and Arrows?

The bicycle and the bow are both highly efficient, human-powered technologies that could substitute for two very harmful alternatives: the car and the firearm. Why do we promote one but not the other?

via LOW←TECH MAGAZINE December 2, 2022

I shall toil at a reduced volume

Over the last nine years I have written 300,000 words for this blog on the topics which are important to me. I am not certain that I have much left to say. I can keep revisiting these topics for years, each time adding a couple more years of wisdom and impro…

via Drew DeVault's blog December 1, 2022

GNOME Shell is one step closer to Linux phones

Our first post ever on this website was about the GNOME Project "getting ready" to adapt their environment to the growing demand of responsive, mobile-friendly Linux devices. That was back in 2019, before libhandy (Gtk mobile library) was consider…

via TuxPhones - Linux phones, tablets and portable devices November 15, 2022

Generated by openring