Dear Community,
Since April, we’ve had a range of conversations around different aspects of a community process that will help us allocate and dedicate resources as well as raise funds and advocate with donors for budget to support collaboration on shared OpenMRS projects. We’re at a point where we need to consider how we as a community will, in a practical way, turn this process into action. Before we do that, I’d like to take a moment to a step back and remind ourselves how we arrived at this point.
As the community discussed our Amazing Future, I noticed several insightful comments about what people thought was needed to work together on a new web application framework. These suggestions focused on the need to commit, allocate, and dedicate resources for a team that included a PM, a QA, as well as developers; having a higher level committee to be in charge of overall architecture; identifying funding for the initial effort and future work on the architecture and application framework; and creating a mechanism to introduce funding into implementation budgets for core support and architectural re-design.
So what?
Our success continues to come from our core values: starting small and focused on solving a shared, real problem, being user-centered, open, transparent, and community-driven. What I appreciate most about the above comments around process and resourcing is that these are essentially suggestions for building on what worked well for us in the past. This doesn’t come as a surprise to me: when OpenMRS implementations moved from pilot implementations of 10-15 sites to national level implementations of 300-700 sites, processes evolved and improved in response. Similarly, we have grown beyond a community whose efforts were supported by a handful of organizations: in our 2018 Annual Report, we listed over 20 supporting organizations.
Recent shifts at the global and local levels will continue to bring new and exciting opportunities for our community:
- As more countries begin national scale implementations, more and more of the action is happening locally. This is reflected in both the call for more local community activities during OMRS18’s How Might We? brainstorming to the recent re-vitalization of Kenya’s OpenMRS community.
- Country leadership is taking a stronger interest in global goods - and actively reaching out to collaborate with open-source communities, including ours.
- Donors increasingly seek to align their investments in digital health as we can see by the recent Principles for Digital Investment.
These shifts underscore the need for us to effectively support collaboration and maximize the use of resources. Just as OpenMRS implementations evolved to work at scale, our community and our processes must also adapt and work effectively at scale.
The main process we’ve been working on for the past month or so picks up where Scrum of Scrums and Implementer’s Meetings currently leave off. The project resourcing process takes identified areas of collaboration or projects and makes them available in a highly visible list of “contribution opportunities” on high value and high impact, community projects. This is intended to make it easier for contributors and supporting organizations/implementations to a) identify what they want to work on, b) make decisions about committing to or allocating resources to a project, c) coordinate with others who want to work on the same project, and d) put together the team needed to produce a quality feature or product. This listing can also help donors align their investments and we can target our fundraising efforts to those projects in need of resources.
Now what?
We have enough of the process and prioritization criteria laid out to start using it, likely making improvements on the way. The question we have started to get into is: Who will take on the different steps in this process?
I decided to try to answer this question using the lens of our current governance structure for two reasons. One, I’d rather work through our existing bodies if we already have the mechanisms and structures in place to do this work. I see no need to add more bureaucracy if we don’t need it! Two, we also want to make sure that we have the right amount of structure so that we don’t put more work on an existing group that is already at capacity, creating bottlenecks.
Several points have become clear to me:
-
Some parts of the project resourcing process clearly fall within the current scope of three existing groups:
- The Strategy and Operations group is responsible for both reviewing community processes and for fundraising. They are well positioned to play a critical role in identifying funding opportunities and mobilizing resources for priority projects in need of funding.
- The Project Management group that meets on Mondays already keeps track of ongoing projects and supports projects as they progress.
- Many project teams/squads, such as the Sync 2.0 team and Microfrontend Squad, already put together project descriptions on the Wiki.
-
Both the Strategy and Operations group and the Project Management Team usually use all of their available meeting time each week - and there are usually a few agenda items that don’t get covered.
-
We passively identify projects in a variety of centralized places in our community (Scrum of Scrums, Implementer’s Meeting, Talk, word of mouth). Countries and implementations bring their priorities to these events or discussions.
-
Volunteer guides, TPM, Director of Community, and others have been connecting contributors/supporting organizations with projects when they know what projects are looking for and when those projects need help.
What can we do?
In order for our community to operate effectively while enhancing our ability to support community projects, I recommend that we form two working groups specifically to support key parts of this process.
Community Coordination Committee This group would be responsible for reviewing, vetting, prioritizing, and resourcing community projects.
We are user centered and community-driven. As such, I expect the community projects we support and help resource to 1) reflect country and/or local community priorities and 2) respond to implementation and user needs on the ground. This is more likely to happen when those reviewing and talking through community project proposals represent local communities, implementations, and countries. I recommend that we intentionally identify and invite local champions from key countries, and implementations, and regional OpenMRS communities to take on an active role on this committee.
Technical Advisory Committee: This group would review community project proposals from a technical perspective, assessing a project’s feasibility, identifying dependencies or duplication with other projects, etc. While anyone in the community could participate in this group, it would be ideal to see experienced and respected contributors with the technical expertise and familiarity with multiple OpenMRS distributions and implementations taking on an active role with this committee.
I see traces of this group coming together organically with the microfrontend project. We identified a few key people in the community with a strategic interest in the project and with technical experience with a variety of distributions to act as product owners. These product owners do not feel the need to be involved in either the day-to-day activities of a project squad or the project management team. By bringing respected contributors together as a Technical Advisory Committee, we make this expertise accessible to the wider community - and increase the likelihood that proposed projects can be used throughout the community.
To encourage both of these committees to take up this process, I recommend that we clearly document not only the purpose and responsibilities of each committee, but that we also identify and recommend specific individuals to form an active, core group - while keeping the door open to anyone in the community who wants to participate or follow both/either committee. I also recommend that the core group lay out and openly document their decision making process and determine how they will communicate, both synchronously and asynchronously.
This may seem to some as a lot of change. At the same time, I see signs of these working groups and the project resourcing process emerging in multiple places already, some of which I mentioned above. We are simply building on and naming what currently exists and what is beginning to happen. Naming what we’re doing gives our actions more intention and visibility, the decisions about the projects we support become more transparent, and we open ourselves up to an even more amazing future.
What’s Next
I welcome your comments and ideas, so I’m turning this over to the community for consideration and discussion for the next couple of weeks.
So many of you spur new ideas or expose me to a new way of looking at an issue almost every day. In many respects, this is already brings together ideas and thoughts coming from many of you as well as a number of sources identified by the community. For instance, I’ve taken some pages from @dkayiwa and become a better Talk and Wiki surfer. I’ve observed our routine meetings and Talk discussions, talked with many of you about working groups, how to make sure our contribution listing will truly reflect community priorities, how we channel information from local implementations, and more. Beyond that and in addition to drawing on my community of practice library, I’ve also spent considerable time looking at open source web sites and guides, including The Art of Community, Open Source Guides, and Producing Open Source Software.
All of this to say that I’m looking forward to hearing even more perspectives and exploring where we go from here. 2019 simply gets better and better for OpenMRS and for our community.
@paul @terry @janflowers @burke @wanyee @hamish @akanter @jdick @c.antwi @chris @mseaton @mogoodrich @gschmidt @ssmusoke