The process of handling development stages needs a bit of work

@michael - can we see where the current work on this is in order to figure out what needs to happen next?

1 Like

Wiki documentation:

Current status of refinement:

1 Like

In the past I’ve had to CC @burke on messages(by past I mean recently) when handling things – but helpdesk currently is NOT the place to go to elevate your dev stage…as to who is the one to talk to – we’ll see.

1 Like

FWIW, @ssmusoke is not yet qualified to be a dev/3. What he is requesting for, is temporary access to github such that he can release 1.11.6 After that, the privileges can be revoked from him, as he continues his way to become a dev/3 :smile:

I’m confused…

In this thread, we realized that it’s desirable to let people have access to write to openmrs-core in response to specific situations (e.g. Bharat is release manager for Platform 1.12 even though his dev stage is lower). That’s what “temporary access” is referring to.

Unfortunately we haven’t documented it anywhere on the wiki. @maurya is going to add it to the Release Process pages. Maybe he can also add this to the Dev Stages pages (or maybe we’ll need to wait for @burke for this.)

Is there a wiki page that takes about Dev Stages process, e.g. what do people need to do to increase someone’s dev stage?

That should happen here IMHO. Full transparency and all.

I mean the behind-the-scenes process like “add them to X github group” and/or “give them the talk badge by xyz clicks through the Talk UI”.

It should be a wiki page at a permanent address. The wiki is public and transparent too…

1 Like

We should automate the process IMHO – we’re developers – we automate life :smiley: Ideally, there should be an LDAP group for each dev stage – and then discourse should routinely poll that via an API (once daily), or have dasboard grant badges on discourse for us – either way works) and add stages automatically. Dashboard would also automatically add github access for the relevant dev stages

We should, I agree. That said, we haven’t proven to be very effective at doing that kind of thing so far.

So, as long as there are manual steps to be followed, we should write them down.


This is always step one in automating (IMHO). That said, as part of this documentation, let’s also make sure that we either:

  • Ensure someone is in fact /dev/3 before asking them to be release managers, or
  • Change the dev stage requirements accordingly.

I am not aware of any such documentation, other than the brief bits I’ve added temporarily to the existing Dev Stages wiki page.

Per @burke’s comment here (and @dkayiwa’s comment right before it) we intentionally decided to “not let dev stages get in the way”, and let @ssmusoke do this point release even though he didn’t meet the usual dev stage criteria, since he was willing to put in the effort.

So, yes, we need to document that when this happens, (a) the appropriate person should grant temporary elevated privileges, and (b) on the release process page, ask the releaser to verify this has happened.

But we don’t actually need to change dev stage definitions. (And “doing a point release” isn’t really the same as “being a release manager”.)

That makes perfect sense!

So back to the original (or at least) earlier question as to “what is the process to become /dev/2 or higher”, I offer this suggestion for the engineering team’s pull requests improvement:

  1. Person desiring stage /dev/N (where N >= 2) who is currently /dev/N-1 composes a private message to the current group of /dev/N using the link on
  2. Requester includes relevant URL’s to any objective items in the “Criteria” column for that stage. For example, JIRA user page listing issues worked, meeting notes page, Talk posts, etc.
  3. Existing pool of /dev/N members review the request and look to confirm any subjective items listed in the “Criteria” column from the wiki page. If acceptable, reviewer “likes” or explicitly replies to the private group message with their approval.
  4. Once the requester has received 2 or more affirmative reviews, one of the designated “group owners” for that stage adds that user to the list at the relevant link, e.g.: and notifies the requester.
  5. Requester should then open a help desk case as applicable providing their new developer stage, requesting access to Bamboo, Nexus, eligible software licenses, etc., as provided for at that stage.

This is probably a bit wordy but it’s a start. Let us begin hacking away at it. :slight_smile:


@michael, I like this a lot, and +100 for actually writing something down!

Is “2 affirmative reviews” a choice you made, or something we had collectively decided on elsewhere? (Offhand I think that’s the right balance, just wondering.)

Specific concerns:

  • what’s the pathway by which someone’s request is denied? Is it just that they don’t get two affirmative replies within some amount of time (e.g. 2 weeks)?
  • some people may not want to write negative replies that the applicant can see. (They should in fact do this, in a constructive/helpful way, so we need to find a way to set that expectation.)
  • I propose that if 2 affirmatives approve a request, then 2 negatives should deny it. (The person can always apply again later with more details in their application.)
  • what if nobody replies because of inertia? Is there a way that some project manager-type person could peek at these messages after they reach some age?
  • potential long-run workload for smaller values of N, especially for /dev/1s going on to /dev/2. (This is an inherent problem, not specific to this workflow.)

Below comments are my personal opinions, and certainly all are up for debate & discussion :slight_smile:

AFAIK it was just something I thought would be about right.

I think this is probably a good way to go. I don’t know if the 2-week limit is right, but timeboxing the decision is important, I think.

I agree that people should try to express their concerns directly with the requester in a constructive way, but if necessary, anyone in the /dev/N group could also create another message amongst itself to have this kind of side conversation.

See also the timeboxing question above. Hopefully we get some more leaders identified in the engineering teams identified soon, and this could be a role for some type of dev manager to keep an eye on.

Hopefully, although if it takes only 2 approvals, then in theory that run time is reduced for larger groups since there are more people available to review & respond.

1 Like

I think given the size of the /dev/1 and the inherent interest we have seen in dev stages, I think 5 is a better arbitrary number of reviews. I think two is too low. It might seem appropriate now, but I think given the latent demand we should make it 5.

1 Like

I have a question tangential to this discussion: say you work on products other than the EMR system, or modules for it…are you essentially “stuck” at your current stage. Asking for a friend. That friend may or may not be me.


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

1 Like

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.

1 Like