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