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.
While browsing Hacktoberfest repositories, I noticed some maintainers had requested that contributors do not ask them to assign issues. (i.e. "If you want to work on an issue, just do it and then send me a pull request.")
This made me wonder: If an issue isn’t assigned, who receives credit if multiple people make pull requests that fix it? If each of them comes up with a different—yet conflicting—answer to the same problem, does the first contribution that’s submitted get merged, or is it the solution that the maintainer likes the most?
Furthermore, does only the pull request that gets merged count? In other words, is it possible for more than one contributor to receive credit for working on the same issue, or do we as contributors have to race each other to claim dibs?
The answer to all of the above questions is: it depends. To understand why, let's examine the multiple ways maintainers can approve pull requests.
Merging a pull request in a repository with the "hacktoberfest" topic
The "hacktoberfest" topic is the most automated means by which contributions are approved. Assuming both the repository and pull request align with Hacktoberfest's values, a contribution will count as long as (1) the pull request has been merged and (2) the repository has the "hacktoberfest" topic.
Seriously, that's it! As long as these two criteria are fulfilled, no further action is needed by either the maintainer or the contributor. Issues, commits, and the "hacktoberfest" label aren't counted, as we discussed in the previous post.
See Incorporating changes from a pull request on GitHub Docs for more details on merging.
Giving a pull request the "hacktoberfest-accepted" label
The "hacktoberfest-accepted" label is a workaround for maintainers to manually approve one-off pull requests if one or both of the aforementioned conditions are not met. Think of it as a catchall. Note that pull requests must be marked "ready for review" (NOT "draft") in order to qualify for Hacktoberfest credit.
To answer our opening questions, it's completely up to the maintainer if and how they apply the "hacktoberfest-accepted" label. Some maintainers may, in fact, operate on a first-come, first-serve basis. Others, if they have more time on their hands, might be able to award credit to multiple contributors in the event of duplicate pull requests.
What are some other situations where a maintainer might use the "hacktoberfest-accepted" label?
The repository does NOT have the “hacktoberfest” topic
Say you regularly contribute to a repository year-round. Unfortunately, the maintainers don't have the bandwidth to participate in Hacktoberfest.
Given you already have an existing relationship with the maintainers, you might kindly ask if they'd consider applying the "hacktoberfest-accepted" label to your pull request. This way, you can receive credit without the maintainers having to open the floodgates to all Hacktoberfest contributors.
The pull request is NOT merged
Perhaps you submitted a meaningful contribution, but the maintainers determined your pull request wasn't quite ready to merge as-is. Instead of asking you to make the necessary changes, they might simply add the "hacktoberfest-accepted" label to your unmerged pull request in appreciation of your effort.
At the end of the day, maintainers are free to use the "hacktoberfest-accepted" label at their own discretion, and contributors are asked to respect their decisions.
Giving an overall approving review to a pull request in a repository with the "hacktoberfest" topic
Some maintainers have structured their repositories so that any new pull requests must undergo rounds of checks before they can be merged. Think of it like a rubric that's automatically attached to your pull request when you submit it.
For example, say a repository has five maintainers. They may set up their repository so that pull requests require approving reviews from at least two of them before merging is enabled. Or if a specific maintainer's sign-off is required, they can configure the repository so any new pull request reviews are automatically assigned to that person.
By requiring multiple checkpoints, maintainers can ensure their teams are aligned on internal requirements. Having more eyes to catch mistakes also safeguards against errors slipping through the cracks.
An "overall approving review" generally means the pull request has passed the minimum criteria to be merged, even if it has not been merged yet. Look for the checkmarks!
Finally, note that pull requests must NOT be closed in order to count for Hacktoberfest via an overall approving review.
See Reviewing changes in pull requests on GitHub Docs for everything you need to know about reviews.
Conclusion
Circling back to the scenario at the top of the article, we've now learned that it is possible for multiple contributors to receive credit for fixing the same issue, as long as the maintainer applies the "hacktoberfest-accepted" label to each of their pull requests. However, given Hacktoberfest is a busy time of year for maintainers, it's not guaranteed that they will have time to do so.
With this in mind, it's probably still a good idea for you to drop a comment in the issue to say you're working on it, if nothing else but for the benefit of other contributors. Feel empowered to take communication into your own hands, even if the maintainer isn't assigning issues, and others will appreciate your effort to help mitigate confusion.
Over the last two posts, we've summed up what to look for in a repository. Now, let's go over how to look for a repository. 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!
Image courtesy of Naomi Plasterer
This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience
Top comments (4)
I really like how you emphasized the importance of communication in open-source contributions. Dropping a comment on the issue is definitely key, especially when so many contributors are eager to help out at the same time. It’s smart advice for maintaining clarity and respect for other contributors’ efforts.
Looking forward to the next post! I'm curious to see your approach to finding suitable repositories to contribute to. Thanks for sharing these tips!
in/rodrigo-santiago-pimentel-155-ab-2332
Hi @snowman524! I completely agree about the importance of communication, not just in open-source, but in any text-based community.
When you walk into a room, you can pick up on so much about the social norms just by observing people's body language. Is this a relaxed meetup or a more formal networking event? Should we hand wash our mugs in the sink or place them in the dishwasher when we're done?
In open-source, every repository's like a different room. It's still just as important for participants to observe social norms. Except instead of body language, it's the tone and frequency of comments. And vice versa: because no one can see your body language, it's crucial to overcommunicate.
Written communication is such an entirely different beast. I think that's what motivated me to set aside space in this series to touch upon on soft skills.
Thank you so much for stopping by, and happy reading!
Thanks for breaking down the different ways pull requests can be approved during Hacktoberfest! Out of curiosity, would you recommend always checking with a maintainer before submitting a pull request, or is it better to just start working and submit it later?
Hi @jance_jacobs, thank you so much for reading. I'm glad you found it helpful!
Every project is different, so I'd begin by reviewing the README or CONTRIBUTING files for that specific repository's etiquette guidelines.
I've also found it helpful to skim some open and closed issues and pull requests. Oftentimes, I find the answers to my questions by reading conversations that previous contributors have had with the maintainers. It's also helpful to see what kinds of pull requests the maintainers have approved in the past and why. (For example, is the maintainer ok with you making your own issues, or do they only want you working on issues they've created?)
Hacktoberfest has concluded for this year, but I hope you're inspired to continue contributing to open-source during the off-season!