The emerging governance structure of movement

Niko Sirmpilatze

2025-10-23

Contents

  • The context: what is movement?

  • Examining current governance

  • Challenges to address

Sainsbury Wellcome Centre (SWC)

 

 

 

 

 

sainsburywellcome.org

Neuroinformatics Unit (NIU)

A research software engineering (RSE) team… dedicated to the development of high quality, accurate, robust, easy to use and maintainable open-source software for neuroscience and machine learning.

neuroinformatics.dev

Tracking animals in videos

Source: sleap.ai

movement overview

movement.neuroinformatics.dev

Who is involved in movement?

movement size and growth

~60k downloads (PyPI + conda-forge)

26 code contributors, 50% from outside UCL

~300 merged pull requests

Public forum hosts 82 members across 53 threads

movement.neuroinformatics.dev

Existing elements of governance

  • License: BSD-3-Clause
  • Code of Conduct: Contributor Covenant v3.0
  • Community page, including:
    • People—leadership, collaborators, contributors
    • How to contribute
    • Statements of mission, scope, design principles
    • Public communication channels

Motivations for more formal governance

Governance is the formalisation of implicit norms and culture in order to scale collaboration.

Source: “Governance for Software Engineers”, by Tobie Langel

Pitfalls to avoid

  • Avoid excessive bureaucracy: make process the backup plan, not the default.
  • Don’t define governance too early, let community dynamics emerge first.
  • Avoid aspirational governance—spell out existing norms; do not invent new ones.

What are our existing norms?

Looking through the lens of Ostrom’s three levels of governance:

  1. Operational: the day-to-day, who has merge rights, who owns the server, who updates the social media? Whose weekends get ruined when something breaks?
  2. Collective: what we normally think of as governance, who is in charge and how decisions are made.
  3. Constitutional: the meta level, who decides who decides.

Operational level

Task Who has the rights? Who does it?
Approving PRs Maintainers Maintainers
Triaging issues Maintainers Maintainers
Releases Maintainers Mostly Niko
Community Calls Maintainers Mostly Niko
Social media Adam Adam
Conferences Adam, Maintainers, Collaborators Mostly Niko
Moderation and COC enforcement Adam & Maintainers Mostly Adam

Collective level

For major decisions, such as roadmaps, feature prioritisation, and design changes:

  • Collaborators and contributors are often consulted.
  • Maintainers decide by Consensus.
  • Head engineer (Adam) has the final say in case of deadlocks (rarely happens).

Constitutional level

  • Niko to draft a governance proposal for movement, incorporating Birdaro’s training.
  • Maintainers and Adam to provide feedback, iterating until consensus.
  • Collaborators and contributors may also be consulted.
  • Final approval may be required from SWC senior leadership.
  • The governance document to be published and periodically reviewed.

Challenges to think about (1)

How do we prevent separation between the Neuroinformatics Unit and the wider community?

  • Enforce strict adherence to open communication channels.
  • Create a pathway for external contributors to become maintainers.

Challenges to think about (2)

How do we scale the consensus-based decision-making process as the number of maintainers increases?

  • Gradually move towards a Circles model.
  • Formalise procedures for failures to reach consensus:
    • Introduce voting mechanisms for major decisions.
    • Acknowledge the Head Engineer’s role as a tiebreaker.

Challenges to think about (3)

What if SWC completely changes course on movement?

  • Prepare a succession plan to make movement independent of SWC, if needed.