Stage upgrade process improvement

Development
1

In the interest of having more OpenMRS experts in our community, we have ongoing discussions to improve the stages - including the upgrade process;

  • Validating an upgrade recommendation/proposal perhaps through some sort of surveying or check with some available personnel within the proposed stage.
  • Recognising people who have advanced on virtual community meetings.
  • Any further thoughts are welcome.

With the ongoing Fellowships aimed at mentoring fellows and helping them advance, today i posted an upgrade proposal interested in feedback around my recommendation and i have noticed we generally as a community straight away send flowers to the candidate, i have felt like this is great although may need to have it’s right place being taken as; a recommendation/proposal rather not an approval and i am not a lone.

4 Likes
2

Kindly I haven’t understood this point. I humbly request you shade more light on it please!

3

validation through either some sort of survey or checking with those already possessing the proposed stage

4

@k.joseph, thanks for bringing this up! I’ve noticed the same thing. When you made your recommendation, it seems like you were asking others in the community for feedback. Do they agree with your recommendation? Do they want to know more about why you’re recommending someone? I think what you’re saying is that posting an upgrade proposal is simply that: a proposal. And you’re asking a good question: how can we improve our process for nominating and then validating a recommended stage upgrade?

I decided to see if we had any guidance on our Wiki. Here’s what I found:

Who decides?

As mentioned earlier, community members should be able to go from /dev/null to /dev/1 on their own and reach /dev/2 based on objective merits. Beyond that, advancing people through stages is a manual process for the community. /dev/3 s, /dev/4 s, and /dev/5 s meet periodically (2-3x/year) to review current staging assignments and adjust them. If you feel that you have earned a developer stage, then make sure a /dev/3, /dev/4, or /dev/5 knows about your interest in advancing stages as well as the steps you’ve taken that support your advancement. People are welcome to nominate themselves as well as others for advancement. Remember, developer stages are not just a measure of someone’s development skills, but also a reflection of their engagement with the OpenMRS Development Community.

Are you thinking that a survey would be used to nominate someone, like we do with Volunteer of the Month? Or to ask people if they agree or disagree with your nomination?

I think we have a lot of our technical leaders at the TAC meetings. Could we ask them to take 10 minutes at one of their meetings 2-3 times a year to review nominees?

2 Likes
5

I actually think that we should prefer a very open process, but maybe we need to be a bit clearer about how this is done. On the one hand, especially if @k.joseph is feeling unsure about whether he followed the right process in his recent nomination, then we clearly haven’t done enough to make it clear how one should go about handling nominations. On the other hand, I quite like this quote from this page in the Wiki:

Developer stages are not meant to create a bureaucratic process around community privileges.

And I think it’s good if we can keep the process as simple as possible.

Ideally, I think, anyone at /dev/3 or higher should be able to nominate any other person they feel meets the criteria to progress to another stage. And of course, anyone should be able to nominate themselves for a new dev stage.

Doing this via Talk is nice: it’s asynchronous, so it doesn’t have to wait for certain people to sign-off or for a particular scheduled meeting; it’s public, so everyone can see the process as it happens.

Realistically, though, this hasn’t been the real process. To try to be transparent about this, there have been some private threads on Talk related to nominating people (mostly getting sign-off from either myself or @dkayiwa and coordinating who writes the post); I’m sure there are others I haven’t been part of. Likewise when I was first promoted, I too ran nominations past Dan before posting them on Talk. And looking back through the last few self-nomination posts have clearly been written after the person nominating themselves has reached out to Dan (who probably told them exactly what he’s told me: that’s fine; post it to Talk and get the community’s input).

So, from my perspective I think the questions I would want to be asking are:

  1. How do we make it very clear that it is perfectly acceptable to nominate yourself for a new dev stage?
  2. How do we make it clear to /dev/3s and above that they are allowed to nominate others?

I would suggest that maybe one thing that would be helpful to do is to create some templates on the Wiki with the text for nominating someone and text for nominating yourself.

Some examples of nominations that I think are excellent:

This one for @jayasanka is one of the best-written nominations I’ve seen. This one for @aman is short but extremely clear about why @aman is qualified. This self-nomination from @permissionerror and this other self-nomination from @ivange94 are, I think models for how self-nominations should look.

Hopefully this doesn’t derail the conversation here. Overall, I want to be sure we have a process that is clear, transparent, and frequently taken advantage of. :smile:

PS I’m much less concerned with validating whether a recommendation is right or not; perhaps it makes sense to place some onus on the person writing the nomination to explain why they feel that the person they are nominating meet the criteria and as long as the explanation is good, I don’t see why we’d ever want to discourage someone.

4 Likes
6

If dev stages were based on a clearly defined list of skills & experiences achieved, then the process would be more objective, less dependent on time/nomination/social factors, and more useful as a metric for implementations & service providers.

Then nomination would only be needed to highlight someone whose dev stage doesn’t align with their skill set rather than being the process itself.

The original intent of dev stages was to encourage community engagement; however, not long after introducing dev stages, developers said they wanted dev stages to reflect dev skills and not engagement, so community engagement criteria were removed and “parked” in om.rs/stages so they might be used as omrs stages (community engagement stages) independently some day (should we decide to do that).

I personally would prefer not to be making subjective calls or participating in perfunctory processes where names are read on a recorded call and everyone agrees because it’s too awkward to dissent and there’s little or no objective information beyond online interactions with people on which to base decisions. At a bear minimum, there should be a shared & enumerated list of expectations of each stage. And, for example, we shouldn’t be all agreeing that someone is /dev/3 unless we can all agree that they haven’t (yet) reached /dev/4. Without a shared metric or objective milestones, I fear this would just be dressing up an informal process to make it appear more formal. If we’re really keeping community engagement separate, then someone should be able to reach /dev/4 or /dev//5 without any of us knowing who they are (e.g., if Sarah Anonymous can build modules, has submitted amazing fundamental PRs that have been merged, and successfully led teams of OpenMRS devs at her implementation, then couldn’t she be a /dev/5 even if we haven’t yet met her?).

3 Likes
7

I strongly agree. This is more objective when it comes to dev stage upgrade, we may need to look into this direction as well

I often notice that when an upgrade proposal is made, most of the respondents if not ALL will throw flowers to the geek even when they may not know much about the individuals technical skill advancement simply because community contributors are spread around different squads and so one may not know the progress of others in squads that he or she is not actively involved.

From the time have been in the community have never seen a public rejection on an upgrade proposal though I think there could be members in the community who may not consent with the proposal but because of privacy they just ignore making the response on the post.

IMO upgrade proposal is more realistic when its raised by a dev/3 or higher of the squad members working with the geek than someone else who has not been tracking the geek’s progress. This does not override the second option of someone initiating the proposal him/herself. For me I feel rewarding for someone else to recognize that my skill set does not align with my dev stage and he/she initiate the proposal to the stage the skill set aligns.

Though our @dev stages follow a pattern of @dev/null → @dev/1 → @dev/2 → @dev/3 → @dev/4 → @dev/5 But I realized that this may not be true to some geeks. Because one may not have been recognized for upgrade proposal since there might not be community developer meetings specifically for this and as time goes by the geek advances his/her skill set to that higher than the dev level next to him/her. Such advancement could also be looked into than just following the sequence dev pattern. I have seen such of this kind with @ibacher’s upgrade before he advanced to a Guru level.

Following upgrade episode very well in our community, have discovered that its one of the silent motivating factor to our contributors and as well encourages new members to strife to advance in their skill set.

8

Thanks to @k.joseph @dkayiwa @hadijah315 @christine @grace and @ibacher, we’ve been making improvements to the list of skills & experiences - for the Dev stages, for new QA stages, for OMRS stages, and for PM stages. The Fellowship Program is driving some of this, since having these more defined skill expectations helps mentors and fellows set goals for their fellowship and figure out what to focus on each month. That said, it’s still very much a WIP - the dev stages in particular have a lot of areas identified without skills or expectations, simply because we’re working on making the area competencies clearer.

Anyone is welcome to help us work on these improvements is more than welcome to join us - usually during our Mentor Office Hours on Thursdays at 5pm UTC.

1 Like
9

+1 consent with you on this and am glad you and @burke have come out to shade more light on the dev stages of which I don’t know if it’s clearly explained in the dev stages page. If not how are we going to make this clear to the community members to help them feel it’s not all about what is on the activity sheet but also community involvement is paramount.

Does it mean one has to acquire all the listed skills in a given developer stage to be promoted to another developer level and if not at which percentage should one consider to be fit for the dev stage?

10

I added @jwnasambu’s comments on this post over here because this is related to our stage upgrade process.

This is a great question! And one that I think we might have touched on while working through the dev stage improvements. I seem to recall talking about distinguishing between foundational dev skills, frontend dev skills, and backend dev skills. @k.joseph and @dkayiwa?

We do need to figure out a way for people to use the skill/expectation worksheet (or something else) to track their skill acquirement easily. I’ve been watching what Google’s been doing with their Tech Dev Guide - and earlier this week, I saw some interesting ways of using Jira to do something similar.

11

sure we did and were thinking about growing both frontend and backend separately in our staging whiles able to consider a frontend/backend dev/5 so in their sphere

12

Bringing over Dmitri’s response to Willa’s upgrade to /dev/5, since he brings up some great points:

@mksd makes an important point here. While we have criteria for stages, perhaps we should include milestones as well. While we have moved metrics of community engagement to om.rs/stages, it’s reasonable to expect that some milestones would include contributions to the community.

Given that we have a variety of areas where developers can contribute (at least backend & frontend) and ambiguous criteria are unhelpful (the more concrete, the better), we may need to express criteria with (roughly) equivalent frontend & backend examples. For example, something like “can write a Hibernate interceptor OR can create a new patient dashboard feature.”

To @mksd’s point, some milestones like “Has reviewed n PRs” and "“Has successfully submitted n PRs to community repositories” might be worth considering.

1 Like