In this section we will cover some best practices for developers who want to contribute to the platform and recap some of the practices learned in other sections. This section includes best practices for developers of all levels of skill and ages from high-school to highly experienced.
If you’re new to opensource development, it takes a bit of getting used to. Some of the best and biggest products that power the world today are built by communities of developers working together - Linux, Node, Android. There are a number of strengths of working on an opensource product. The power of what the collective can build is far superior to what a single developer or a group of developers can envision. Opensource means lowering barriers to cost of licensing, and it also means that implementers have the freedom to customize and adapt the product according to their needs. Most importantly it creates a global good for the world.
But there are known challenges with opensource and it can sometimes feel like the veritable Tower of Babel! Knowing these challenges and accepting them as a natural by-product of the opensource process will help mitigate some developer frustration. Documentation may not always be complete, it make take effort to get the community to focus around a particular feature, the code written may not be of the best quality (remember that a lot of developers may be interns or new to writing code!). Take this in your stride.
This is a team sport. Working with other developers is an important component of the opensource process. If documentation is unclear or incomplete, do reach out for help. You can learn how to reach out for help in this section. It may sometimes seem easier to abandon adopting another product and building your own. Definitely you will have more freedom and you will rely less on others. But there challenges with building your own product too. The grass may seem greener on the other side. So please do engage with others and reach out for help. If you’re someone who prefers to work solo this may seem daunting at first, but the benefits will be clear later on.
Read our contributing guidelines here. Please be respectful of the diverse community of contributors who may be from different countries and cultures and speak different languages.
When joining a release, reach out to the Release Manager who will provide support.
Pick up an issue to work on from our Zenhub Board.
Create a branch on GitHub from master and name it with the issue number and a few words about the issue.
Commit your edits to this branch. Make sure to document in code with comments where necessary.
Make sure to properly perform unit testing for the sections you have developed. If possible, write unit tests in the code. Test the code thoroughly in your local machine.
Notify the Release Manager for the next release that you have completed the code.
We create a separate branch for each release. Create a pull request to the release branch. Select a reviewer on GitHub.
The Release Manager will review the code or assign an experienced developer to review your code.
If the reviewer requests some changes, then they will respond in the comments on specific commits. Once you have made the changes request for a review again
The reviewer will then merge your pull request into the release branch.