It makes sense that the earlier stages (for which the reviewer pool is larger) require more reviews. (Is that what you’re saying?) 5 sounds like a large number, but I defer to you and others about demand, and how things will play out in the earlier stages.
How about something like this?
5 reviews for /dev/1 to /dev/2
3 reviews for /dev/2 to /dev/3
2 reviews for /dev/3 to /dev/4
2 reviews for /dev/4 to /dev/5
The developer stages are written for people developing openmrs-core and modules, that make up the main OpenMRS EMR platform and application.
A fundamental part of the value it conveys to someone external that this dev can work at a certain level on OpenMRS, e.g. it’s a credential you might look at before contracting with someone.
So, I don’t foresee us changing the developer stages to encompass more than the main OpenMRS product.
These products and efforts are valuable for sure! Indeed if you want to start to define “infrastructure stages” in an analogous way, that would make a lot of sense. Similarly it would be great if we had “implementer stages.”
The point is just that OpenMRS Developer Stages are meant to indicate something specific (demonstrated ability to develop and collaborate on the EMR platform), and dual-purposing developer stages to also be something else would muddy the message.
There is nothing currently written in the dev stages policy to exclude any specific types of coding contributions, or limit it to any specific projects.
I think creating such a limitation now would be a slippery slope, and will discourage people from doing other types of coding, such as on distributions, or QA/test platforms, the SDK, experimental clients, release engineering, etc. But if the engineering team disagrees, at a minimum these “more special” projects should at least be identified in the policy so people aren’t disappointed after their hard work.
The original plan was for /dev/5s to oversee the process of OpenMRS Developer Stages, both ensuring people are getting promoted when appropriate as well as iterating on the process itself (like we’re doing here). Progress had been stymied on trying getting the /dev/null → /dev/1 process working, getting groups in Discourse, and creating a (preferably not manual) process to align stages between Discourse & GitHub before we held a kickoff virtual meeting amongst /dev/5s. I had originally avoided the /dev/N promotes /dev/N-1 approach, because levels prior to /dev/3 are not expected to be that engaged with the community.
I happened to have had a chat with @michael today regarding dev/2 promotion for current dev/1 members (me and @ivange94 , to name a couple) who are still actively contributing.
I think the privileges of accepting tickets straightaway and the incentive to do even better after such a promotion would be pretty cool. @burke Maybe we can moderate such activities every 3 months
A process for keeping GitHub team assignments aligned with Discourse badges that doesn’t depend on a single person. I was hoping to create a scripted process for this (at least to scan and report discrepancies), but haven’t been able to get API access to Discourse and ran into some limitations on the Discourse API.[ref]
A forum for discussing dev stage assignments (e.g., the “dev3-5” meta-group @michael mentioned). We’d probably want a private forum so people could be frank & honest in their opinions.
A clear way for people to suggest a dev stage assignment. Maybe this is a post to the meta-group? Devs could suggest a change for themselves or anyone else. We’d expect at least /dev/5s to be looking for opportunities where someone is deserving of a new stage.
A regular (e.g., 2- or 3-month) meeting to review potential re-assignments. We could always address these inbetween, but a regular meeting would ensure that outstanding issues don’t languish.
A regular (e.g., 2x or 3x each year) review of the entire process (forced conversations like this one). I was thinking of doing this with /dev/5s, but it could really be /dev/5s + anyone interested.
At the end of the day, my primary interest in Dev Stages is to explicitly acknowledge people’s level of engagement with the community (from “community member” to “leader”). It’s not like this is a simple sequence of activities in a perfectly straight line, but I think it’s important to acknowledge and encourage greater depths of engagement. In the end, we need more people contributing, more people coordinating contributions, and more people spending time in the important “meta” efforts of enabling everyone else. The ability for people to publicize and discover people’s general level of technical skillset is a nice side effect.
@burke, Michael helpfully made a proposal above, and updated the Developer Stages wiki page to say how people should request status N (by messaging the N+1s on talk).
If you want a different process, we need to change this. (Though personally, I don’t see myself having time and energy to review requests to move from dev1 to dev2…)
Broadly, what is the concrete next step here? I think you’re saying that we should schedule a recurring meeting every 2-3 months to review potential re-assignments. If so, please ask Jamie to help set this up.
I emailed the help desk asking for admin access to Discourse so I can make a script to point out inconsistencies between Talk Badges and GitHub privileges.
Created and shared a Google doc for now.
I’ve asked @jthomas to set up a meeting. Actually, I’ll send out an invite soon to get the ball rolling.