Daniel Immke

This year I participated in Hacktoberfest for the first time. I became aware of it last year and really wanted to participate, but I had just started a new job, was moving and buying a new car all in one month! Hacktoberfest was definitely not on the priority list. I was excited to give it a go in 2019.

The basic concept is that you submit 4 pull requests to open source projects during the month of October, and they give you a free t-shirt.

Easy right? Well, it can be. Hacktoberfest doesn’t evaluate the pull requests based on merit/effort so as long as the maintainer of the repository doesn’t mark it invalid it counts towards the 4. This means a pull request to correct a typo can count as much as a pull request that is a major refactor of a codebase.

Since I did this challenge more because I wanted to learn than because I really wanted a free t-shirt (though that was definitely a motivator!) I decided to embrace the spirit of Hacktoberfest and try to submit pull requests that addressed existing issues in projects but weren’t huge commitments.

This is where I ran into my biggest issue — finding good issues is really hard! Or rather, issues that I wanted to work on. I wanted to work with projects that were used by a lot of people, presented some challenge and were somewhat within my domain of expertise. Every time I would find a Github issue that looked perfect, somebody had called dibs. I eventually expanded out from using the #hacktoberfest tag and just looked at medium sized projects with issues.

So, without further ado… these are my Hacktoberfest pull requests!

1. Fixes issue where next button doesn’t automatically focus — #553

React Joyride is a React component that lets you create a guided tour through a page. A little window pops up next to a feature you want to highlight and when you click “Next” on a button it takes you to the next step in the tour. As reported by this issue, even though in the code it tries to focus on the “Next” button of in the next step, this wasn’t working.

I was able to get a simple fix working in 20 minutes. The project had some really good instructions on onboarding with it. It didn’t feel like a super clean fix, but I decided to submit it as a PR anyways.

After submitting, the person who originally submitted the issue reviewed the code. He pointed out that my fix didn’t guarantee that the element was ready for the focus call, and suggested I use requestAnimationFrame, which is a DOM API that was added to browsers somewhat recently to help with this sort of thing.

I had heard of requestAnimationFrame but never actually used it before. The documentation was straightforward and I was able to implement it fairly quickly. It was cool learning a little bit about something I’ve never used before.

As of this writing, I am still waiting for the maintainer of the repository to review the PR and come back to me with any changes or merge it in.

2. Add pass event — #492

Boardgame.io describes itself as an “Open Source Game Engine for Turn-Based Games.” It manages the state and though it is deeply integrated with React, can be utilized with any frontend. Under the hood, it functions as a layer on top of Redux and lets you declare all of the basic logic you need for your game in a simple object.

This is a really big project, and I was a little intimidated to work on it because it seemed very involved, however I noticed the creator and maintainer goes out of his way to be very welcoming to new contributors so I decided to give it a shot. I noticed he had posted an issue requesting the addition of a “pass” event so I gave it a shot.

This was definitely the most time consuming PR on this list. It took me 4-5 hours to really wrap my mind around how the framework functions and probably an additional 4-5 hours to write something I was happy with. A lot of new features had been added to the project that weren’t well reflected in the examples in the repo and I had to make sure the feature I was adding accounted for these more advanced concepts (like phases.)

It also wasn’t just about creating something that “works” it was about matching the current style of the codebase and trying to work within that paradigm.

At one point, I had to ask for clarification and he was very responsive. When I submitted, he had some minor style changes he wanted but I was actually surprised at how little additional feedback there was. At the time of this writing, he wanted me to write some unit tests for the new functionality which I plan to do so very soon and hopefully get the code merged in!

3. Update packages — #2

This one felt a little like cheating, because it’s for one of my own repositories. A couple years ago I created a Pardot Starter Kit. I don’t make Pardot landing pages anymore in my day job, so I haven’t had much incentive to keep it updated.

However at the beginning of this year somebody did open an issue saying they were having trouble using the starter kit because the packages were out of date. Even though there isn’t a lot of activity on Github, I think people do use this starter kit. My analytics show that it’s actually one of the more popular posts on my blog. It definitely needed a little love.

Originally I tagged it as #hacktoberfest and wanted someone else to pick it up, but after a few days I decided to do it myself. I updated all of the packages. Gulp’s version 4 was a major breaking change. Their API surface changed significantly, so I had to refactor the Gulpfile.

This took some time. I also went through and updated the README to explain things better and made some other changes to keep things chugging along smoothly. For people finding it in 2019, it should still be a good option to get started building custom Pardot landing pages.

4. Change JS filenames to bring them in line with the Google JavaScript … — #116

I saved the hardest, most substantial pull request for the very last. This one will definitely knock your socks off.

Just kidding, this was definitely the quickest PR. I traveled through a good chunk of mid October and my day job had started to get busy and I am gearing up to do some more work on other personal projects. I didn’t have the bandwidth to spend a lot of free time working on a bigger issue so I decided to go with a simple one I found through the Hacktoberfest’s website!

Even though it was a basic task, it still addressed a real issue in a project and I still learned something new! It turns out that the git diff command has a flag titled --name-only, which lets you see just filenames that were changed.

Was it worth it?

Before I started this I had open sourced my own work, but hadn’t contributed much to other open source projects. I got to see how popular open source projects are run and how issues are triaged. Each project does things slightly differently and has processes that work for them. I learned a lot about things I want to do in my own open source projects (definitely adding unit tests!)

Participating was absolutely worth it. I expect to contribute more frequently to open source projects going forward and will probably be participating in Hacktoberfest 2020.