Throughout Hacktoberfest (October) people are encouraged to contribute to open-source to secure a t-shirt along with other swag. I have long been a fan of Hacktoberfest as some of my initial contributions to open-source software occurred during Hacktoberfest. Although, a downside to Hacktoberfest for some project maintainers is that people are encouraged to submit low-quality, spammy pull requests which directly increases the time required for them to maintain their projects without the benefit of being able to incorporate the code that was submitted [As of 10/03/2020 project maintainers must opt-in to participating in Hacktoberfest]. A lot of project maintainers for projects without large corporate funding are unpaid (or underpaid) volunteers.
As I've contributed to larger open-source projects and maintained smaller projects over the years I've learned more about what types of open-source contributions are generally accepted. I recently read through Working in Public by Nadia Eghbal (and shared my notes) which is a great primer if you are interested in learning more about the labor that goes into maintaining open-source software and norms for participating in various types of open-source communities. Below are some of my thoughts on how to make quality contributions to open-source during Hacktoberfest and beyond! I plan on updating this post over time.
1. Finding Issues
If you're newer to contributing and are looking for issues that are designed to be smaller in scope, instead of opening pull requests with unsolicited, 1 character changes, I'd recommend using GitHub's issues filter to search for "Hacktoberfest" or "Good First Issue" or checking out these sites that help people find beginner-level issues that you're interested in contributing to:
- https://goodfirstissue.dev/
- https://www.firsttimersonly.com/
- https://github.com/MunGell/awesome-for-beginners
The benefit of spending the time to find issues that are well-scoped to your interest and experience level is that if you make an attempt at resolving an issue based on the requirements usually maintainers are more willing to work with you to help get your changes accepted into a project.
In addition to using the above resources to find good first issues, I'd also recommend contributing to projects you already use or check out the following projects:
- awesome-uses • share your developer setup, gear, software and configs.
- httriri: HTTRiRi - HTTP Status Codes as Portrayed by Rihanna GIFs ✨💄 • submit your favorite Rihanna GIF that accurately potrays a status code and improve an educational resource for those looking for an HTTP status code reference.
- twilio-labs/open-pixel-art • Contribute to a fun, collaborative pixel art project to teach people how to contribute to open-source.
- selfdefined/web-app: Dictionary database with future API and bot integrations • submit definitions and enhancements to the selfdefined dictionary.
Note: Hacktoberfest has been updated to require maintainers to opt-in to having contributions to their projects count towards Hacktoberfest. If you would like your contributions to count towards the Hacktoberfest requirements, explore the Hacktoberfest topic on GitHub to find projects that have explicitly opted-in to participating.
2. Claiming Issues
Different projects have different norms for indicating that someone is planning on working on an issue. As a starter, I would recommend commenting on any issues that you are interested in working on to reduce the chances of multiple people submitting duplicate changes to resolve the same issues. Generally, unless a maintainer already had someone in mind to work on an issue whoever "claims" an issue first and submits a pull request first will be prioritized and later submissions may be viewed as spammy. Also, note that not all issues are opened by project maintainers and core contributors so it's helpful to read the conversation and tags on an issue to determine if a maintainer is interested in resolving the issues that were raised in the issue.
3. Read the Documentation
I would recommend focusing on contributing to projects that have at least a basic README that outlines how to get started with contributing and what the expectations are for contributors. Another file that some repositories have to help provide more context for contributors is a
CONTRIBUTING.md which indicates what the expectations are for how people should contribute to a project. For example, for my project https://www.httriri.com/
I've shared guidelines for how files should be named and how to make changes that are more likely to be accepted (i.e, not submitting duplicate content, checking open issues before submitting unsolicited changes) in the README file to help make it easier for new contributors to get new status code submissions accepted:
The GIF should include Rihanna and not already be included on https://www.httriri.com/. In rare cases, a GIF that already exists in the HTTRIRI collection can be used for another status code but within the same set of proposed changes, a new GIF should be chosen for the other status code to ensure there are no duplicate images and the overall size of the collection is growing. Excerpt from HTTRIRI Documentation
If there are things specified within a repository regarding naming conventions, testing practices, where files should live, etc. these are usually requirements and not suggestions unless otherwise indicated. Therefore, it's in your best interest to follow those guidelines to hopefully have your changes accepted and to reduce the back and forth required to finalize your pull request.
4. Opening a Pull request
Once you feel like your changes adequately address an issue you should open a pull request in the repository. It's generally a best practice to reference the issue that you are resolving in your pull request and to add a link to your PR on the issue. Some projects will include a checklist or template when opening a new pull request, this generally should be filled out completely unless something is not applicable and gives you another chance to check that your contribution meets the requirements. For example, if a checklist indicates that unit tests should be updated or added for all changes then you should make sure that is done in your pull request and if not indicate why you have decided to forgo a particular requirement.
If you're not quite ready to submit a PR for feedback but need assistance I'd recommend opening a draft PR or sharing a link to your branch on the issue and requesting guidance from other contributors. Depending on the project they may indicate that other forums like Discord should be used to solicit help with contributing. Not all projects have the same capacity to help newer contributors, so you may have to ask for help from others that aren't necessarily directly involved in the project. For example, if you're contributing to a popular, React repository a project maintainer may not be able to answer a lot of follow-up questions but someone in a popular React Discord might be able to help you.
Summary
Overall, to increase the chance of your pull request being accepted I would recommend first identifying an open issue that a maintainer has already given the green light to be worked on, indicating that you are interested in that issue if it's still up for grabs and hasn't been claimed, reading through the project documentation and guidelines to make sure your contribution is aligned with their expectations for contributions and opening a pull request once you've completed the previous steps. I hope these tips help you get closer to successfully contributing to open-source software!
Top comments (1)
Hey Monica! Love this post. Just wanted to share that there is another update to the rules that you might want to include in your intro 😊
"Individual pull requests can also be directly opted-in to Hacktoberfest with the ‘hacktoberfest-accepted’ label, on any public GitHub repository, without the need for the ‘hacktoberfest’ repository topic." - DigitalOcean