OpenMRS Developer Stages

December 15, 2014

During the OpenMRS Leadership Camp 2014, we talked about ways to empower and scale the OpenMRS Developer Community. While our approach to collaborative development has gotten us far, we don’t have a clear process for developers to grow in responsibilities.  The fact that OpenMRS has approximately the same number of developers doing code review or pushing to core as it had five years ago is a significant failure on our part.  We’ve been talking about ways to be more inclusive for a while, but haven’t put these desires into something actionable… until now.

With the help from several folks in the community, I was able to come up with a draft process for recognizing the stages of a developer within the OpenMRS community:

Stage Description

  • Be or desire to be a developer
  • Can communicate well and show respect for others
  • Willing to be opened
  • Chat with devs on IRC
  • Can become a /dev/1
  • Claim an intro ticket (or a non-intro ticket with assistance from a /dev/2+)

  • OpenMRS ID
  • Development Environment
  • RTFM
  • Introduced
  • Claim ticket
  • Pull Request Accepted
  • Pass 5-10 question Introductory Quiz
  • Has tackled at least one intro ticket
  • Can write a unit test
  • GSoC
  • Post to dev list
  • Propose topic(s) on Dev Forum(s)

  • Helps others
  • Participate in Dev Forum(s)
  • Active ≥3 months
  • Can handle low complexity tickets
  • Has tackled at least 10 tickets
  • Can create a module
  • Has pair programmed
  • Claim low-to-moderate complexity tickets
  • Publish a module and resources to Maven repo

  • Curate ticket(s)
  • Working with others
  • Can handle moderate complexity tickets
  • Can function independently, yet looks for opportunities to pair program
  • Assisting with code review
  • Code review
  • Configure CI
  • Lead Sprint
  • Push to module(s)

  • Performed at least one Spike for the community
  • Leading Dev Forum(s)
  • Leading Sprints
  • Overseeing code reviews
  • Endorsed by implementer(s)
  • Can handle complex tickets
  • Has publicly thanked at least 10 other devs
  • Finds effective ways for developers across organizations to work together
  • Push to core

  • Responsible for a component
  • Mentor
  • Engages with implementation(s)
  • Leading development
  • Finds ways to make local implementation development benefit the community and community development benefit local implementations.
  • Can establish coding conventions
  • Can deprecate services

The goals of defining a process like this are:

Our goal would be to fully automate the transition from /dev/null to /dev/1 – i.e., anyone in the community should be able to transition to /dev/1 without requiring manual review from anyone else in the community.  Realistically, transitioning through later stages of development would require some manual review, but our hope would be to keep things as objective as possible, so any developer would know what she needed to do in order to advance to the next stage of development.

Next steps:

While I could spend more time revising this blog post, it’s primary purpose is to share the work in progress, so I’m going to stop editing and let it go warts ‘n’ all. 🙂

You can see the actual OpenMRS Developer Stages wiki page here.

Leave a Reply

Your email address will not be published. Required fields are marked *