In part one of this blog series, I gave you meaningful insights on 1) how to measure the health of an open source project, 2) the importance of understanding project governance and standards, and 3) community as a driving force of an open source project. In this post, I’d like to focus on best practices when making technical contributions and share how I have experienced:
- Effective collaboration with the community
- How to find a good first issue
- Sharing good practices in submitting a change
Effective Collaboration the Open Source Way
Open source software is developed in a decentralized and collaborative way, relying on peer review, consensus, and community production. Here are some ways that make for easy collaboration and help achieve consensus within a community:
Transparency – When interacting with the community, I always use the well established community communication channels (GitHub, Slack, email, etc). I ask questions on public channels and try to avoid holding private conversations. Before working on an issue, I add a comment or assign the issue to myself so others know to put their efforts into other issues. Transparency helps the community work efficiently and organically, thereby synchronizing the efforts of all community members.
Consensus – Achieving consensus is not always easy. I have learned to be patient as it takes time to build trust and integrity with other community members. Sometimes communication can be delayed due to members living in different time zones.
Politeness – It’s important to not take criticism personally. When told that my changes have missed the mark, I analyze the provided feedback to find the rationale and integrate them into my second attempt. There have been times when my proposed solution did prevail — through polite and reasonable defense of my thesis.
Respect – For effective teamwork, each community member must understand “the importance of easy collaboration,” meaning that everyone should do their work in support of the project. For example, committing messages with code should be concise and to the point which makes the review process easier and vice versa. All contributors should respect other contributors’ time and efforts.
How to Start Contributing?
The best way to get into a new project and learn the new technologies is to search for issues labeled as “good first issue,” a common practice in open source appropriate for newcomers. You can also look for project management tools or a task management tool within GitHub, which help the community plan, track, and collaborate while providing a project’s current state, its upcoming goals, and how different tasks are progressing.
Once you are ready with your first issue, it’s time to upstream changes. Here are some good practices I try to follow.
Good Practices When Submitting a Change
- Before submitting a change (creating a Pull Request or PR), I open an issue on the topic and point it out in the PR. Be sure that such an issue does not exist. An issue could be opened not just to report a bug, but to propose a new feature or discuss a high-level idea.
- Always try to justify why a submitted change is necessary. Ensure that the proposed change is aligned with the project’s main goals and provides a benefit to the entire project. Code changes that benefit a small subset of the group are more likely to have fewer consumers, therefore fewer maintainers, and become stale.
- Provide thorough context and alternatives to help the maintainers make the right choice.
- If the proposed change is too large, it’s better to break the change into a series of well-separated Pull Requests. Try not to touch unrelated code. This will simplify the review process.
- Provide an informative commit message, following the community guidelines.
-
- Don’t forget to update/write tests. If the change is user-facing, update the relevant documentation.
- The review process could take time. Respond to all reviewer comments in a timely fashion.
- Always thank and give credit to the people who have been involved in the contribution process.
Begin Building a Reputation
Integrating into an open source project takes time and effort and yields best results when tended to by a diverse and creative community. Keep in mind that everyone starts with a small issue/contribution. And it’s okay to think big — as your knowledge and expertise grow, you could one day define a project’s future direction. Open Source leadership is not a given, rather it is earned through regular, ongoing participation and contribution. So in the meantime, build your reputation and the trust of others. And always keep in mind that open source is about the community — be human first. 😃
Other Beginner Resources
DigitalOcean and their partners have been hosting Hacktoberfest for eight years, a month-long challenge during the month of October. It’s an event that encourages newbies to participate in Open Source and create their first meaningful pull request. Another beginner-friendly event is the Google Summer of Code (GSoC), a global, online program focused on bringing new contributors into open source software development. GSoC Contributors work with an open source organization on a 12+ week programming project under the guidance of mentors.
Lastly, I hope the experiences I’ve shared in this two-part series gives you a solid foundation that will ease your journey!
If you want to learn more about the technical details in creating your first PR and a fork, git commands, and GitHub, read Anna Jung’s blog post 5 Things You Should Know Before Getting Into Open Source. Dawn Foster has a number of informative blogs on the subject including a four part series on Navigating Open Source Risk. Finally, Nisha Kumar shares her insights with How to Create Good First Issues (as a maintainer).
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
