Hi everyone,
This year, we’ve responded to the wonderful thirst for collaboration by introducing squads, leading to increased action on shared problems. There are active conversations about additional ways to break down walls to contributing to our community (see here, here, and here). And yet we now face a situation where demand for experienced contributors is growing when our capacity at this level is extremely limited. We have not yet created and implemented a means for attracting talent and retaining contributors. Our fellowship program can provide incentives and motivation for contributors to join and stay in our community by offering the recognition and mentorship that so many contributors value and seek.
In the past few months, we have seen several exciting changes and opportunities emerge that make this an ideal time to kickoff a trial run. Read on for details on where we’ve been, where we are today, and what a proposed fellowship program looks like to our community. Please join the conversation about how we can get started right now and offer your ideas and opinions.
Where Have We Been?
Since 2010, we have welcomed many new developers through various mentorship programs which have been strong entry points to OpenMRS for new developers. Each year, OpenMRS is one of many organizations participating in Google Summer of Code and Google Code-In mentorship programs. We established a partnership with Andela and through this partnership, rotations of Andela interns worked on the Open Concept Lab for the OpenMRS project. Ideas about fellowships and the problems they can solve have been floating around for at least a year.
Where Are We Today?
We continue to participate in Google Summer of Code, Google Code-In, and now Google Season of Docs. Meanwhile, Andela’s focus shifted to providing companies with mid-level developers and our partnership ended. Some of the formative informatics experts and developers remain with OpenMRS.
We are increasingly reliant on scarce technical experts. Today, /dev/nulls and /dev/1s comprise about 85% of our developer pipeline compared to the 5% made up of /dev/4s and /dev/5s. Our newer developers, and those interested in joining the OpenMRS community, express eagerness and interest in growing their skills, continuing to contribute to OpenMRS, and advancing to higher dev stages.
The limited availability of more experienced developers, project managers, business analysts, and technical writers has led to a situation where some recruits and newer contributors leave our community because they lack guidance on what to work on or need mentorship to take on increasingly complex tasks that challenge them and meet their demand for development experience. This is a loss for all of us as these become passed up opportunities to help maintain and sustain our infrastructure, releases, and documentation.
Part of the solution involves having a clear pathway for making meaningful and valuable contributions - think well curated JIRA tickets, a list of active squads as well as projects, and a set of volunteer guides to help contributors find their way to these opportunities and supporting resources. The TAC and the Documentation Team are both working on some of these aspects.
The other part involves addressing capacity in a way that is sustainable, supports professional growth, and leads to long term engagement with the community. Technical experts, especially those from implementations, still have limited availability. We continue to lack mentors and guides for those who want to become a /dev/4 or /dev/5 or experienced technical experts who want to expand their expertise in new areas, such as FHIR or microfrontends. Fellowships can be one way of expanding our pool of experienced developers while also building the skills of existing developers in our community who seek opportunities for growth.
Fellowships: Towards retaining a sustainable pipeline of talent
At OpenMRS, we seek to motivate community members by offering meaningful opportunities that lead to mastery and growth. Through fellowships, we can give individuals in our community the challenges they crave to grow or expand their skills, while also unblocking our pipeline and addressing community priorities. By aligning fellowships with our developer, community, and terminology stages, contributors willing to commit to a fellowship have a clear path for professional growth. Fellows can also advance or build out their skills in specialized areas by working on special projects that have real value for the community and implementations. Fellows get to hone their skills and become not only an OpenMRS jedi but a FHIR, ETL, DevOps, or QA guru. Becoming an OpenMRS fellow can be its own form of recognition.
The ideal OpenMRS fellowship program would have a dedicated group of mentors or instructors, projects for fellows to complete and enhance their skills in multiple areas, clear assessment criteria for advancement, and in-country rotations with OpenMRS implementations. Our dev stages would be fleshed out and expanded to include a broad range of skills in languages, frameworks, content management, tooling, open source project management, quality assurance, technical writing, etc. We could establish new levels or tracks on business analysis, technical project management, quality assurance, terminology, and infrastructure. These could be used to create standard fellowship plans and evaluation rubrics. The fellowship program could have its own, structured set of materials and possibly be linked to an OpenMRS Academy or other academic institution.
To sustain the program and our pipeline, we can build a mentorship component into our fellowship program, where more senior fellows mentor and guide community contributors. To get this off the ground, we can recognize these additional efforts by providing a modest stipend.
All of this will take time, effort, and funding to establish.
What do we need to get started? Is it at all possible to start now?
We are successful when we start small and build from initial successes. There’s no need to wait until we have everything in place for the ideal fellowship program - provided we have enough to get going.
Here are four critical elements that we need to have in place in order to get something off the ground:
- a group of experienced developers, project managers, and/or technical writers who can guide and mentor more junior fellows and others in the community
- curated tasks and projects that are important and valuable to the community
- a way for experienced contributors to dedicate significant time for learning and mentorship
- clear objectives and expectations for fellowships that can be used for assessment
So what do we have in place right now?
- We have our platform roadmap, technical priorities identified by the TAC, and emerging approaches to module maintenance and JIRA curation
- We have several special projects about to begin that are great opportunities for mid and senior level developers to expand their skill set, guide a squad, and mentor others
- We have our OpenMRS developer and community stages that can be used to set expectations
- We have some draft fellowship descriptions based on a few of our dev levels
What’s Next
We have enough in place that we can try out a few initial fellowships and address short-term gaps as we go along. It’s time to put some of these ideas into action and simply see how it goes.
So here are some concrete actions we can take right now and in the next six months:
- Create a group of “Mentor Fellows” from experienced developers, project managers, or technical writers. One way of doing this is to start with two or three senior fellowships that includes mentorship. These Level 4 or Level 5 Fellows can contribute to specific projects that benefit the community while mentoring GSOCers and other /dev/1s, 2s , and 3s.
- Review and amend fellowship objectives. Our dev and omrs stages are good starting points and we will also explore additional “tracks” for BAs, PMs, and QA.
- Work with senior fellows to find ways to make it easier to dedicate at least twenty hours a week to mentoring others and becoming an OpenMRS jedi with a specialized skill set. If the fellow already works full time, this could include coordinating with organizations regarding the fellow’s time.
After 4-6 months, we can check in with the fellows and identify what is working well - and start identifying what changes we’d make next in order to make the fellowship experience richer and more satisfying.
More To Figure Out
Even as we get started, we still have plenty of questions to discuss and work through. Here are a few that I’ve already heard:
- How can we include DEI (diversity, equity, and inclusion)?
- What kind of commitment will we ask fellows to make? How will we hold them accountable?
- How can we ensure that fellows have a meaningful experience that benefits the community and implementations?
- How can we motivate fellows to continue contributing to the community once their fellowship has come to an end?
What is your opinion about this approach? How would you answer these questions?
@paul @janflowers @burke @grace @akanter @wanyee @christine @ibacher @hamish @mozzy @dkayiwa @ball @herbert24 @sharif @gcliff @chris
