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.

Now that we understand what does and does not count toward Hacktoberfest, it's time to start looking for issues to work on.

Unfortunately, it’s harder than you might think to find issues that are (1) inside a participating repository, (2) within your skillset, and (3) not already assigned to someone else.
 

Problem

Conventional wisdom says to browse the Hacktoberfest topic on GitHub. What no one talks about is how user-unfriendly this process is.

With nearly 150,000 participating repositories, the feed is set up as a continuous scroll, and users lack the ability to jump from page to page. Unless you want to spend the next several hours clicking the “Load more…” button, it's nearly impossible to access the wealth of repositories in the center of the pack. While users do have the ability to sort, this still leaves everyone crammed at the top and bottom of the list.

The only option you're left with is to filter repositories by language. However, this alone still might leave you with a bunch of projects that are out of your league. When you're first starting out, you may want the ability to apply additional search criteria, such as the "first-timers-only", "beginner-friendly", and "good-first-issue" labels.

Good news! You can.
 

Solution

The Hacktoberfest website points to several third-party resources, some of which allow you to achieve this filtering to varying degrees. (My personal favorite is Up For Grabs.) Likewise, the project-sharing forum on the Hacktoberfest Discord proves less overwhelming.

With that said, I’ve found the most flexible solution is simply to use the GitHub search bar. This can be effective if you know how to do it properly.
 

Searching for repositories

Say you want to search for repositories that contain CSS, have the "hacktoberfest" topic, and have at least one issue with the "good-first-issue" label. Just type the following into the search bar:

language:css topic:hacktoberfest good-first-issues:>0

Note that the last qualifier only works with the "good-first-issue" and "help-wanted” labels. For example, the following syntax would yield an error message:

first-timers-only:>0
 

Searching for issues

You can also search for issues instead of repositories. Say you want to filter by open issues that have the "hacktoberfest" and "beginner-friendly" labels and are within repositories that contain CSS. Try entering the following into the search bar:

type:issue state:open label:hacktoberfest label:beginner-friendly language:css

If you use this method, just double check that the repository you select also has the "hacktoberfest" topic. Remember, labels and topics are two different things in GitHub. If the issue has the "hacktoberfest" label but the repository does not have the "hacktoberfest" topic, your pull request will not count. (Confusing, I know. See our prior post.)
 

Can't I just filter by issues with XYZ label that are inside repositories with the "hacktoberfest" topic?

As far as I can tell, GitHub is not capable of searching for issues with specific labels that are within repositories with specific topics. In other words, you cannot combine the label and topic qualifiers. This is because the "label" qualifier is not supported when searching repositories, and the "topic" qualifier is not supported when searching issues. Therefore, you can only search by one type at a time (i.e. repositories or issues).

Have you found a workaround to this problem? If so, please let me know in the comments!
 

Conclusion

By mixing and matching the search criteria to suit your needs, you can narrow down the number of results from several thousand to a few dozen. This might seem like a no-brainer if you're familiar with GitHub, but it's a game changer if you're new to the platform.

I’ll leave you with some closing tips:

• Make sure you use quotes around multi-word search terms. For example, to search for issues with the label "up for grabs," type label:"up for grabs", not label:up for grabs.

• Search terms are not case sensitive.

• If you prefer a visual interface, you can also use GitHub's advanced search page. However, I find this option offers less flexibility.

See Search on GitHub on GitHub Docs for everything you need to know on this topic and more.

We're now up to speed on finding repositories to work on. In the next two posts, we'll shift gears and explore a couple of the unexpected things you might encounter while working on those repositories. 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