The process of handling development stages needs a bit of work

Bouncing off of this:

Help desk can handle a great deal but one thing we don’t and/or can’t handle is promoting dev stages. I’m going to keep this terse, but i think there needs to be more than a few people who are point-people who can promote people to elevated dev stages. @burke seems to be over-taxing himself – perhaps we need to have multiple people able to promote others so we don’t run into @ssmusoke’s situation again.

What is everyone else’s opinion?

4 Likes

Agreed; we’re still waiting on a documented process for this, especially in the more senior stages, and it’s been 14 months now, so we should probably work really hard to get this done ASAP.

People have been asking … especially newly-named /dev/1’s who would like to move up. :stars:

4 Likes

@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: https://wiki.openmrs.org/display/RES/OpenMRS+Developer+Stages

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.

4 Likes

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 https://wiki.openmrs.org/display/RES/OpenMRS+Developer+Stages.
  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.: https://talk.openmrs.org/groups/devN/members 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:

5 Likes

@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.

2 Likes