Updating and expanding our Developer Stages

Development
1

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?

4 Likes
2

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
3

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
4

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 ??

3 Likes
5

sure , makes sense

6

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
7

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

1 Like
8

Unlimited :slight_smile:

2 Likes
9

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

https://wiki.openmrs.org/display/RES/How+Developer+Stages+Work

@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

10

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

11

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.

12

@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

4 Likes
13

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
14

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:

1 Like
15

The spreadsheet looks comprehensive enough to me, though it would be good to add a column for “past experience =” that tells where a developer has used a particular skill or applied his knowledge for that field =.

1 Like
16

As I was looking over the learning objectives for Google’s Technical Writing One and Technical Writing Two courses, two questions came to mind:

  • What kinds of technical writing skills do we think OpenMRS developers should have?
  • Should this be an independant “track,” or are there any core technical writing skills that should definitely be a part of our dev or omrs levels?

I’d love to hear what everyone thinks.

@burke @dkayiwa @grace @gracebish @herbert24 @ssmusoke @k.joseph @ibacher @ayesh @rainbow @madhens

17

FWIW – while it’s easy to use them interchangeably, we specifically chose the term “stages” for dev stages and avoided the term “levels” to focus on the personal journey and self-improvement rather than implying hierarchy.

“Levels” imply competition and hierarchy image     image

“Stages” imply growth and self-improvement image     image

These are typical roles in an organization and reflect responsibility. I would avoid conflating this with dev stages, which focus on self-achievement. While we might first look amongst /dev/4s and /dev/5s for leaders (because of their technical skillsets), someone could be a /dev/5 (based on achievements & skills) yet have no responsibilities.

I agree with this approach (though, technically, our dev stages start with /dev/null, since nobody expects output from /dev/null). That’s why, when our devs asked that dev stags –initially built to encourage engagement – focus only on dev skills/criteria, I moved the engagement criteria into a draft of omrs stages for this very purpose. That is, someone might be /omrs/5 (a leader in the community) while /qa/2 (knows a little of QA) and a /dev/null (hears “Java” and thinks of coffee).

All that said, I still think we have work to do to make dev stages more objective. Ideally, each stage would have enough criteria/examples that multiple people assessing the same person against those criteria would independently come up with the same stage. The more objective we can be, the fairer we can be and the more people can rely on people at a given stage having expected skills.

1 Like
18

@burke I think the key is for one to be an /omrs/5, /dev/3, /qa/1, /infra/4 and they can choose to decide what they want to identify with more since there are different needs along their journeys

IMO keep the stages at 5, but add variations, keep them controlled basically not more than 5

1 Like
19

This article had some interesting points on integrating documentation into the development process. I don’t know which of its suggestions would be the most feasible, but it’s certainly some food for thought. At the very least, we could think about some baseline technical documentation skills for devs, and ‘embedding’ trained tech writers with developers.

2 Likes
20

@madhens, I’ve been asking myself a similar question: what basic technical writing expectations or competencies should developers have? How can the learning objectives from Google’s Technical Writing courses help us think through those expectations?

1 Like