The process of handling development stages needs a bit of work

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

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

it should encompass more than that though – there are support products that are critical to keeping the community afloat.

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.

That would be nice. So few people jump in.

I understand where you’re coming from…not liking it but understand it.

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.

6 Likes

I tend to agree here. An angle I didn’t think about.

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.

Good points. In that case, what about creating a meta-group of “dev3-5” to review the requests for elevation?

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 :slight_smile:

3 Likes

Things that would help:

  • 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. :slight_smile:

4 Likes

Bump.

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

2 Likes

I think my request is a no-brainer though :smiley_cat:

Okay.

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.

3 Likes

I’m technically closer to dev3 than dev2…so sorry for hijacking

1 Like