What NOT to do at Hacktoberfest 2022

Hacktoberfest is such a great tradition. It gets people into open source, it helps open source maintainers fix some outstanding issues, and it is a great way to give back to the community we all benefit from.

If you’re not familiar with Hacktoberfest, it’s a Digital Ocean-sponsored contest to create four accepted pull requests to participating open-source codebases. The first 40,000 (!) who complete this get a free t-shirt in the mail and bragging rights for a year.

But while there are some great upsides to this yearly tradition, Hacktoberfest hasn’t been exclusively positive. Every year, open source maintainers spend as much time closing bogus pull requests as they would have gained from the pull requests they accept and merge.

Now, if you’re new to Hacktoberfest, there are some mistakes you might make that you really shouldn’t. This article will give tips on what not to do and guide your efforts to being a productive participant.

1. Don’t rewrite existing documentation

We get it; fixing typos and changing the wording of a particular piece of documentation might sound like low-hanging fruit for creating pull requests – but it’s definitely not where the maintainers would love your help.

What maintainers dislike about Hacktoberfest are these tiny pull requests, which don’t add much value. More often than not, docs are the way they are for a reason.

Instead, add examples to existing documentation or a deep dive or experience-based tip to the docs. These both clearly add value and don’t reek of bad intentions.

2. Don’t skip the pull request description

Nothing is more annoying than a pull request without any description. They are hard to review correctly; they seem like the contributor didn’t care enough about getting their patch accepted to write a few paragraphs about what they did and why.

Remember – a lot of popular repositories will get hundreds of pull requests this month, and making them easy to review is the best thing you can do for both parties.

So make sure to provide answers to what, why, and how in your pull requests. Add some pictures of the before/after as well, if you’ve done a UI change.

3. Don’t add dependencies

Some of the biggest infosec events in the world have been triggered by overworked maintainers accepting a pull request that adds a new malicious dependency to their project. As we’ve gotten better at avoiding these kinds of traps, our guard has gone up.

If we see new dependencies added to our open source projects by a first-time contributor, you can be sure I’ll close your pull request and report you before I even look at the rest of the code. Accepting these are high-risk, low reward, and just downright scary to most maintainers, especially during a mass event like Hacktoberfest.

So even if you’ve created the best library out there and want to get people to use it, don’t use Hacktoberfest to promote it with use-my-library-pull requests.

Instead, see if there is a way you can remove superfluous dependencies! NPM is full of stupid dependencies that are downloaded millions of times a week, just because the original author was too lazy to write their own is_even or is_odd function. Removing these dependencies can often be a great way to simplify a codebase and make it safer.

4. Don’t change the formatting

Another entry in the hall of useless-yet-popular Hacktoberfest pull requests are ones that “correct” some aspect of formatting. Switching out all const with let, changing file formatting from tabs to spaces (or the other way around), or switching out single quotes with double quotes are just some of the pull requests I’ve seen. And rejected. Time and time again.

Formatting is a personal choice, and the maintainer(s) are probably very comfortable with how things are currently set up. Even if they don’t use Prettier or elm-format or whatever other tool you love to use. Just let their formatting be.

Instead of looking at how code is formatted, look at how it’s structured. Perhaps there is a particular piece of the code that could be refactored for clarity or simplicity? In those cases, remember to add any missing tests to ensure you don’t break stuff.

5. Don’t be a jerk

Sometimes, you might have done everything right. You accepted the CLA, adhered to the guidelines, and even fixed an outstanding issue. Yet – after all of that – your pull request might not be accepted. And that’s okay.

What isn’t okay is throwing a tantrum or hissy-fit. It’s never fun to get rejected, but responding with rude comments or even harassment, is never the answer.

Maintainers often have their reasons for declining a pull request. They might not always be the best communicators as to why, but that code is their responsibility, and the decision as to whether they will accept your contribution is solely in their hands.

Instead, try to understand their reasoning and either change your suggested solution or move on with your life.

Summary

With these tips in mind, you should be more than able to add a significant contribution to the open source community this month. And thanks for taking part of what is a great little tradition. Happy bug squashing!

If you have any more “don’ts”, make sure to leave them in the comments.

A TIP FROM THE EDITOR: Be sure not to miss our It’s Hacktoberfest And We’re Here For It! article, to learn more about Hacktoberfest 2022!

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs and track user frustrations. Get complete visibility into your frontend with OpenReplay, the most advanced open-source session replay tool for developers.

Check our GitHub Repo