How can community developers serve your needs better?

We created a Community Development Swim Lane a couple years ago to direct community development toward issues that matter most to implementations; however, the swim lane has devolved over time to simply tending the developer needs (i.e., improving the experience for new devs & ensuring their questions get answered) and is no longer directly serving implementations’ needs as initially intended. We discussed this in today’s project management call and would like to reset the development swim lane to more directly serve your needs.

Our proposal

The community development swim lane begins working from a “Community Development Swim Lane” list of prioritized tickets everyone can see (i.e., a community “backlog”). Any ticket within TRUNK or a bundled module marked “ready for work” is a candidate for the backlog; however, the goal would be to populate the backlog with those tickets that are the highest priority for implementers and keep it updated as priorities change.

Populating & prioritizing community development swim lane’s backlog

  • We use an “Implementing > Development Priority” subcategory here on OpenMRS Talk for discussing what should be added/removed/rearranged from the backlog. Any implementers in the community could use this forum to suggest a particularly bothersome ticket be placed in the backlog.

  • The Community Development Leader, with the help of implementers, watches this discussion along with votes on tickets & tickets marked as blockers, adapting the backlog as needed, and leads a brief review of the backlog in our weekly project management call.

Going forward, the Community Development Swim Lane would direct community development toward active projects and, when an active project didn’t fit the developer’s need, toward this backlog, reserving intro tickets for new devs with little available time or who are otherwise unable to join the swim lane.

Our goal is to create a culture where implementations needs are prioritized in community development and, most importantly, we are continually re-assessing and adjusting to needs & priorities as they change.

Any thoughts or suggestions on how to improve this process? We’ve previously tried using solely JIRA votes to guide priorities; however, that didn’t work out as well as we’d hoped. A “vote per implementation” might be another approach; however, we’d like to try a more fluid & discussion-based prioritization to see if it might be both more friendly and more productive.

Thanks for starting this conversation @burke. I think that we could definitely improve the communication between the engineering team and our customers (implementers, developers “in the field”, users, etc.) and these ideas would be a good start. It might also be helpful for the Community Development Leader to write up a similar regular summary of accomplishments and priorities, and share it with our implementers as well.

I also think there are probably some other great ideas out there for helping to ensure that our engineering contributors are working on the things that matter most to people using OpenMRS. Looking forward to hear from others!