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
/dev/null

“Community”
Criteria
  • Be or desire to be a developer
Expectations
  • Can communicate well and show respect for others
  • Willing to be opened
Privileges
  • 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+)
/dev/1

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

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

“Cooperating”
Criteria
  • Curate ticket(s)
  • Working with others
Expectations
  • Can handle moderate complexity tickets
  • Can function independently, yet looks for opportunities to pair program
  • Assisting with code review
Privileges
  • Code review
  • Configure CI
  • Lead Sprint
  • Push to module(s)
/dev/4

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

“Leading”
Criteria
  • Responsible for a component
  • Mentor
  • Engages with implementation(s)
Expectations
  • Leading development
  • Finds ways to make local implementation development benefit the community and community development benefit local implementations.
Privileges
  • 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 *


*