DEV Community

Cover image for Just because it says “hacktoberfest” doesn’t mean it counts toward Hacktoberfest ⚠️
Jeanine Duchaney
Jeanine Duchaney

Posted on • Edited on

Just because it says “hacktoberfest” doesn’t mean it counts toward Hacktoberfest ⚠️

Welcome to 6 Things They Don't Tell You About Hacktoberfest (When You're Learning to Code). In this series, we’re sharing tips for self-taught coders that the official Hacktoberfest resources may not cover.

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.


You know when you're playing a video game with friends and you realize you've spent more time customizing your characters than actually playing the game? That's how it can feel sometimes when you're trying to find a repository to work on for Hacktoberfest.

At first glance, all you should have to do to find a participating repository is look for the "hacktoberfest" topic. Sounds pretty straightforward, right?

In truth, there are a number of reasons why an ineligible repository might appear deceptively promising. Let's break down some common pitfalls.

An issue has the "hacktoberfest" label, but its repository doesn't have the "hacktoberfest" topic

When you're new to Git and GitHub, the jargon can feel pretty indecipherable. Topics? Labels? What's the difference?

The two can be pretty difficult to tell apart given how similar they look. As it turns out, though, labels pertain to individual issues, pull requests, and discussions. Topics, on the other hand, apply to the repository as a whole. (If that wasn't confusing enough, tags mean something else entirely, but that's another story.)

Here's an example of an issue that has the "hacktoberfest" label...

GitHub issue that has the


...within a repository that's missing the "hacktoberfest" topic.

GitHub repository that doesn't have the


This distinction is important, because Hacktoberfest tracks the "hacktoberfest" topic, NOT the "hacktoberfest" label.

In practice, this makes sense. It's less upkeep for maintainers to opt in the entire repository once rather than have to attach labels to every issue. Vice versa, if they subsequently decide to opt out of Hacktoberfest, they won't need to go through each issue removing labels one-by-one.

But if only the topic matters, why is anyone still using the label? You'll likely see maintainers giving issues the "hacktoberfest" label to organize their repositories internally or make their repositories easier for contributors to find. Alternatively, they themselves may be unclear on the rules and/or want to cover their bases.

If the former, they'll likely also have given the repository the "hacktoberfest" topic. Still, it's worth double-checking in case of the latter. While you’re at it, make sure the maintainer hasn’t made any typos.

GitHub search showing that there are 3,000 repositories with the


With all that said, there is one instance where Hacktoberfest tracks labels: the "hacktoberfest-accepted" label. We'll look at this in more detail in the next post.
 

A note about issues

While we’re on the topic, it’s worth noting that you're not necessarily limited to existing issues. Issues are great for organizing what problems are and who's working on them. However, at the end of the day, Hacktoberfest only tracks pull requests, NOT issues or commits.

This means, depending on the repository's etiquette guidelines—typically outlined in the README file and/or other documentation, often titled CONTRIBUTING, HACKING, or similar—you’re sometimes free to create your own issues if you identify meaningful areas for improvement.

In some repositories, creating an issue may be an optional step. On rare occasions, the maintainer might even prefer you skip over the issue altogether and jump right to submitting a pull request. In either case, the pull request does not need to be attached to an issue to count toward Hacktoberfest.

Every repository is unique, so approach each one on a case-by-case basis.
 

The repository is invalid

The Hacktoberfest rules state, "Bad repositories will be excluded." But what does this look like in practice?

When I began looking for repositories, one of the first things I did was Google "hacktoberfest beginner". Wouldn't you know it, the following repository popped up as the first search result:

The first Google search result titled


"What luck!" I thought. "A repository made just for someone like me."

I clicked the link, went through the README, and was ready to create a fork when I noticed one issue.

An issue on the hacktoberfest-beginner repository titled,


It turns out the well-meaning maintainer had inadvertently violated the Hacktoberfest rules regarding quality contributions. While GitHub users could continue utilizing it as a learning resource, any contributions make to this repository ultimately would not count toward their Hacktoberfest quota.

Given the repository had "hacktoberfest" in the title and the README did not indicate that the repository had been excluded, I easily could have submitted a pull request without ever having noticed the issue.

Lesson learned: If you stumble upon a repository that seems too good to be true, click around first to make sure it's legitimate. And, of course, make sure your own contributions align with the Hacktoberfest values. (I'm looking at you, spammers!)
 

The repository is inactive

Next, I tried filtering the "hacktoberfest" topic by language. The fourth search result was a repository that I thought looked approachable.

Not only did it include the "hacktoberfest" topic, it also showed no signs of having been reported. So far, so good.

I proceeded to review the README and CONTRIBUTING files and was all set to fork the repository when, once again, I noticed an issue.

On the issues page of the repository, an issue titled,


In it was a disclaimer stating that issues were no longer being reviewed and pull requests wouldn't be merged. Furthermore, the maintainer specifically mentioned, "If you're looking to contribute here for Hacktoberfest or other similar events, this would not be a good repository to contribute to."

Considering this repository fell near the top of the search results, this message was pretty easy to miss. Sure enough, it looks like not everyone got the memo.

A list of pull requests submitted 2-3 weeks ago


The takeaway? Even if you put in the time and effort to make a meaningful contribution, it won't count unless the maintainer reviews it. Thus, check the repository for signs of recent activity. If there haven't been any commits for months, consider leaving a comment asking if the repository is still being monitored. If no one responds, then you have your answer.

Lastly, if you are a maintainer, please consider removing the "hacktoberfest" topic from your dormant repositories to reduce confusion for contributors. Even if it's not logistically possible to track or enforce, it’d be great to see at least a cultural push within the Hacktoberfest community encouraging maintainers to clean up their repositories’ topics and labels.
 

Conclusion

As you can see, several factors can quickly add up to make finding a repository harder than it looks. The process might even end up taking longer than the coding itself!

Now that we've cleared up some of the nuances that could disqualify your pull request, let's talk about the various ways your pull request can be approved by the maintainer. NEXT POST ▶️


✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

Top comments (0)