Updating and expanding our Developer Stages

The need to update and expand our Developer Stages has come up more times than I can count.

This month, we’re kicking off our Fellowship program and one of the first steps is for Fellow Mentors and Fellows to develop an individual learning plan. For those that want to use the fellowship as a way to advance through the dev levels, having an up-to-date set will be a great resource! And hopefully it will make it easier for anyone in the community wondering what it takes to become a /dev/4 or a /dev/5 to figure out how to get there.

What resources can we work with?

The 2017 Q1 Brainstorming Dev Stages spreadsheet that @burke shared with me a while back is a fantastic tool! It divides the dev stages into areas (Communty, Developer, Open Source, Tools) that are then broken down into skills (i.e: Tools >>>Bash, Git, JIRA, Maven, SDK) and then those skills are further broken down into what we expect developers at each level to be able to do.

How do we do this?

Here are three questions that you can help us answer, area by area:

Question/Task #1 (Row 2): Does this area capture the full set of skills that an OpenMRS developer needs? If not, what skills do we need to add?

Question/Task #2 (Rows 3-7): Which skill expectations need to be updated? What would you change or add to bring them up-to-date?

Question/Task #3: Where skill expectations are missing, what skill expectations would you add?

For the skill expectations, we probably want to start by identifying the skill expectation for /dev/5 and then work through /dev/4, /dev/3, /dev/2, etc. Open Source>>Tickets shows a nice progression from /dev/1 to /dev/5. It reminds me of one of my go-to resources for verbs that describe skill progression.

What do you think? How would you answer these questions?

2 Likes

I think the question for each skill is to ask “what would we expect a dev at this stage to be able to do that we would not expect at the previous stage?”

2 Likes

Just throwing this out there, I think the dev stages are great since they show a level of progression

IMO the areas are the different paths along the dev stages for a particular skillset which enables any person to advance along the paths through proficiency

if there is a need change the perfix, from dev to something else more relevant …

Organizations tend to have a path Junior (or no title) -> Senior -> Lead -> Principal -> Director/Vice President to show progression along the responsibility scale

2 Likes

The stages so far defined here are basically development centric , and any extra skillset is just an addition to the development ability , which explains the prefix ‘dev’/X

can we also probably define some other stages that are not development centric , more comprehensive and generic foccusing on areas like leadership , mentorship , management etc ??

2 Likes

sure , makes sense

And I am looking forward to updating the document once the decisions are made. How to advance to higher stages came up as an area of interest in the user survey for new developer documentation project.

1 Like

How many attempts can new developers have for the dev/1 quiz?

1 Like

Unlimited :slight_smile:

2 Likes

@rainbow I think we have a documented description of the process for advancing to the higher stages, which we need to re-visit and revive.

@ssmusoke, I like the idea of making it clear that /dev/ level X would position that dev for a lead role or a director role with a given organization. Within our community, would it be helpful for people to know that reaching /dev/2 or /dev/3 means that you could consider taking on a specific role in our community?

Could those descriptions also help us update the list of skills and expectations? I’m also curious to hear if there are any particular skills that anyone from the MF Squad and/or OCL for OpenMRS Squad think we should add. @bistenes @ball @grace

@jennifer I focus on principle, you can call it dev/qa/ux/implementor and then add a list of skills, but you will then find issues on where to “Box” those who have multiple skills, do you just focus on their primary skill that the community needs or what they want to focus on?

The idea is a progression model, and if you look at the dev stages, it focuses on responsibility not what code or area a person has achieved.

Leverage that but keep it simple…

So more like a matrix is what you are suggesting? Like you can be an OpenMRS Level 2 that means you have the ability to do XYZ (skills) and you have done ABC in the community (achieve), and your areas that you can apply your ability and achievements are in [x] Dev, [x] QA, [ ] UX, or [ ] implementation (those can be columns in the matrix.

@janflowers I am actually suggesting you can have multiple paths, Dev, QA, UX, Implementation, each of them with a 1 to 5

And you can be at any stage in one of the paths, up to you to decide which one to highlight

2 Likes

Developer stages were originally created to promote engagement. Once we started using them, developers asked that we focus on skills and remove engagement milestones. So, I moved engagement milestones into om.rs/stages so they could be (potentially) re-adopted in the future independently from dev stages.

While it would be great to have people claiming stages like /qa/3, /ux/2, /implemeter/4 alongside /dev/3 (not to mention having /omrs stages in use), I’d love to see our /dev stages applied more objectively and serving as an exemplar for others.

Personally, I like the idea of keeping /omrs stages focused on engagement (not technical skills). Trying to pull a matrix of skillsets into a single stage will likely make the /omrs stages ambiguous & uninterpretable. In other words, I’d think it’s easier to interpret /omrs/2 & /qa/5 (highly skilled QA with modest engagement in the community) or /omrs/5 & /dev/2 (a leader in the community who can help curate issues).

3 Likes

I really like this idea. I think from an outside organization trying to understand someone’s ability - it’s useful to know both the skill set they have per our criteria, as well as, their engagement in OpenMRS at large. From an OpenMRS perspective, it’s useful to know our community’s capacity to achieve certain goals - both, but separately, in terms of skills and engagement. :slight_smile: