Contributing To My First Open Source Project

As Front End Engineering Students at the Turing School of Software and Design, we are constantly asked to do new things, things we have never done, to push our boundaries, learn new things, and grow. During Mod 4 (the last module), one of the projects we focus on revolves around contributing to an open source project. The project my group-mates and I were assigned to was “Code for Social Good”. The first thing on our agenda was to find out what exactly this “Code for Social Good” was all about. So, we did some research, looking around the website to see what we were getting ourselves into.

1. Was it an application? A website? A developer tool? How does it work/what does it do?

Code for Social Good is a website, a non-profit site for volunteers made by volunteers. A few of the main targets are industry workers that want to contribute to a good cause, or college students looking for experience. There are currently 1242 volunteers (601 with a public profile), 73 projects to work on, 52 Organizations currently participating, in 70 countries. I was immediately interested in learning more once I read those statistics. I was impressed by how many countries, volunteers, and organizations are being connected through this website.

I became more curious about how all of this started and what the vision behind it may have been. Digging a little deeper into the website, I found that the vision was to connect nonprofits with great volunteers. As a nonprofit, it can be hard to offer paid work. A limited budget means fewer workers, which in turn means, work that cannot always be done. At Code for Social Good, they understand the struggle of nonprofit companies, and as a nonprofit company themselves, they seek to provide other such organizations with the technical help they need, for no charge whatsoever.

Pretty sweet idea, huh? Now that they had the vision, how did they go about implementing that vision? As a junior software developer, these are things that I constantly question. I feel as though many people have great ideas, but actually going out and doing something about those ideas is a whole other story. One of the reasons I love software engineering is that it gives me a platform to create. In my opinion, the reason this website has taken off the way it has, connecting all these great people, to all these great organizations, its because its extremely intuitive and easy to use. On the landing page, you have the option to click projects, volunteers, or organizations right on the top of the page. And just in case you missed that, you can click on “find projects”, or “find volunteers” right in the middle of the page. The website simply works off of volunteers and organizations. An organization can create an account to be able to post projects on the site. A volunteer can create an account, log in, and browse by project or organization. Volunteers must have a completed profile before applying to work on a specific project.

2. So… What was it like jumping into a new codebase?

As a junior developer, fairly new to the world of codebases, this was a great learning opportunity. Every project I have worked on thus far, has been created from scratch, therefore, I know exactly there everything lives, and if something breaks, I know exactly where I need to go to be able to fix it. Needless to say, I did not write “Code for Social Good” from scratch, and I absolutely did not know where everything was in their codebase. Most applications I have created have either been in vanilla JavaScript, or I’ve added frameworks like React or Redux.

3. What was new and interesting about this code base?

While jumping into the codebase for “Code for Social Good”, there was a slight shock factor as I saw a handful of things I had never seen before. A quick google search later, we determined the application was written in Angular. I thought this was cool, mostly because it didn’t seem too tough to read through and get an idea of what the code was doing. But, the main difference between applications I have been accustomed to working on, and the one we were looking at, was the sheer size of it! The code ended up being pretty difficult to follow and know what was effecting what. In addition, it was clear that there were numerous contributors on this project, because there didn’t seem to be any sort of flow, and it was pretty difficult to follow class names and nested SASS variables.

The first thing that we were instructed to do was clone down the project to our local machines. This process was fairly straightforward, but at the same time, the documentation could have been written more clearly. For example, we didn’t need to clone down and run the back end repository just to edit the frontend.

What issues did you resolve?

Initially, we spotted an issue on GitHub that had to do with responsiveness on their “Top Volunteers” page. We thought this was going to be a quick and easy fix! We pulled up our developer tools, added a display flex in addition to 3 or 4 other lines of code and BOOM! We fixed it, right? Nope! In the process of fixing the one page, we completely destroyed a few of the other pages. This goes back to when I mentioned class names that were hard to follow and nested SASS variables. Unfortunately, we couldn't figure out exactly how to fix that one page, without completely ruining at least one of the other pages. Therefore, we pivoted and found another issue that we may have some better luck with. We ended up fixing some icons that were on top of the page! We created a pull request with our changes, so now we will have to wait and see if its merged in.

Overall, this was a great experience. I learned a lot and was able to throw in a pull request on my first open source project.