Community Roles and Decision Making

jennifer · July 15, 2019, 2:23pm

At OpenMRS, we embrace and celebrate the work that small teams or groups do in our community because it’s become a proven way for us to solve problems together. Over the next few months, we’re very likely to get to a point where some of the innovative work currently being done by a small group or team will be ready to move to the next stage. Given the wider implications for the community and the teams’ work, we’ll have some decisions to make about how the community proceeds.

This is already starting to happen to some degree with Microfrontends, OpenMRS Flow, and migration. As a result, the past few Strategy discussions have raised excellent questions and generated a number of ideas around our decision making model and the relationship between the community and small groups/squads.

It’s time to move the conversation about decision making to the next stage. By figuring out and trying some adjustments to our decision making and governance model that allows our model to work more smoothly at scale, we’ll be in a better position to support and work more quickly with small teams when they need us.

What happens next?

Let’s build off of the questions and points raised during recent discussions to put together some cohesive proposals for community conventions that we can discuss and improve together.

I’ll kick this effort off by posting a series of proposals on Talk over the next several weeks. Each one will have it’s own Talk thread and we can use the #strategy-and-operations Slack channel to chat or ask questions about any aspect of a proposal.

How can you contribute to these conventions?

These are not going to be perfect by any means and I expect that they will include some things some people agree with and disagree with. Feel free to read them over and point out what you like, what you don’t, what you think is missing, and/or what you think needs to be beefed up, toned down, or tossed out. Your ideas, perspectives, and feedback will lead to better conventions that reflect our community’s values.

If you’d like to be more actively involved and help determine when each proposal is “good enough” for us to try out over the next 3-4 months, let me know! Several people, including @paul, @burke, @jdick, @wanyee, and @c.antwi, have already voiced their willingness to help in this way.

Want more context or background?

Here are some of the questions that have come up during recent Strategy discussions:

As the work of small and nimble teams like the Microfrontend Squad advances, how do they move from working on something that’s experimental to something that is accepted and adopted by the larger community?
When small groups or squads working on a project are trying to make a decision about something that has implications for the wider community, how do they proceed in a timely way, while remaining open to input from the community?
If the squad has decision-making authority over their scope, does this change when a squad or team is working on something that has wider implications for the community? If so, when does that shift happen, and who then makes the decision?
How do we move something that a team or squad is working on into core? What is this process?

If you want to know more about the discussion and how these questions came up, I encourage you to listen to the recordings or look over the notes.

https://notes.openmrs.org/2019-06-27-Strategy-and-Operations-Call

https://notes.openmrs.org/2019-07-11-Strategy-and-Operations-Call

dkayiwa · July 17, 2019, 8:39pm

A JIRA ticket is created, pull request raised, reviewed by the community, and once approved, it can be merged by any /dev4 or /dev/5

janflowers · July 19, 2019, 8:02pm

@dkayiwa you are right, that is the process for specific code contributions. But I think the larger question is how do we determine the influence and authority to include code/ideas/components into the technical roadmap or core code from a squad. What we don’t want to have happen is a squad formed, a bunch of interesting work done, and then have it not included/rejected for any number of reasons for inclusion into the OpenMRS products. That would be disheartening and demotivating for members, or innovative squads. So that’s where that question comes from I think… it’s a slight shift in how we do things, and not a bad shift in my opinion.

gschmidt · July 23, 2019, 4:42am

Hi, I started this piece a few weeks ago,

It’s inspired a lot by

the experience of the current work of microfrontend Squad,
The Lean Startup book
and in particular the last few Leadership & Strategy calls where @paul has encouraged the community to explore ways to move from single threaded decision making to multi-threaded decision making

My hope is this proposal will help enable innovation within a larger open-source community. Balancing the need for autonomous teams with final code merges to core.

Any feedback on this would be helpful

@jdick @joeldenning

jslawinski · July 23, 2019, 7:50am

@maciej FYI

akanter · July 23, 2019, 6:18pm

This is a very important discussion, and I appreciate all the contributions on the calls, and in the talk thread, especially Greg’s discussion document. Full disclosure that I come at this from a more traditional software company perspective and have a historical bias towards making OpenMRS a more reliable partner to governments, implementers and organizations who want to use the platform. I think there is a technical discussion to be had about how best to rapidly innovate and build stuff. There is a separate discussion about how to integrate that innovation back into the product/community. There is a third discussion about governance, oversight and accountability (to the community, donors, partners, etc.).

I don’t think this discussion has touched on the third topic at all, and that seems like an oversight which might need to be weaved in later. I would like the Strategy and Operations team to be able to take on specific deliverables with certain expectations for timeline, quality, etc. The team/squad work described in the first discussion is well and good, but these efforts might not be self-generated, nor independent of expectations for deliverables, etc. I’d like us to find a model which is robust enough to handle both of these situations.

My first reaction is that there does need to be some sort of institutional memory which can be captured in the Senior Technical committee mentioned by Greg. That group needs to be aware of all the responsibilities that the OpenMRS Inc and Community have, and understand technical and political reasons for prior decisions and their impact on current decision-making.

It also seems that the integration process and decision-making would need to take into account how much community involvement there was in the squad work. Teams that have had a lot of transparency and input from the community and the senior technical committee wouldn’t need to jump through many hoops to get the work integrated. Other teams that did not have those advantages would be required to do more to show that the work was compatible with the technical plan, strategy, deliverables, etc. before it could be merged/integrated. This would also incentivize teams to be more open and more collaborative with the advisors/technical team/community so as to prevent a large challenge at the end.

I do believe that the S&O team needs to make the overarching strategy/deliverables/direction clearly transparent to all (so there are no surprises) and that the process and criteria for acceptance are also clearly known for the teams to work with.

Just a few comments to add to the discussion

jennifer · July 23, 2019, 9:12pm

@gschmidt, thanks for sharing! Clearly, we’ve all been thinking about these questions from multiple angles and this is exactly the kind of information-sharing and discussion that will lead to better conventions. With that in mind, I hope that you will take a look at CC#1: Decision Making Playbook. How well does it reflect the points about decision making that you include in your blog? Are there others that you would like to see integrated into it?

@akanter, I really like how you tease out the three separate and key discussion topics. I think the second one (integrating innovation back into the product/community) is similar to what @janflowers was getting at and I’ve added it to this list of ideas for community conventions.

The convention on decision-making is only one piece of the larger governance puzzle, and we’ll work through the other major pieces through additional conventions. For instance, a convention around our structure and related roles/responsibilities will be the next piece. Different aspects of communication, participation, and incentives/motivation could be woven into these and we may decide that some deserve their own convention.

gschmidt · July 24, 2019, 1:22pm

@Jennifer, yes I think the Decision Making Playbook your posted highlights many good ways to encourage groups to discuss what they are working on and seek input from the community.

My blogpost was more focused on a process to demonstrate how an autonomous team could operate within the community, and provide a clear structure for this

@akanter - yes, I agree that level of transparency during dev process may influence speed of the final merge. What did you envision by the idea, "I would like the Strategy and Operations team to be able to take on specific deliverables with certain expectations for timeline, quality, etc."

akanter · July 24, 2019, 3:13pm

There is some history here that goes fairly far back. One of the perspectives raised was that OpenMRS was not as effective in actual implementation as it could be (as compared to say, DHIS2). The leadership team at the time highlighted the ability of the Inc. to engage in actual contractual relationships supporting implementations (both requiring development and implementation support). My thought was that it WAS a good idea for OpenMRS Inc to enter into these sorts of relationships and that therefore there would be both income and expense related to specific deliverables. We had once discussed that the S&O meetings would include representation from those specific project teams to ensure that there was: 1) commitment and oversight of those deliverables, 2) integration of deliverables with OpenMRS roadmap and 3) alignment with overall OpenMRS strategy.

joeldenning · July 25, 2019, 4:04am

I missed this thread until just now, here are some thoughts.

I think the OpenMRS community is unusual / distinctive when compared with other open source communities for the following reasons:

There is no core team of developers working on OpenMRS. Which is highly unusual for a project with such longevity and # of users.
Open source software projects usually have a much more clearly defined scope. “Vue is a UI framework,” “webpack is a bundler”, “Python is a programming language.” But the size and scope of OpenMRS is very much up for interpretation. You can fill in the blank with a lot of answers: “OpenMRS is a _____”
Open source projects usually provide tools for developers, not features for end-users. A reason for this is that no single end-user feature can satisfy all groups using the open source project.

I view these things as fundamental challenges that make Community Roles and Decision Making very difficult. No core devs + no clear scope + try to do something that can’t satisfy everyone = dysfunction, frustration, and glacial progress.

I think it’s remarkable that OpenMRS has thrived under these conditions and applaud the efforts of everyone who has made it happen. In my opinion, making the squads-oriented approach work for OpenMRS requires addressing those three issues directly.

jennifer · September 5, 2019, 12:50am

@joeldenning, these are insightful comments and some of them have come up before. They have also been coming up during several Strategy discussions this year. I’ve been trying to keep the notes from those discussions up to date each week - and looking back on them, there are some clearer themes and points that come out. Here’s a summary:

The decision making playbook and a community structure that uses it will become more meaningful when we have a clearer scope and more technical direction
Mobilizing and advocating for resources can be done more effectively when we have greater insight into what work is being done - and what is on our medium and long term roadmap
It’s easier to fundraise, advocate for, and allocate resources when we have a plan for sustaining them over the long term

Having decision making guidelines and some additional community governance in place will enable us to arrive at a clear scope/roadmap, prioritize current community projects, and mobilize community resources - in a way that is community driven and responds to actual needs on the ground. It doesn’t have to be perfect, simply enough to get us to a point where we can begin working through these issues.

We’re getting closer to concrete action:

Squads/teams are going to continue to form and have the potential to contribute valuable work to the community
If we’re interested in integrating their work so it’s available to the larger community, there needs to be some way to provide squads or teams with technical guidance when they seek it - and in providing that guidance, we can help assure the quality of what is produced.
There is also value in having a vision for the product that helps everyone see how the work they are doing aligns with it. Check out some of the great torch and lighthouse metaphors in the notes.
Some of this can be accomplished by forming a Technical Steering Group/Committee/Board that includes domain experts and representatives from different implementations, regions/countries, and distributions.
@burke and @c.antwi agreed to work on criteria for the kind of community members should be a part of this group and think about potential members. If you have ideas, feel free to share them!
Those in the Technical Steering Group are not necessarily the ones who coordinate and follow the work that different squads or individuals are doing. This could be done by a community management or coordination group, such as the one @wanyee has been thinking about.

This is an active discussion, so everyone’s feedback, comments, and questions are timely and welcome!

Relevant notes + recordings for quick(er) reference:

https://notes.openmrs.org/2019-08-01-Strategy-and-Operations-Call

https://notes.openmrs.org/2019-08-08-Strategy-and-Operations-Call

https://notes.openmrs.org/2019-08-22-Strategy-and-Operations-Call

ssmusoke · September 5, 2019, 5:41am

Thank you for putting this so clearly.

Actually this is a new situation as the community has lost 4 core devs in 2017/18 timeframe, so this new circumstance is one which has to be remedied quickly otherwise the progress will start speeding up in the reverse direction.

My addition with this will be the same, all structures cannot work unless there is a core development team moving the platform forward at a sustained pace. This pace and direction drives decision making to support the implementations, which do not have the resources and capacity to work on “unsexy but necessary” features and functionality.

As an implementor supporting a country wide rollout current platform has started to atrophy at a growing rate, there is no guidance or support available to handle the challenges that our constituents need, so the team spends more time that necessary on what should be core features.

I am hoping that the leadership can hear this call, and act accordingly to reverse the trend

wanyee · September 5, 2019, 12:44pm

Thanks a lot Jen for this succinct summary. I might miss today’s meeting as I’ll be driving back from deep in the field.

I’ll ping you we catch up.

jennifer · September 11, 2019, 2:23pm

Part of building and maintaining OpenMRS technical products means clearly defining what we are building and how we are building it. Innovative work on microfrontends and OpenMRS Flow continues, new releases of the Ref App and Platform are coming soon, and as @ssmusoke puts so well, we know we have “unsexy but necessary” work to be done to reduce our technical debt. This is the time to define what is next for our technical products - for the short term and beyond. Having a clearer scope enables us to plan for, mobilize, and allocate scarce resources in such a way that complements implementation’s contributions.

As a community, we know that we work faster and go farther when small groups work together on a clear and specific scope. We also know that we are too large to rely on 2 or 3 people to provide our community with the technical guidance many would like.

With that in mind, and with thanks to the insightful questions and suggestions from @paul, @terry, @burke, @jdick, @janflowers, @dkayiwa, @wanyee, @gschmidt, @c.antwi, @akanter @lober, and others, we will set up two, small teams with decision making authority over 1) what we build and 2) how we build our technical products. Specifically:

The Product Change Committee will:

Gather and provide the Product Change Lead with input on priorities from OpenMRS implementations and partners
Set short, medium, and long term product goals
Review, vet, and prioritize community technical projects

The Technical Committee will:

Define overall technical and system architecture.
Review and vet technical priorities and projects for technical feasibility and viability
Maintain the technical roadmap
Set community technical standards for code quality, contributions, and performance

As always, anyone in the community will be welcome to contribute to the discussions of either committee and we expect each to follow our community conventions around decision making. At the same time, we want to recognize the expertise of respected contributors from implementations and local communities - and intentionally involve them to determine what we build and how. Both committees will have up to 5 core members with decision making authority.

To ensure that these two teams work together effectively, a Product Change Lead and a Technical Lead will oversee and manage their respective committees - and will be accountable to the Project Lead. In addition to the Product Change Lead and the Technical Lead, OpenMRS QA Lead/Technical Product Managers will provide ongoing support to each committee. The full Terms of Reference for these committees and their leads is available here. The diagram below will give you an idea of how these two committees will fit into our software development process.

What’s next?

We’re going to try this out for the next three months and start with the following:

Over the next two weeks, we’ll identify2-3 interim, core members for each committee and an interim Technical Lead. If you have ideas or recommendations, please feel free to share!
Each committee will have an initial meeting to review their TOR, come to agreement on their scope for the next three months, and make some decisions about how they want to work.
At OMRS19, we’ll take a look at how this model has worked, improve on it, and then recruit and confirm committee members for the 2020-2022 period.

As we put this conversation about governance of our technical products on hold during this interim period, we can move forward with the ideas laid out in What would an OpenMRS Fellowship Program look like? and consider different approaches to mobilizing resources.