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
|
| /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:
- Remove the mystery of why one developer can do something and another cannot.
- Create a path for developers to grow in responsibilities within the community.
- Increase the number of developers in the community who can take on specific roles.
- Give new developers a clear vision of what contributions and behaviors are desirable and rewarded.
- Allow implementations and developers to more easily understand and communicate level of developer expertise.
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:
- Working with the infrastructure team to automate as much of the process as possible (especially the transition from /dev/null to /dev/1)
- Getting feedback from others in the OpenMRS Developer Community on this approach. Does it feel like the right direction? Any ideas on how we might improve it?
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.