An OpenMRS Fellowship Program: What Can We Do Today?

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:

  1. a group of experienced developers, project managers, and/or technical writers who can guide and mentor more junior fellows and others in the community
  2. curated tasks and projects that are important and valuable to the community
  3. a way for experienced contributors to dedicate significant time for learning and mentorship
  4. 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


Hello @jennifer , Thanks so much for your effort towards this programme, i believe the community would greatly benefit from it.

Just to give an idea regarding one of the questions to do with “accountability”

  • About the Fellow’s commitment , we can always set up the minimum required time a fellow would have to spend working on a given project per day/week say 30hrs per week

  • And using the existing Jira issue tracking System , we can curate tickets with the expected amount time to be spent working on the given task ,and the complexity of the task , that is in regards to the dev level expected to work on a given task.

So at the end of the given time , we can always track the amount of effort /number of tasks / time spent / complexity handled by each fellow


Great looking forward for it :smiley:


@jennifer if possible fellows can be given a chance to mentor new upcoming fellows(who are of lower dev levels) in the subsequent community fellowship programs


What about setting the expectation that fellows will commit 20-30 hours per week, with those electing to mentor other dedicating at least 10% of that time to mentoring community members? @gcliff, I think we should encourage fellows to mentor anyone in the community - not only those working on similar projects. What do you think?

1 Like

Sure that seems very fine

Thinking about the accountability question, I think there’s more to it than making a time commitment but about demonstrating that the fellowship is achieving something of value for both the fellow and the community. If part of the aim of this program is to grow skills and expand our pool of experienced contributors, then we’re likely talking about setting specific professional development objectives and then working towards them.

@mozzy, your idea about jira tickets is a good starting point. If we take the skills and expectations that @burke and others laid out for our Developer Stages, I’m imagining a /dev/3 who can already create a set of tickets to accomplish a specific project and knows that she needs to be able to create epics and organize tickets in order to advance to /dev/4 by the end of the fellowship. If she knows what she needs to do, then it’s a lot easier to look for opportunities to organize tickets and create epics. The /dev/ expectations become objectives to shoot for.

Back to accountability, @janflowers shared some mentorship tools with me a little while ago. Among them is an example of an individual mentoring plan for laying out short and long term goals. It looks like it’s meant to help mentees link their career objectives >>> specific activities >>> projects >>> artifacts.

Other ideas? How can we make this easier?


i absolutely agree on this

sure thats right ,

i only meant also in the subsequent fellowship programs to

Thanks @jennifer for bringing up this, Actually creating and curating tickets as part of task shouldnot be /dev/3 work to my perspective and it depends upon work commitment to a fellow , since they have already privileges of making these tickets ready for work and digging deep into, they should leave that work of div levels below. This will even enable a dev2/dev1/dev null to think and get familiar of how to create tickets , how to document , getting familiar with jira issues just incase guided by /dev3/dev4/dev5s. otherwise would also like to hear more from your views. thanks

thats great. probably you can share the full details about that

I still hope that there will be a chance for dev1/null people to be fellows :joy: