Have Fear and Contribute Anyway

Cover Photo by Tonik on Unsplash

Background

I am a mom of 4. When I was pregnant with my second child, I had a lot of fears about labor. I had these fears despite already having labored once with my first child. These fears consumed me until I read an article titled "Feel the Fear and Birth Anyway" by Dr Rachel Reed.

I know, I know. You are probably thinking, "Whoa this is a developer blog platform, why are you talking about birth!?"

I am talking about this because we all experience fear. I bring up the article "Feel the Fear and Birth Anyway" because it didn't only help me with my fear of giving birth – it helped me understand that fear is not only ok, it’s something we all must feel at some point. The article also made me realize that I didn't have to talk myself out of fear to accomplish something.

When I later started learning to code, I went into the field with the same mindset. I was starting something completely new, so it was natural for me to be afraid! I could be afraid and still be a software developer.

Contributing to open source is something a lot of developers fear. They fear it because they don't understand how to do it, they are worried about someone critiquing their code, or for many other reasons.

I am writing this article to tell you it is ok to have these fears but you can still contribute anyway.

How to get started?

One reason software developers fear open source is because of the unknown. If we don't know how to do something, we are much less likely to try it. In my opinion, the remedy for this is external support and guidance, so I’m going to give you some tips here on how you can get started contributing to open source.

Contributing Guides

My first tip is to find a project that has a good contributing guide.

This file will usually be labeled as CONTRIBUTING.md and can be found in most open-source repositories that are looking for community help. Again, having this file is typically a good indication that a project will be helpful and encourage your contributions.

Take the time to read through a project's contributing guide before you try to contribute. This will save you and the project's maintainers a lot of time.

Issues

Tip number two is to get acquainted with a project's open issues.
If a project is on GitHub you will see the open issues in the Issues tab. You can also use filters to search for specific issues.

Some of the questions you will want to consider include:

• Does this project label their open issues? Labels are useful to help contributors know if the issue is a bug, a good first issue, what tech might be needed, for the Core team only to work on, etc.
• Are there conversations happening on the open issues?
• How many open issues does the project have and how responsive are the maintainers to contributors' questions?

These last two points are important to check so you know if you can ask questions before creating a PR.

Communication

This is probably one of the most important parts of contributing to an open-source project. Good communication between a contributor and maintainers can make your experience so much better.

Contributors should ask questions often, before they start working on an issue and while working on their PR.

To get help quicker from maintainers, be sure to ask thoughtful questions.

Your questions should provide a lot of detail about where you are stuck or what you think you should do to fix an issue.

Keep in mind that many maintainers volunteer on projects and may be in vastly different time zones than you. Asking short, indirect questions, will lead to you getting a response much slower from a maintainer.

Creating a PR

Once you have discussed the open issue with the maintainers you can start working on a pull request (“PR”).

You will want to see again if the project has guidelines for how they would like you to create a PR.

In general, most projects will have you fork (make a copy of) the project to work from.

Every project is a little different when it comes to their expectations for branch usage, naming conventions, filling out PR templates, etc. If the project does not have guidelines on creating a PR, be sure to communicate with the maintainers beforehand.

If you have never created a PR before I suggest you go through GitHub's Learning Lab called "Introduction to Github". This lab will walk you through:

• Creating a pull request
• Branches and commits
• Introducing changes with pull requests

… and more.

Draft PR

Draft PRs can be used when:

• You need more guidance
• You would like more discussion on your PR
• You don't want to have your PR reviewed right away

On both draft PRs and regular PRs, you can discuss any potential changes with maintainers.

However, draft PRs can't be merged and maintainers will not be automatically requested to review your PR.

Feedback

Once your PR is in and the maintainers start to review it, you will likely receive some feedback before your PR can be merged.

You may see a "change request" or a "commit suggestion" added to your PR. Take the time to review the changes that were requested and ask any questions before making changes.

Once your PR is reviewed, it can be merged into the project's main branch.
Every team is different and you may need to wait for a maintainer to merge your PR. If you are unsure ask thoughtful questions!

Etiquette

When you are contributing to a project remember real people are maintaining it.
Respect their time. Be patient if someone is not responding as quickly as you would like.

It is okay to be frustrated or confused, but do take the time to gather your thoughts, keep your cool, and most important of all be kind when communicating.

You can read more about etiquette for contributors in the post Hacktoberfest Etiquette for Contributors.

Now go forth, embrace the fear, but contribute to open source anyway!