Our changelog, announcements, dev posts, and anything else we think you'll find interesting.
From my experience working with open source projects over the years, I noticed many of them (including popular ones) don't have an onboarding process. I get it, it's a lot of work, and when you have 300+ issues to triage over the weekend, that’s the last thing on your mind.
The team behind NativeScript, on the other hand, has been hard at work onboarding developers who want to contribute to the project and ensuring that they do so in a scalable and consistent way.
In this article, we’ll explore the project a little and look at how the onboarding process works because there are some broader lessons to learn for all of us working within open source software when it comes to community building and operational best practices.
What is NativeScript?
The resulting experience minimizes language switching and IDE jumping – a huge improvement for the developers who rely on these modalities.
"The team has mentioned that having more hands-on sessions with regular contributors and maintainers would further improve the process because it helps to scale the understanding of the general process – which in turn speeds up the merging of contributions for future releases."
What Does the Onboarding Process Look Like for Developers?
The current cadence for contributors is about 10-15 people per month outside of the core team. While some are regular, there is also a healthy turnaround of new contributors – all of which need to be onboarded effectively to maintain consistency across the codebase. The team has acknowledged just how important a seamless onboarding process is, especially as things grow and expand.
The onboarding itself is quite a quick and painless process with most of it being self-driven. The majority of contributors do so via their own forks and this tends to take care of itself. However, when a contributor starts to be more active on a regular basis, the team will chat to them about guidelines and best practices that will help to bring them into alignment with the wider project conventions. Typically this will happen using Slack, GitHub, Discord, email, and Zoom as needed.
Nathan Walker, NativeScript maintainer, is helping out a new contributor in Discord.
The reason for this is that it helps to be proactive about the code conventions ahead of time, rather than trying to fix things later. The more coherent and consistent the initial contributions are, the less time and effort are wasted later on down the line.
The team has mentioned that having more hands-on sessions with regular contributors and maintainers would further improve the process because it helps to scale the understanding of the general process – which in turn speeds up the merging of contributions for future releases. In addition, a recorded session would also help to disburse some of the key information more widely.
"Unfortunately, those who don’t pay attention to these conventions make things much more difficult than they need to be."
What Makes for a Successful Contribution?
NativeScript has a wide range of use cases, and contributions that show a nuanced understanding of these are the most valuable. Typically this requires the contributor to take special care of the existing conditions in the code and leverage the functionality to create something new. Unfortunately, those who don’t pay attention to these conventions make things much more difficult than they need to be.
Taking some time here to align a contribution with the existing code style is a surefire way to be helpful and useful – and it's something that is greatly appreciated by the NativeScript team.
What About the Path Towards Becoming a Maintainer?
Over the past 3-4 years, the team has seen more and more contributors becoming regular maintainers for the NativeScript project. This is great to see for a 10-year-old project, and it bodes well for its future. While the project was part of Progress, there were a number of nStudio developers who played an active role, and they took over the responsibility of being sole maintainers when Progress passed the project back to the community.
nStudio did a great job before bringing the project to the OpenJS Foundation to help build out more community stewardship. In the past year, three new community contributors have been part of the Technical Steering Committee (TSC) and are actively involved in maintaining the project.
Developer onboarding is one of those things that can be overlooked when growing an open source community – but you do so at your peril. By setting a precedent upfront and helping to bring new contributors into your ecosystem, you are investing in the future of your project in a very sustainable way.
If you need help with onboarding at work, read this guide.
Thanks to the following people for helping with this post: Jory Burson, Nathan Walker, Marcos Placona, and Fabiana Castellanos.
About the author
Justin Dorfman is Sourcegraph’s Open Source Program Manager and is responsible for fostering the adoption of code intelligence in the open source community. You can chat with Justin on Twitter @jdorfman or our community Discord