Making your first Open Source contribution

Ana Enríquez — Mon, 19 Oct 2020 13:14:13 +0000

What is Open Source Software?

According to opensource.com Open source software is software with source code that anyone can inspect, modify, and enhance.

"Source code" is the part of the software that most computer users don't ever see; it's the code computer programmers can manipulate to change how a piece of software—a "program" or "application"—works. Programmers who have access to a computer program's source code can improve that program by adding features to it or fixing parts that don't always work correctly.

Why should I contribute to Open Source?

There are hundreds of reasons to contribute to Open Source projects. Here are a few of them:

Show yourself that contribute is not as intimidating as it seemed
Win a battle to the impostor's syndrome
Return to the Community and/or the project by helping to its development
Grow as a professional by adopting new code styles and working with different teams and architectures.
Get out of the comfort zone

There are more, those were just a few that I always think about :)

Can I contribute to Open Source?

One of the biggest challenges when it comes to contributing to open source is ourselves.

At first, we have the feeling that only senior programmers recognized in their field can contribute to Open Source. And often a mixture of fear and shame keeps us from taking the step of contributing.

But the truth is that Open Source needs the help of all kinds. From syntactic corrections, generating documentation, creating a new feature, there are tons of ways to help and contribute. In this post, I describe step by step the last contribution I made as an example of a first issue to start with.

Looking for a first good issue

Starting something new is always hard. You probably have a lot of doubts and probably you don't know where to start.
Gratefully, Github got you covered.

For every repository, Github offers good-first-issue as a default label. You can filter issues by the label to find simpler contributions. Search by a topic or by a specific project and apply the label filter.

You can also use github.com/<owner>/<repo>/contribute and look for available tasks for a specific project.

There are also some websites that group projects with good first issues.

firsttimersonly.com - A guide with links to help you contribute
codetriage.com
up-for-grabs.net

In this post, we are going to contribute to one of these webs with a simple issue, fix some broken imagen links from the avatar of the Open Source projects firstcontributions.github.io.

Preparing to start

Before you start working on the issue you have chosen it is important to review the repository and check if there are guidelines about how to contribute and any code standards. Usually, this information is in CONTRIBUTING.md.

First step: Fork the project

As you are not (yet) a contributor, and as a good practice, you should fork the project to have a space to work on it. If you fork it into an organization instead of your profile, you would grant access to the issue to the rest of members of the org.
Once you have forked, you can clone it into your computer. For this example:

git clone https://github.com/this-is-you/first-contributions.git

Go to the new directory and then you should add the original repository as an upstream remote (so that you can git pull if new changes happen while you are working on the issue).

git remote add upstream https://github.com/firstcontributions/firstcontributions.github.io.git

Create a new branch

It is important to create a separate branch to work on the issue. Also, remember to add a prefix depending on the type of work you are doing. I normally use bugfix/ feature/ or hotfix/. For this issue, I named my branch bugfix/fix-images-open-source-list

Working on the issue

Normally, the Issues will give you information about the problem and what it needs to be fixed. This information could be more or less specific.

In our example, the Issue is very specific and the reporter told us the file where the changes needed to be made, but if this is not the case, my advice is to first run the project in our local and inspect the code and the behaviour of the project until we found the piece of code to edit or the piece of functionality to modify/create.

Even in this example, I ran the app in my local to find out the logos that were broken and to test if my changes solve the issue.

Committing the changes

Once you think he issue has been resolved you can commit the changes and send them to your fork to the new branch you have created. Remember to fit the contributing guidelines of the repo that you are trying to contribute to.

Creating the pull request

Once you have uploaded your changes to your fork you will be able to create a pull request through the web browser or the console. Trough the web browser you would see something like this when looking at your fork:

If you click on the compare and pull button you can start creating the pull request with the details of your solution.

Make sure that you select the branch to compare and that the changes are being reflected. Look at the arrow to know exactly the process of the pull request.

Waiting for review

You are almost done! Now you need to wait until a reviewer (codeowner) can take a look at your pull request and discuss with you the solution.

If the PR is not accepted

Sometimes the reviewers need more info or context to be able to evaluate all the code changes. Don't be afraid to talk and discuss the solution.

The reviewer/s normally would give feedback about why the pull request is not ready or why they had to close it. Talk to them and continue working to improve the solution.

Congratulations! You have just made your first pull request!!

CI/CD - Not synonymous but related

Ana Enríquez — Fri, 01 May 2020 12:38:16 +0000

At first, when I started my learning path in DevOps, I always thought that Continuous Integration (CI) and Continuous Delivery (CD) were synonymous terms until I made a deep search about it.

As seen in devops.com:

CI is the process of integrating code into a mainline code base. In almost all scenarios today, CI is done using platforms designed specifically for the purpose. Implementing CI is, therefore, as simple as using the right tools.

CD is more complicated. CD is about the processes that have to happen after code is integrated for app changes to be delivered to users. Those processes involving testing, staging and deploying code. There is no single type of tool that does all these things. These processes take different forms, depending on the culture of the team and the type of app it is creating.

So we can asume that CI is the main scenario where we start to build or "orchestrate" our CD. Our roadmap and our clean process of creating de delivery actions.

The process and the platform we establish to start building our delivery. And the CD is all of the phases (or jobs) that we chain to perform the action of push to "master" and make the software available for the users.

DEV Community: Ana Enríquez