Skip to content

Instantly share code, notes, and snippets.

@NicholasJacques
Created August 2, 2017 16:19
Show Gist options
  • Save NicholasJacques/2a19e65b215a4848230da027cfe9becd to your computer and use it in GitHub Desktop.
Save NicholasJacques/2a19e65b215a4848230da027cfe9becd to your computer and use it in GitHub Desktop.
My First Open Source Contribution.

My first contribution to open source

It been seven (short/long) months since I decided to dive head first into the world of software development by attending Turing School of Software & Design. In that time there have been a lot of milestones: My first "Hello World", my first sorting algorithm, the first time I did "rails new", deploying my first app to Heroku and so on. In a period punctuated by frequent milestones, none have felt quite as momentus as making my first open source contribution.

As a new developer, making an open source contribution feels like an especially big deal. Having code that I wrote merged into a professional quality open source project was an incredible validation of my skills.

The project that I decided to contribute too is called AgileVentures. AgileVentures is a non-profit organization based in the UK that provides opportunities for developers to contribute to open source projects. People are also able to submit their projects to AgileVentures in order to gain a wider base of contributors. AgileVentures provides infrustructure and guidance for contributing developers in order to make the experience of contributing to open source feel more social, as well follow best agile development best practices.

The first step to contributing to this project was to clone the repo and get it working locally on my machine. Having worked on mostly small, greenfield projects so far, it was interesting, and a little bit intimidating to work on a project of much larger scale. My initial run of the project's 3(!) different test suites took more than 30 minutes in total! The contribution guide for the project stated that in order to be able to start contributing, I would need the entire test suite to be passing on my local machine. After 20+ minutes of watching green text whiz across my screen like the matrix I felt pretty confident that I was going to have a passing test suite. Of course, nothing in software development can be that easy and as soon as I had that thought I got a big, ugly red error message on my screen. A test had failed.

One failing test out of thousands of assertions isn't so bad, but the branch that I pulled down was supposed to be a completely passing build. I ran that specific test a few times in isolation to see if it was just a fluke and it failed every time. Doubt began to slowly sink in at this point. How was I going to make meaningful contributions to this project if I couldn't even get it set up on my computer?

Luckily enough AgileVentures has an active community on slack that I was able to consult about my failing test. I posted the error code in the appropriate channel and the projects maintainer got back to me almost right way. He pulled down the latest copy of the develop branch and ran the test suite as well. Sure enough, he received the same error that I did. It wasn't my fault afterall. We spent some time working together to find the source of the problem. After some digging we determined that a feature had been merged that wasing missing some request caches in its testing suite. This was causing the test to fail as the response that it was recieving had changed and no longer matched the test's expectations.

After sorting out this issue I was able to get started on my feature. I picked a pretty simple looking issue to get my feet wet and asked the project's maintainer if I could get started on it. The goal of this feature was to change the page that a user of the site is redirected to when they cancel editing an event. The only catch here is that the form is shared between the new event event page and the edit page. This meant that I needed the cancel button to perform two different actions depending on which page the user was viewing.

I solved this problem by adding a conditional to the view that checks if the @event instance variable is a new record. If it is, that means the user is viewing the new event form. In this case, if they click 'cancel', I redirected to them back to the events index. If the @event instance variable is not a new record, that means that the user is viewing the edit event form. In that case, when the user clicks on 'cancel' they are redirected back to that event's show page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment