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 get 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. 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 decision
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.
✒️ 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 (0)