Getting the Most out of Hacktoberfest
Another year, another Hacktoberfest. 2019 was my second completed Hacktoberfest challenge, and while it was a challenging endeavour for me, it was also a rewarding one. It’s a great way to nudge yourself out of your comfort zone and work with codebases, libraries or even entire technologies you wouldn’t have otherwise seen, while contributing to people’s open source projects and getting a free t-shirt to boot (score!). For any future Hacktoberfests, it is my hope here that I can provide some nuggets of wisdom to help people do all of those things.
-
Build on what you know. I’ve always tried to use Hacktoberfest as a learning experience, but I find myself frustrated and discouraged whenever I try looking for opportunities in a repository that I simply can’t grok the code in. Therefore, I tend to stick to repositories that put me just a little bit out of my comfort zone. For a first-time contributor on GitHub, even learning the process of making a pull request can be a step into the unknown, but since I had 2017’s challenge to get used to that, I focused my learning towards new and unfamilliar libraries and technologies, even if only slightly so from what I’m already used to. To name some of my examples for this year, used Selenium and Python, but never Selenium in Python? Why not contribute to a collection of scripts that involve just that? Know how unit testing works, but never written a unit test in JavaScript before? Why not make contributions that have you writing tests in Jest and Mocha/Chai? By choosing what I contribute to in this manner, I expanded my sphere of competence ever so slightly while not having to dive into the deep end of an unfamiliar codebase that I may never touch again. As much as I would’ve liked to contribute to something in Haskell in 2019, my knowledge of the language just wasn’t up to snuff with what most repositories demanded.
-
Better-known projects tend to be more complex. For a time during 2019’s challenge, I was ogling the repository for Microsoft’s PowerShell, since it had an issue marked
Hacktoberfest
that looked like I could realistically work with. However, my changes were missing something that prevented them from working completely, and I wasn’t able to figure out what that je ne sais quoi was (although someone else eventually pieced together a successful pull request). After some time floundering about the codebase trying to figure out the missing piece(s), I decided to cut my losses and move on to something else. As shiny as the allure of contributing to something as big and well-known as PowerShell was, I felt I would’ve needed much more time to get used to the codebase to start making useful contributions than I could give it in a Hacktoberfest challenge. This brings me to my next point: -
Failed attempts aren’t wasted. Sure, you spent a few hours looking at a repository you couldn’t get running on your machine, or figure out how to change for a certain issue, but you still learned something. Even if that learning is entirely intangible and you can’t put your finger on what exactly you learned, you still gained some tacit experience that will help you in doing the same general thing to other repositories in the future. Even if you didn’t make that pull request in the end, you still got better at making pull requests.
-
Make quality contributions. I mean, yes, we’re all here for the (rad, 80s-themed for 2019) t-shirt, but making it any more than a metaphorical carrot-on-a-stick means you’ll make low-effort contributions, and perhaps even worsen the quality of the repositories you contribute to, just to get up to that magic number of four pull requests. This doesn’t necessarily mean that anything as small as fixing a typo isn’t “quality”, but you should still make sure the code works after your changes have been made, write any applicable tests if the repository has a test suite (and if it doesn’t, ask about starting one), and so on. If your changes are large enough, ensure the resulting code is clean as well. After all, the spirit of collaboration should be to put aside your own goals and concerns, even if only for a while, for the benefit of whatever project you’re all working on.
Finally, don’t forget to have fun! If you enjoy coding, but aren’t enjoying your Hacktoberfest, even after some sustained effort, you might be going about it the wrong way. Hacktoberfest is a great tool for getting used to contributing to open source, and if you find a project you liked contributing to, maybe you’ll even decide to stick around after the challenge is done?