Thanks to programs like GSoC, GCI, and university courses, we see surges in new developers coming to our community every February/March. Our annual Implementers’ Meeting also produces a spike.
Thanks to @rainbow’s work last year on updating our Get Started as a Developer Guide, we’ve seen a drop in questions on Talk about getting OpenMRS set up and getting going. This is exactly what we hoped would happen!
What we’re seeing now is that onboarding people to a particular squad or team has its own challenges and takes time. Some squads and teams (like the MFE Squad and QA Support Team) are talking about or working on their own Getting Started Guide. This will help….and integrating these guides into an onboarding “Flight Path” to a specific squad or team will make the full community onboarding experience even better.
Bonus: The Documentation Team and the Website Design Squad have been rolling around with this idea. It’s already helping them align website and Wiki content- and remove/avoid duplicate content.
TL; DR: It’s not enough to get someone on the OpenMRS community plane. Once they’re on board, we need clear, aligned documentation and tools that connect individuals to the right squad or team. “Flight paths” point newcomers to the right squad and the right Getting Started Guide that aligns with a person’s chosen destination, allowing them to take flight with the right squad/team - and from there, grow their reputation and become a valued member of the community.
At a very high level, flight paths could look something like this:
Want to know more about why we need flight paths and what they are? Watch this lightning talk or read the next post.
Feedback, please! If you’ve found it challenging to join a squad/team or if you’ve helped people join a squad/team, we want to know what you think. How do you think Flight Paths will change the onboarding experience? Aside from Getting Started Guides and bonding periods with squads/teams, what else would you like to see in a Flight Path?