formalising the turing way's governance (a two year review)

Note: I recently wrote this document about formalising working groups for governance with The Turing Way for a former colleague and friend Gracielle Higino’s lab meeting for her course Computational Biodiversity Science and Services (BIOS2). They were going through a similar process with their group, and while I wasn’t able to attend the meeting, I drafted a short summary of the process of creating working groups. In the time since, I’ve expanded it into this broader blog, expanded to account for the different stages of governance that I’ve gone through alongside The Turing Way community.

How have we formalised governance within The Turing Way?

Talk to anyone in the open source space (or really anyone who has experience with organisational governance, community organising, or management) and they’ll all say the same thing: governance is hard!

I thought I’d tell you a little bit about how I’ve tried to go about forming working groups with The Turing Way project, and formalised work within the project more broadly. I don’t want to pretend that this effort came from me alone – it absolutely was a team effort! These reflections primarily came from reflecting about some of the early work around working groups, specifically.

Maybe it’s the anthropologist in me, but beginning with what already existed in the community was a starting point I came back to again and again to help incubate our governance (which has changed a lot since these early days!). Beginning with formalisation, then iterating on the structures and processes that emerged from that helped us to work within the existing culture and structures (i.e. community calls) in the community that existed before I joined.

What I learned from these steps:

1. Don’t reinvent the wheel, but also don’t be afraid to be inventive: Reviewing the existing material about governance structures more broadly brought me to all sorts of different examples from radically different places: from the Kubernetes to the Zapatistas, from corporate governance structures to grassroots community organising, to fellow open source communities. Reviewing all these different types really helped our team to see trends in their underlying structure, but they also helped us as a team to establish what we needed, what we could discard, and ultimately, what we might need to create.
2. Develop templates early on, but let them evolve as they interact with the real world: As you might have seen in the development of our governance, we often incubated structures (such as working groups) without necessarily developing templates to build off or get started with. While the intention behind this was to observe and support what emerged from these incubated structures, this often could default to the tyranny of structurelessness unless active support was given. If we could do it all over again, I would begin with more templated structures that could be tracked as they developed in real time.
3. Develop rigorous ways of receiving and acting on feedback: When incubating these structures, gathering feedback happened in informal calls as well as in broader community calls. At the time, both types helped us to gather feedback on community structures regularly with psychological safety in mind for community members and volunteers. However, in retrospect, we could have developed structures to do this more regularly and clearly with established questions. But I also suppose that we didn’t know at the time the types of questions that needed to be asked to receive more specific feedback. This is definitely a learning experience about monitoring and evaluation in real time, and developing more rigorous methods that have already been developed by others. However, there’s another lesson here about who is able to act on what, and where authority lies, another governance question that remained a “chicken and egg” debate within our community.
4. Document regularly, document often, but most importantly, document in a communication format that makes sense (however imperfect): After the public community research process, the documentation for these past few years of governance work within The Turing Way became more ad-hoc. Our documentation lives in a couple of different places as we have shifted our underlying infrastructure, and I also learned about the different types of documentation that The Turing Way contains in its guides. Condensing all of this into a narrative format that makes sense required navigating these different archives, and translating them into a consistent format. While presentation slides are often a format that is used within our community calls to report-out key information, not translating this information to other formats has come much later (such as a template for our community handbook and/or one pagers such as this one). 
5. Governance is embedded in culture, but it can also translate into very specific practices: Coming from anthropology and sociology, I was used to defining any social phenomena as expressions of a culture that were always context-dependent, governance included. And while this is true, and enables a more holistic understanding of the term, it doesn’t necessarily equip you with the tools to explicitly support governance as it is understood bureaucratically within an organisation. I’ve learned that the following at least need to be defined in order for governance to be developed: rituals (community calls or meetings), power (decision-making matrices), communication (both intra-community and externally-facing), and documentation (minutes, notes, summaries, reports, templates).
6. Establish expectations and plan for longer timelines, always: The beginning of community research revealed many learnings about the project that in many ways, still apply today. While the early community research and audit process surfaced many questions quickly (in just a couple of months - if not weeks), developing the structures to address these questions, concerns, desires, and dreams simply takes time. It always takes more time than you expect. Planning for this kind of timeline could have set expectations of more sustainability across the community and within our own delivery team.
7. Moving at the speed of trust is difficult, but an imperative: Maybe this is a catch all for “everything happened the way that it meant to”. In many ways, as we navigated the uncertainty of trying to recognise, reward, and support all the different types of work across the project, it’s important to know that all of these practices were being done alongside folks who were also adjusting and learning to trust both us and the process. Community work will always require moving at the speed of trust, or else it’s an imposition of will – or even worse, a hammer trying to find a nail.