My dive in to open source!

It wasn’t to long ago when I was working as a geologist in an industry where sharing information was considered a four letter word. I never thought there would be a day when I would work in an environment where freely sharing data was encouraged, at least not until I got in to software development.

Nearly eight months ago I left my career in Oil&Gas to go to school for coding and while it has been a life changing experience, it has also been a somewhat daunting one as well. Throughout the course of the program I’ve executed projects independently, in pairs, and in groups and at no time during those did I feel as intimidated by the task at hand as I was when I was asked to contribute to an open source project. In this project my group and I were given an open source code base and were tasked with resolving at least one issue related to it. We thought this would be a cake walk! The issues given to us were mostly CSS and HTML fixes, simple right? Not simple at all.

First things first, we have to clone the repo down from GitHub and get it running on all of our machines. My three partners and I thought for sure this would be a straight forward process, but to our surprise (or not) it wasn’t. For starters the documentation for our repo was all over the place. There was a link at the top of the README that redirected us to a document with instructions on how to get the project up and running but oddly the document was in the maintainers trash can. I tried following the instructions on that document but they weren’t great and resulted in an application that wouldn’t run on my machine so I asked my group if they were having issues as well and they were, but they were all having different problems. Apparently your machines configuration plays a big part in how other peoples applications run on it. Once we all realized this document wasn’t working out for us we went back to the original README and followed its very basic instructions which ended up proving successful.

Once we all had the application up and running, we decided as a group to split up and independently get our heads around the project so on the first night of the assignment we all went home, pulled down the code base, and began chiseling away at it. After pulling down the repository, my first thought was what framework are they using to build this thing. I had hoped to find something I was comfortable with like React, but it wasn’t long before I was sorely disappointed. This project was built in Angular and the script files were all TypeScript. To my dismay both of these were libraries and frameworks I had no experience with……great. In order to develop a better understanding of what was going on I just had to dive in to the code and find some parallels to the frameworks I am familiar with. This process quickly yielded results. After a short period of fumbling around this huge code base I finally had an understanding of what was going on, a small one at least.

With this new found understanding of AngularJS I decided to look at the issues we were given and see how solvable they were. The first issue wanted us to add padding to an to the left and right edges of an element that was similar to the padding of the element above it. This seemed simple enough but as I dug deeper I found that I was a little confused by their styling. What I found was one, they were using SASS for their CSS, and two, they were using bootstrap as well. Just two more tools I had never used before. This kicked off another research project. Luckily the documentation for both of these tools is pretty great and made solving the problem easy. Now that I was able to read their styling more easily I could make decisions about how to solve this problem.

Next I began looking in to the second issue we had which was simply changing out text in a couple of HTML elements. This was yet another misleading issue. When I went to find the text they wanted changed I realized it didn’t actually exist in any of the Angular components or really anywhere in the project. After much deliberation I realized this text was in their backend somewhere which made this unfeasible to me time wise, so I decided to skip it. With that decision, I decided to go back to the previous issue and try to solve it because it seemed like it would be the one with the highest possibility of being completed and merged in to the repo by the maintainer. The rest of the team agreed as well so this became our focus for the week.

Now that we knew what issue we wanted to fix we had to reach out to the owner of the repo and ask for permission to take the issue. This was simply done through the comments section of the issue on GitHub. Once we initiated contact we began working on the problem. The first thing we did was run the application on a localhost server using “ng serve”, which builds the application and starts a web server. With the page running we were able to view all of the elements using the inspector tool in dev tools and find the HTML element we need to add padding to. Once we found the element we began brainstorming solutions that wouldn’t break everything else. This was an interesting task because as I mentioned before they were using bootstrap as well as SASS. When we found the class name in the inspector that had the styling on it we though, “Ok great! That was easy enough, lets add styling here!”. That is not how it worked out for us. The class name in the inspector was a bootstrap class which gives whatever element it is on styling that isn’t in the SASS files. The class name was “no-padding” which removed any padding from that element automatically. Since the maintainers of the repo wanted this element to be styled similarly to the one above it we found that elements class name in the SASS files (which were luckily NOT bootstrap classes) and it did have a CSS property of padding on it. The class name used to target that property was “container”, so we added a class name of container to the element that needed the padding on the side and removed the class of no-padding and what do you know, it fixed it and didn’t break everything else! After some approval processes we submitted our change in a PR with the repo which was quickly accepted and merged in to the production application.

Ok so what was the point of all of this rambling…hmmm. Well as I said in the beginning, diving in to an open source code base as a new developer was daunting in the beginning. There was a lot going on and new technologies that I had no understanding of, but once I got over the fear of breaking everything and being exposed as a know nothing, it wasn’t that scary and actually it was pretty exciting. My team made the tiniest of changes to this application but it needed to be done to improve the users experience, which is extremely important for an application to succeed. Contributing to open source isn’t as scary as it seems and the community appreciates any help it can get on these projects (within reason, that is). Submitting my first open source contribution was a great experience and I intend on contributing more in the future.