What are Developer Stages for?

[Drafted this a while ago, finally deciding to click send.]

Continuing the discussion from The process of handling development stages needs a bit of work:

@burke, I wanted to raise an existential issue here on Leadership, outside of the other thread. First, I’ll copy in some relevant quotes, then get to my point:

So, @burke, it’s ultimately your decision as engineering lead on what you want developer stages to be. But I would suggest that communicating someone’s technical skillset as a developer/contributor to the OpenMRS Platform and Application(s) is the by far the biggest value. And gamification of the contribution/participation process is the thing that should be a nice side effect.

From “inside” recognizing people’s efforts and community engagement may seem like the most valuable. But from “outside”, our mission is to impact the world by building the best possible EMRs, etc, and implementing them in the best possible way. We (as the OpenMRS community) are in a unique position of being able to communicate people’s ability to build OpenMRS, and thus suitability for hiring by an implementer, etc. I think it’s a wasted opportunity if instead of communicating the real thing, we instead use dev stages to communicate how much someone participates.

My two cents, anyway.

1 Like

What I remember (and this may have changed since) the original primary rationale during Leadership Camp 2014 was to create more senior developers that could have more accountability (such as starting with code review) and responsibility/leadership to allow our engineering organization to grow.

Since there has been no significant increase in the number of people making engineering leadership decisions in the 19 months (!!) since, I assume maybe we should revisit/re-evaluate the purpose of the dev stages, and our needs.

1 Like

it may help to set aside x amount of time, see who is in the dev queue, and who may qualify for new stages. While i understand that there are ‘gates’ to get through, if no one gets through them, we need to assess what the problem is.

I tend to agree with Darius, though i dont think that Burke and Darius opinions need to conflict. We only need to reconcile them and try to move people through to new levels.

could we set a date/ time to figure this out?

Fair points. As @terry suggests, I don’t think we need to choose one or the other. I suppose I’m trying to push the engagement side because, as @michael pointed out, the original intent was to grow leadership/engagement.

While we have plenty of room for improvement, I don’t think it’s fair to say that we have had no significant increase in the number of people making engineering leadership decisions. We’ve had substantial collaborations & contributions to the platform over the past year, including Bahmni team leading a release of Platform 1.12. We also have gone from a handful of “full committers” and a long tail of ill-defined “partial committers” to having a dozen /dev/3 and /dev/4. The problems we’re having aren’t because of dev stages. In fact, having dev stages has helped focus the conversation and identify problems.

I think the problem is my lack of leadership skills. I need to get better at delegating. For example, we need to better define what we want & expect out of code reviews and then get more people capable of and doing them. I know this and I’ve tried expressing it in various ways over the past few years, but when nobody takes it & runs with it, I end up owning it and becoming a bottleneck. I think, instead, I need to facilitate the conversation and then delegate (assign) the tasks to others (e.g., person X to document expectations for code review, person Y to create metrics to measure how we’re doing, and person Z to ensure that we meet our goal in 6-12 months). Dev stages are another example. I try expressing what I think needs to happen and then, when nobody offers to help make those things happen (perhaps in large part because they don’t feel empowered or able to do so), I end up doing them myself. As it stands, I’ve gotten us relatively aligned between Talk & github, created a doc for the discussion, and just haven’t yet gotten to the last item on my todo list (sending out an invite to /dev/3, /dev/4, and /dev/5s for an initial dev stage review).

1 Like

Have we done the dev stage review yet?

1 Like

IMHO that should be at the bottom of the pile right now… it’s important sure but not as important as other things. Just my $0.02…

there are more pressing issues but this seems to get to the bottom of the queue all the time. Burke, if you want me to help you organize this, i will. I can help this… terry

@r0bby it might be the bottom of the list for you or I personally, but it isn’t the bottom of the list for those developers who have been following the rules we created for them to become a level up. They’ve been working very hard to do what we outlined, and they deserve our attention to respond to their hard work and reward them with what they’ve earned.

They won’t be of any use if the community dies. Which is exactly what I’m saying.

FYI – a posted a proposal for moving forward here and sent a message to all /dev/3s, /dev/4s, and /dev/5s linking to it.