An (even more) practical guide to open source contribution

I had the pleasure of speaking at DevOps Minneapolis to a great group of people. In it we explored why I’m fascinated by open source, how it’s growing as a career opportunity, and then dove deep into the terminology that can be confusing at times. I called the talk a “practical guide” because it includes all the lesser-discussed parts of the effort: understanding terminology, feeling okay practicing, offering PRs for small improvements like correcting a typo. It was a great time and many came up to discuss it afterward.

It was so fun talking with my DevOps people in Minneapolis!

What happened next was a 40 minute whiteboard session on what commands to run when you’re trying to push to GitHub. It was exciting, engaging, and the moment I realized that there were some even more practical tips the audience needed to hear. Here is that guide.

Configuring your laptop for SSH access

While I highly recommend new GitHub users enjoy their beautiful desktop applications, most people I talk to enjoy the CLI too much to do so. If you’re going to hang out on the CLI, invest in setting up SSH keys so you don’t have to re-enter your password.

Commit to understanding commits

These wonderful little dots will be the difference between a helpful PR and one that’s confusing to other users. I’m a visual thinker, so it’s been difficult at times to know what’s going on. Then I found the beautiful Learn Git Branching tutorial. It took me about 5 run throughs to make me feel like a native speaker of commit history. Spend 15 minutes every morning for a month and I guarantee you’ll get there too. It’s worth the time!

Issues are a kindness

Reporting a detailed, thoughtful, and well-documented issue for a popular project is a great way to give back without a single line of code. I can tell you that I was nervous doing so for a while, but the trick to feeling confident is this:

  • Review the CONTRIBUTING.md file to ensure they want issues opened.
  • Search through all open *and closed* to ensure it’s not already solved.
  • Make sure you’re running the most recent version of the project.
  • Provide context: what OS, how did you run it, what errors can you see, etc.
  • Be responsive — respond to follow up requests on the issue.
  • Be humble — your kindness is done when the issue is closed, even if its closed without you feeling like its completed.

Here are a few examples of when I’ve followed these practices and had a good time doing so:

^ Here’s where I fumbled on following the issue request, but the team was kind enough to help me through it. Kind maintainers go a long way.

^ Here’s an example of me opening one without updating. Lesson learned!

^ The above is an example where I missed the original thread. They closed my issue and I joined the discussion on the other.

Correcting typos or READMEs as your first PR

Pull requests don’t have to be complicated. I find myself regularly using other people’s projects, and I’m bound to find a typo or two along the way. A short PR is an easy merge for the maintainers and often appreciated. Here are some examples you can see as examples:

For those that took apart microwaves as children

There are those who don’t trust what they don’t understand. I often call them Engineers, and they’re awesome people. If you’re the type that needs to really get git before you’ll use it further, take the time to read Git SCM. It thoughtfully demystifies every piece of magic in the system.

A beautiful image showing how Git sees snapshots, not differences. Read the full article here.

Where to next?

If you have a CLI or GUI experience you feel good about, you’ve opened up an issue without fear, and started to share PRs once you’ve internalized commits, then you’re ready to dive in deeper.

There’s a great deal more advice thanks to all the thoughtful commenters on this thread. Check it out and reach out if I can ever help you on your journey.