4 things that will facilitate your open source contribution
According to TechRepublic, “open source has become a keystone for enterprises across the globe.” With IBM acquiring open source companies like Red Hat, it shows the value of developers who write the software code. In fact, they are called as King Makers. Developers contribute to the open source community like GitHub for a variety of reasons – ranging from improving the usability of the code, standardizing for interoperability to build their career and give back to the community. Because of the collaborative nature of the community, innovation happens here, which seems to be another attractive factor for the developers.
There are numerous resources to get started with an open source contribution. ‘Contributing to open source for the first time can be scary and a little overwhelming’, says Scott Hanselman. Yet, there are passionate people like Kent Dodds out there trying to help out the developer community. One of our teams at Imaginea, based on their learning and inspired by Kent and Scott, came up with a list of factors that every developer needs to be aware of while contributing to an open source project – which can be applied for any open source contributions in the future.
Understand the problem statement
Often, leaders in the community are wary of the newbie developers, because it requires a lot of hand holding as they fumble around trying to figure out how to communicate and contribute in an open source project. To overcome this, first the developers need to understand the problem statement mentioned in the push request. A quick feasibility study can help understand if it is a bug fix, enhancement or a new feature and tag them appropriately. For example, if there is an enhancement request, developers can create a new issue in GitHub and tag it as an enhancement. This can make communication clearer.
Follow coding guidelines
Developers learn to code in different ways, which gives rise to different styles in writing codes. This leads to programming conflicts, which can make a team inefficient. Having coding guidelines/standards would help solve this type of problems. In the open source projects, look for any recommended structure posted by the owner and align with that. This will help in writing consistent code, which can be easily understood by anyone in the team. It also helps new team members to see how the code is structured. All these paves way to clean coding, with fewer bugs – meaning lesser time spent in maintenance.
Think and plan the testing
The test plan should tell why the new code should be added to the project. It is a place that defines what to expect, after adding it to the repository. It doubles up as a proof of sorts that tries to show that the program works after adding the new piece without any hiccups. With respect to testing, look for already existing test suites available in the repo and add tests specific to new changes. Here is a test plan and the test repo with live examples.
Prepare the PR
A Pull Request (PR) is the way to notify the project maintainers/owners about the changes a developer is attempting to make with their new code – like a bug fix or a new functionality – and it should be reviewed and added to the project. Here is the documentation that describes the steps to create a PR. Before submitting the PR, check the code thoroughly and make sure that it works well and doesn’t hamper the existing functionalities. If necessary, update the Readme file. Here is the PR created by our team for your reference.
Any PR with a lot of code changes causes a big overhead during the code review. Cisco Systems programming team case study revealed that a review of 200–400 LOC (Line of Code) over 60 to 90 minutes should yield 70–90% defect discovery. Therefore as a best practice, do not club multiple functionalities in a single PR. For example, if the code is doing more than one functionality, break it into multiple PRs.
Things like title, description of the issue must be precise and short. Make a self-explanatory title which gives an overview of what the pull request does. A description should have briefly explained topics covered with the problem statement, proposed solution, current behaviour, expected behaviour and steps to test. These things will make the reviewer’s job easier.
It is a good practice to mention the open existing issues related to the problem statement which is solved, against the submitted PR. This will give the reviewer a clear picture about the solutions present in the PR and the priority for the bug fix or feature implemented. Tag the reviewer of the open source repo in the PR which gives more visibility to the reviewer as well as to the contributors who created similar issues for the same problem. Actively interact with the reviewer. Try to respond to any comments and changes requested by the owner or community as soon as possible.
These factors are a culmination of lessons learned through our team’s first open source project. Nowadays, we follow these invaluable practices conscientiously, which improves the quality and execution of all our open source contributions and even for our client engagements.