OpenMRS Developer Stages
What are the OpenMRS Dev Stages?
This is a mechanism by which people involved in OpenMRS Development can progress from a new community member (/dev/null) to a development guru (/dev/5) as their development skills progress. The purpose of developer stages is to help clarify where people are in their journey, motivate people to become increasingly skilled in OpenMRS development, and help us recognize when people are becoming more skilled with OpenMRS Development. Developer stages are not meant to create a bureaucratic process around community privileges.
The table below gives you a high level view of the criteria, expectations, and priveleges for each stage. This worksheet, which is a work in progress, provides more details about the specific skills each stage needs to meet these criteria and expectations.
How do I recommend myself or someone else for a Dev stage upgrade?
Please use this form to submit dev stage recommendations!
Then approximately monthly, the OpenMRS Global Support Team reviews the submissions and checks the suggestions against the Dev Stage Criteria (below). Don’t be shy - you can also ask for feedback on how you could get closer to the stage you’re hoping for. You can also nominate someone else - we strongly encourage peer nominations!
Criteria and Requirements for OpenMRS Dev Stages
Stage | Criteria | Expectations | Privileges | Example Role(s) |
|---|---|---|---|---|
/dev/null "Noob" |
How to Earn: See /dev/null badge on Talk | Community members are expected to be nice. We're all in this together!
|
|
|
/dev/1 "Beginner" |
How to Earn: See /dev/1 badge on Talk | A beginner is expected to have engaged with OpenMRS development.
|
|
|
/dev/2 "Coder" |
How to Earn: See How Developer Stages Work | A coder is expected to be able to make meaningful contributions to OpenMRS development.
|
|
|
/dev/3 "Skilled" |
How to Earn: See How Developer Stages Work | A skilled coder is expected to be able to think beyond their own needs or their organization's needs, including how their code affects others in the community and able to coordinate community contributions.
|
|
|
/dev/4 "Expert" |
How to Earn: See How Developer Stages Work | An expert is expected to be capable of thinking outside the box, understand complex technical concepts, and coordinate efforts across projects.
|
|
|
/dev/5 "Guru" |
How to Earn: See How Developer Stages Work | Gurus are expected not only to be able to make significant contributions to complex projects, but also lead the development of them.
|
|
|
I think the most practical/useful way to track and monitor these stages (whatever they work out to be) would be to create in Discourse (OpenMRS Talk) both "task badges" and "dev stage badges".
In other words, create a badge for the various criteria (introduced themselves, claimed a JIRA issue, PR merged) and then create a badge, i.e. "/dev/1" that watched for people who had the necessary combination of those requisite task badges. This would allow us to do things like (A or B or C) and (D and E) and also add in the time minimums to prevent people grinding through all the stages instantly without any community bonding period.
In order to monitor external services, some of these specific criteria (e.g., JIRA issues, GitHub activity) will require either a new custom Ruby-based Discourse plugin or (in the case of GitHub) improving upon the existing one.