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…
We should automate the process IMHO – we’re developers – we automate life 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:
- 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.
- 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.
- 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.
- 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.
- 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.
@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.)
- 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
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.
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.
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
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.
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.
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/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-1 approach, because levels prior to
/dev/3 are not expected to be that engaged with the community.