Open Source Contribution?… Do It

Anders Wood
Jul 20, 2017 · 4 min read

A tale about open-source contribution as part of a Turing project.

For those short on time, the short story: our Turing project required us to submit a PR to an open-source project, we were scared, the developers were friendly and welcoming, we submitted a PR, and it was merged… we did it!

contribute to open-source code, we did it, high five!

The long story involves 3 junior devs, a unicorn and arson crimes. Actually no unicorns, and it was 4 junior devs until Adam got a job and ventured into the wild to contribute to society.

We embarked to contribute to the crime data explorer repo, a public repo that ‘aims to make national, state, and local crime data more accessible and understandable to the public.’ The app allows users to search by state, crime type and time period and provides visualizations of the data that are published by the FIB and come from ‘over 18,000 city, university and college, county, state, tribal, and federal law enforcement agencies voluntarily report crime data.’

First we cloned the repo and installed it locally. The readme file provided excellent instruction on setting it up, including a command for copy and pasting the .env file: `cp env.sample .env`. The readme even provided a link directly to the api generator site.

We dove in to the large, polished and unfamiliar code-base. To this point we had dealt mostly with our own codebases and those of our peers. We hadn’t dealt with familiarizing ourselves with a giant and unfamiliar code base. We started exploring and clicking on everything. It seemed straightforward. The app has a few routes and displays- not so different from other projects that we’ve done. Then we took a peek under the hood to familiarize ourselves with HOW the app does what it does. This part was eas… no… this had us feeling..

when you take a peek under the hood of unfamiliar and big code

Terrified. We felt terrified. The app had MANY nested directories and used libraries that we’d never heard of . It was difficult to understand where the html code displaying on the app came from within the code because of all the different sections and libraries. A small number of the libraries include D3, Basscss-sass, lowdash, js-yaml and swagger… all new to us.

After exploring the code, we figured we’d pick off some low-hanging fruit and address the easiest issue posted in the repo. We settled on issue #1136: change subhead type style. This seemed like something we could do in our sleep: change the font of the heading from Georgia to Arial. We dove in, found the font variable buried deep in the SASS code and updated it to remove Georgia. We then refreshed the page. Nothing. We refreshed it again, restarted the server and refreshed it again. Nothing. Our confidence drained… we weren’t really coders, we were imposters trying to code. We couldn’t even change the font.

“How bout service workers?” Spencer suggested.. Genius!

Spencer identifying service workers FTW!

We unregistered the service worker, deleted the cache in the “application” section of the dev tools and selected “Bypass for network”. This cleared out the cached information and prevented caches going forward so that changes we made to the code would reflect in the app. That did the trick and the font updated to Arial!

We hopped on to github to submit a PR to the issue to make the update and… someone had self-assigned the issue… it was no longer up for grabs. The confidence bank had been filling, and now.. full withdrawal.

Back to square one… we needed a new issue to resolve.. but as we dug into all the issues and figured out how to address them, one by one they were assigned to a user and resolved without our intervention. The timing on these assignments was frustrating- the issues had been open for over a week and were just now being assigned.

We went back to the readme and reviewed the process for setting up the repo. The readme provides some validation steps one can take to ensure the server is running correctly and the wires are all connected. We noticed that some of validation steps were slightly off- the urls were incorrect for navigating to some of the routes. This was something that needed updating… and we were the three junior devs for the job.

We drew straws and had Spencer reach out to the head collaborator to introduce ourselves and get the green light to submit a PR. Several minutes after a nerdy introduction from Spencer, he responded with an incredibly friendly and encouraging welcome. With our ticket to PR, we whipped up an issue and then submitted a PR to it. With bated breath clicked, submit… literally all three of us clicked submit…

submitting our first open-source contribution- a truly collaborative effort

Twelve minutes after submitting the pr, one of the repo collaborators merged the PR… we had done it.. our updates would forever live in this public code. I got a lovely chill down my spine and just felt kinda…

that really happened… it feels so... good

The moral of the story is : contributing to open-source code is intimidating, but in our experience the community is friendly and you can start small and still make a contribution.

)

Anders Wood

Written by

front-end developer | adventurer | mountain lover

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade