You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 23
Next »
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.
Want to recommend someone for a Dev stage upgrade? Please use this form to submit dev stage recommendations!
| Stage | Criteria | Expectations | Privileges | Example Role(s) |
|---|
/dev/null "Noob" | - Be or desire to be a developer
- OpenMRS ID
- Introduced
How to Earn: See /dev/null badge on Talk | Community members are expected to be nice. We're all in this together! - 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+)
- Submit a pull request
- Take Introductory Quiz
| |
/dev/1 "Beginner" | How to Earn: See /dev/1 badge on Talk | A beginner is expected to have engaged with OpenMRS development. - Has tackled at least one intro ticket
- Can write a unit test
| - GSoC
- Post to dev list
- Propose topic(s) on Dev Forum(s)
| |
/dev/2 "Coder" | - Helps others
- Participate in Dev Forum(s)
- Active ≥3 months
- Resolved ≥10 tickets
How to Earn: See How Developer Stages Work | A coder is expected to be able to make meaningful contributions to OpenMRS development. - Can handle low complexity tickets
- Has tackled at least 10 tickets
- Can create a module
- Has pair programmed
| - Claim low-to-moderate complexity tickets
- Curate tickets
- Publish a module and resources to Maven repo
- Migrate a repo following our code of conduct
- Manage a release
| |
/dev/3 "Skilled" | - Curates ticket(s)
- Working with others
- Hugged by an implementation
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. - Can handle moderate complexity tickets
- Can function independently, yet looks for opportunities to pair program
| - Code review
- Configure CI
- Lead Sprint
- Push to module(s)
- Spike for community
- Initiate a maintenance release
| - Technical Lead for Sprint
- Spike Developer
- Release manager
|
/dev/4 "Expert" | - Perform at least one Spike for the community
- Leading Dev Forum(s)
- Leading Sprints
- Overseeing code reviews
- Hugged by ≥2 implementations
- Has publicly thanked at least 10 other devs
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. - Can handle complex tickets
- Finds effective ways for developers across organizations to work together
- Occasionally leading the Community Development Swim Lane.
| | |
/dev/5 "Guru" | - Responsible for a component
- Mentoring other devs
- Engages with implementation(s)
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. - An OpenMRS jedi
- Leading development
- Finds ways to make local implementation development benefit the community and community development benefit local implementations.
- Occasionally leading the Community Development Swim Lane.
- Accomplishing more through guiding/helping other devs than on their own.
| - Can establish coding conventions
- Can deprecate services
- Participate in OpenMRS leadership discussions
| - Participating in repo management
- Overseeing one or more community objectives
|