There are a lot of benefits to being a Zephyr Project contributor. You’ll have the opportunity to improve your existing skill sets, find mentors, teach others, work with like-minded individuals, create public artifacts, build a reputation, and even learn some people skills in the mix.
Although submitting some code to improve the project can be its own reward, there is a bigger picture here. One where participants have the opportunity to become part of the innovation behind what Zephyr Project is all about, a new real time OS that will have a significant impact on IoT.
Contributing to any open source project for the first time may seem somewhat complex and intimidating. We at the Zephyr Project understand this and want to officially welcome your ideas and code contributions.
It’s pretty common for new contributors to face some basic hurdles on the path to getting a “successful pull request,” a situation where code can be reviewed and discussed for inclusion in a project, ultimately becoming part of the upstream repository. Pull requests are further covered in the Zephyr Project’s community guidelines documentation and getting to one takes following some outlined instructions in that document.
To help smooth the process, we’ve gathered some tips and tricks on how to get a contribution noticed — straight from the project’s maintainers.
Things to Do Before Submitting a Pull Request on the Zephyr Project
Before you create a pull request, it’s a good idea to orient yourself to the community a bit and make sure to address some basic issues. This will increase the likelihood that the community embraces the ideas presented in a new code snippet and the required number of reviewers approve moving ahead.
- Look at Existing Zephyr Code. Contributors should always look at the existing Zephyr code before they write any new code. There may be identifiable patterns or snippets that may ease the creation of new code and can ultimately help out when developing new code.
- Leverage Git-Extras. Many platforms support the git-extras package, which can greatly simplify interactions with GitHub, speeding the process and submission of code as well as handling some of the basic housekeeping chores.
- Don’t Forget About IRC. Many community members are available via IRC and in many cases an simple answer to a complex question may just be one post away. IRC gives contributors the ability to share information, ask questions, get advice, and ultimately build comradery that improves interactions.
- Check the Maintainers File. It’s always a good idea to do a little research before diving into creating any new code. At the very least, contributors should delve into the maintainers file to contact a maintainer of a particular subsystem directly. That in turn may provide additional background that will be useful for creating any code and also may help smooth the path to a successful Pull Request.
- Remember non-Apache 2.0 Components: The Zephyr Project is robust enough to support non-Apache 2.0 components, allowing an added level of creativity. However, contributors should make sure they contact the TSC mailing list before submitting a pull request to validate component inclusion. That helps to ensure that no efforts are wasted and that the components can be included.
Taking the Next Steps
After going through what you should think of as due diligence, there are some other steps that can help smooth the path to successfully contributing code to the Zephyr Project.
- Understand When to Make a Pull Request. In other words, make sure you have your ducks in a row before making a Pull Request, perform due diligence, make sure all required info is included and standards are considered.
- Communicate Meta Info. Contributors often forget to include metadata, which is often a critical element that a reviewer wants to see.
- Communicate Professionally. Be courteous and professional in all of your communications with the community. Disagreements need not ever turn into arguments.
- Be Willing to Revise. Changes, requests, and revisions are a part of community life. Be accommodating and be willing to address concerns and make changes if need be.
- Adhere to the Project Standards. The rules and standards do serve a purpose. Ultimately, they exist to keep the submission process smooth and hopefully quell any errors or bugs.
- Initially Propose Small, Backwards Compatible Changes. It is the quality of the code and the purpose that it serves that counts the most. In the beginning, it’s better to focus on small changes than to try and make huge changes to the code base.
By following some simple guidelines, accepting sage advice, and communicating with the community, contributors can see their code incorporated upstream and help advance Zephyr and the broader community of embedded technologies that promotes innovation and the development of open source code.
