- Communicate your intent to participate in a project before doing any actual work. Use the issue tracker unless directed otherwise in the README file.
- Check if someone else is already working on the issue by looking at the Assignees and Linked pull requests sections.
- For new issues or features, create a new issue and seek maintainer approval.
- Fork the repository and clone it to your local machine.
- (Optional) Create a new branch for your changes.
- Make changes, commit them with clear messages, and push them to your fork.
- Open a pull request, filling in all required details and linking to related issues.
- Ensure your PR passes all automated status checks.
- Use comments for guidance or help if checks fail.
- Be open to feedback and make necessary changes based on reviews.
- Maintain respectful and public communication throughout the process.
- Be patient as maintainers might have other commitments.
- Avoid contacting maintainers privately; keep discussions public to benefit the community.
- Following these steps ensures your contributions align with the project's needs and increases the likelihood of your PR being accepted.
Handy checklist to use when interacting with a project for the first time:
- Does it have a license?
- Are issues and pull request discussions used actively by maintainers and contributors?
- Does the project use labels like help wanted or good first issue for newcomers?
- Does the project have a code of conduct?
- Does the project have clear Contributing Guidelines?
Finally, remember that all contributions are welcome, and the open-source ecosystem greatly benefits from your ideas and participation. There are many ways to contribute to open source, from submitting code or engaging in project discussions to sponsoring projects through GitHub Sponsors.
-
Commit Message Subject Line:
- Complete the sentence: "If applied, this commit will ."
- Use imperative, present tense.
- Limit to 50 characters, start with a capital letter, and don't end with a period.
- Emojis and @mentions can be used, but consider the audience.
-
Body of Message and Pull Request:
- Use present tense and explain the motivation for the change.
- Contrast the change with previous behavior.
- Focus on what and why, not how.
- Submit small, isolated sets of changes for better merge chances.
-
Add Granularity:
- Before submitting a pull request, complete it with relevant details.
- Assign reviewers or assignees based on project structure.
- Use labels for clarity (e.g., Bug, Documentation, Enhancement).
- Link issues for easy tracking and closure.
- Customize notification subscriptions for better management.
You've added context to an issue, contributed a code review, and maybe even submitted a pull request of your own. Now, you want to immerse yourself further in the community around the project.
- Find frequent contributors in the comment section for issues and pull requests.
- Select Insights in the repository's navigation, then select Contributors to find other active community members.
- Follow organizations and enterprises on GitHub to stay in touch.
- Find like-minded folks by attending meetups or conferences on open-source topics.
- Find archives with talk recordings for past events, podcasts, newsletters, and mailing lists.
- Some projects have centralized communication, often referenced on the project's website or in the README file.
- There might be a Discord server, a Slack community, Gitter, IRC, or even regular "office hours."
- Publish as a stand-alone library (dependency).
- Mirror the project with your added functionality.
- Create a GitHub Action for others to include in their workflow.
GitHub Actions are packaged scripts that automate tasks in a software-development workflow in GitHub. The two different types of actions are container actions and JavaScript actions. You can submit your action to the GitHub Marketplace for discoverability. GitHub Marketplace connects you to developers who want to extend and improve their GitHub workflows. Use this platform to publish actions and share apps with other users for free.
For all three of the suggested paths, consider that you're now a maintainer of a project. People will come to you with praise, questions, and complaints. Are you ready for such a commitment?
If your project takes off, people's apps might depend on your bit of code. Can you involve more people to take some of the potential load off? Do you have time to add documentation, triage issues, and review suggestions from people you've likely never met before? Consider your "bandwidth," and instead set expectations in your project's README file. Or, you can release your code in a public gist or a blog post. Code doesn't need to be on GitHub to be open source, after all.