My First Open Source Contribution

I am student in the Front-End program at Turing School of Software and Design, in the 4th (and final!!!) module. For one of our mod 4 projects, we were split into groups and given an open source project to try to contribute to, with a week to try to do it. Our group worked on the WikiEduDashboard, a web application that supports many of Wikipedia’s education and editing projects. This post is about a couple of my takeaways throughout this project.

SIZE AND SCOPE:

The first and most obvious challenge was the sheer size and scope of the codebase. Most of the projects we have done so far at Turing are relatively small, one or two person, projects that we work on for a week or two at most. It is hard to built up too big of a code base in that little time. WikiEdu Dashboard, however, was a whole different animal. The Dashboard was first started back in 2014, has millions of lines of code in multiple languages across hundreds of files, written by 77 different contributors. Just looking through the file tree at first was a bit overwhelming, with most of it looking so unfamiliar at first…

After a few nervous laughs about it with my teammates, we took a deep collective breath, and started to focus on the similarities that we could find, rather than the differences. There was a test and a spec directory, with many test suites looking very similar to ones we have written in the past. A large portion of the front-end was built using React, which we are very comfortable with. The Back-End, despite being written in Ruby, looked pretty similar to the Node Express backends we have built throughout this mod. These familiar elements helped us to see the bigger picture of the app and understand functionality a little more clearly, and we were ready to get set up and dive in to the issues to find one that we could tackle.

COPY/PASTING IS FOR MONSTERS:

Once we decided on a component to test, I setup the ‘describe’ and ‘it’ blocks for what we would need and then found a similar component and *grimace* copy and pasted the imports to make sure we had all the right dependencies (or out of laziness, more likely…).

At this point, I hooked my computer up to the TV so that I could drive, with my partners navigating. The component that we were testing was a fairly basic React component for user uploads, which essentially rendered another child component if a user has uploads, and some basic html if the user has no uploads. As far as testing goes, we were pretty confident that these would be simple tests to write, well within our skillset. Somehow it seems like anytime you think that in coding, you end up jinxing yourself and spending hours longer than anticipated struggling through something…

We shallow mounted the component and passed it mock props for what we *thought* the component needed, and tried every trick we could think of to get the output we expected. No matter what we tried, we kept getting the same output that made no sense, and had to pass in an extra prop that the component we were testing didn’t actually use in order to avoid a throw error every time we ran the test. After struggling with this for far longer we should’ve, we were starting to get down on ourselves and decided to call in another classmate for help. He told us to scroll to the top of the page so he could check our imports and read through what we were testing to gain some context to try to help. I scrolled up to the top of the test file to where all of our imports were and saw the issue almost instantly...

When I had *grimace* copy and pasted the imports from the other test file, I had updated the variable name in the declaration to the new component name, however I somehow failed to update the file path of where we were importing from. So we were essentially testing an entirely different component than we thought, which is why we couldn’t get the output to change with the mock props we were passing down to the shallow wrapper, and why it needed the extra prop just to render. Needless to say my group was pissed. Oops, sorry!!!!

There are so many reasons why copy/pasting is a bad idea, this was yet another painful reinforcement of that lesson.

WE DID THE THING!!

At the end of the day, we got the component tests written with 100% coverage and all passing (I still get irrationally excited every time I see the green check when a test is passing, and coverage showing 100%. I think neon green has become my favorite color). My teammates, the rockstars that they are, went on to write a bunch more tests for the reducers as well.

We had a minor hiccup with the pull request, as we had accidentally modified one of the schema files for the database (due to using ‘git add .’ for one of our commits, which apparently can be almost as dangerous as copy/pasting). We managed to get that figured out and were able to fix it pretty quickly….. and the PR was merged!!!!! We are now 50th on the list of highest contributors to this project, thanks to a few simple tests! Hopefully we get a chance to go back and write some more tests in the future, and climb up that leaderboard..

Even though our contribution ultimately was very small (minuscule compared to the entire codebase as a whole), it was still a great feeling knowing that we contributed to such a huge project. All in all I learned a lot from this experience, and am motivated to continue learning more and branching out into other languages so that there is less and less that is unfamiliar when I dive into a big codebase such as this one. I would also definitely like to find more open source projects to contribute to going forward.

Related posts:

A while back I needed a summary of which protocols were supported/recommended in different situations by Azure Active Directory while I was researching the “When To Use Which (OAuth2) Grants and…

Every day we heard about someone who made something big, something that made us feel kind of jealous. Maybe because we have 3 years thinking about publishing an application, ebook or a simple post…

Building decentralized systems presents new challenges that are not often seen in traditional software development. In particular, the adage of “move fast and break things” is no longer a viable…