Reno, NV    +1 (800)0 621-0871

Go back


First Open Source Contribution (2014 Internship)

  |  May 30, 2014

Our main goal for this internship program is to contribute to an open-source project. With this in mind, we looked for some open-source repositories in GitHub. Nestor also provided us a list of projects we can choose to. After spending some time choosing the right project, we finally decided to work on GitLabWe chose GitLab because we got interested on the contribution of Karlo (We’re hoping this could be a tradition). This choice marks our first step (at least for us) to the open-source community. We then started reading more about the instructions to contribute to this project – the

aelogica summer internship 2014

The instructions are just plain and simple (at least at first sight): 1. Read and follow the instructions 2. Set-up your environment 3. Hack and Contribute

As we finish Step 1, the first interesting task we have to do is to install GitLab’s development environment to our local machine. This part of the internship allowed us to experience the pain of being a DevOps especially when we ran to errors due to following an outdated guide. We did a number of “install -> reinstall -> breathe -> install” steps before successfully setting up Gitlab.

After the setup phase, we quickly transitioned to development and listed all the things we need to learn before contributing to the codebase. To look for ideas for contribution, we also browsed the community feedback site and suggested our idea for a new feature: Language Statistics.

Being Ruby newbies, we first familiarised ourselves to Ruby on Rails that powers GitLab. After building a few small apps on Rails, we delved to the main project hoping that everything will work according to our plan. We learned how to utilize the existing gem gitlab-linguist which almost do all the computations for us. We encountered some problems in using this gem which is caused by their outdated documentation. This gem made our lives easier and we just inserted minimal number of lines, as needed, to complete the feature.

Next we committed and pushed all the changes we’ve made to our own fork of GitLab. We adhered to the project’s style guides and conventions. At this point, we have already filed our very first pull request (PR) to an open-source repository and it feels fulfilling (we know that this is just an attempt until it gets merged, haha).

We then waited for the project owners and core developers to reply to our PR so that we can know if we need to change something. We are very confident that they will merge this PR but unfortunately, this wasn’t the case. Instead, we received some negative feedback from the reviewers regarding the UI/UX and the usefulness of the feature itself. In the end, they rejected our pull request which caused a huge disappointment on our part.

Our failure in our first attempt didn’t stop us to contribute, though. We went to the feedback site again and looked for features tagged as “Accepting Merge Request” or AMR. Here we found an interesting idea which suggests a file attachment feature when creating a post or comment. With this, we decided to extend this feature and make it a drag and drop image upload to all the text-area that has markdown support. This gave us a chance to not lose hope and show our growing skills once more.