Governance#
movement is currently led by the Neuroinformatics Unit
(NIU), a Research Software Engineering team based at the
Sainsbury Wellcome Centre and the
Gatsby Computational Neuroscience Unit.
That said, movement is very much a community effort, and we’re grateful to
everyone who helps move it forward.
The roles below describe the different ways people can take part and the repository privileges that comes with each role. To see who currently fills them, head over to the People page.
Roles#
Contributors#
If you’ve opened a pull request, filed an issue, or joined a discussion through
any of our community channels,
you’re a contributor, and every bit of help counts.
Our contributing guide is the place to start.
We strongly believe that contributions directly help us achieve our mission.
The more people get involved, the more robust and versatile movement becomes.
Contributors bring fresh perspectives, ensuring that the software serves a broader
and more diverse community of users. Beyond technical improvements,
contributions help us build trust, foster shared ownership,
make the project more sustainable, and strengthen the wider ecosystem of
open-source tools for behavioural analysis.
Everyone who contributes to the GitHub repository—whether through code or documentation—gets
credited on the People page. Once your first pull request is merged, a
scheduled monthly workflow will add you to that page, and you’ll also get a mention in
the release notes for that version of movement.
Some people contribute in ways that don’t involve the repository, e.g. by providing
sample data. We add those contributors to the People page manually, so please
let us know if you think we’ve missed you.
Team members#
Also known as members of the movement development team,
these are people who have made several contributions to the project and
take on a more active role in its development and maintenance.
Team members are welcome to help with a range of tasks, including:
Keeping the issue tracker and pull requests tidy and welcoming.
Participating in discussions on Zulip and attending community calls.
Reviewing pull requests—especially in parts of the codebase they are familiar with.
On GitHub, this role comes with Write access. We trust our members to use that judiciously: merging straightforward changes, particularly in areas they know well, while seeking input from maintainers for larger or more contentious decisions.
There’s no expected time commitment and no quota to meet.
Joining the team also comes with a promise from us maintainers:
we will mentor and guide you as you grow into the role.
Some people take on this role for a fixed period—for instance while doing an
internship with us,
or while working on movement as part of a collaboration.
For some contributors, this role is a stepping stone to becoming a maintainer.
For others, it is simply a rewarding place to make a lasting contribution.
Both are entirely fine—the role is a valued destination in its own right,
and there is no expectation that you continue beyond it.
Note
This role is inspired by napari’s Triage team,
whose thoughtful approach to community maintenance we’ve adapted to fit movement.
Maintainers#
Maintainers are the stewards of movement, responsible
for the project’s long-term direction and health.
The role’s name matches the Maintain access it comes with on GitHub,
but you may also see the same group referred to as core developers
or core team.
Beyond everything a team member can do, maintainers perform the following tasks:
Make decisions about the project’s scope and roadmap, and prioritise features and bug fixes. Our community actively shapes these decisions, but maintainers make the final call.
Manage the repository itself, including merging pull requests and making releases.
Foster the community by moderating conversations on GitHub and Zulip, organising community calls, and posting on social media;
Publicly represent the project in talks, workshops, and other events. That said, we welcome anyone in our community publicising
movementin their own way, and we provide a list of Resources to help you do so.
Administrative access to the GitHub repository, the movement package on PyPI,
and our Zulip chat is reserved for maintainers only.
Typically, administrative rights will be held by the
head of the NIU
and at least one other maintainer, to ensure continuity in case of absence.
Decision-making#
Most day-to-day decisions are made by lazy consensus among the maintainers. Approval from one maintainer is enough to merge most pull requests. We only escalate to the full team for matters that affect the project’s core architecture, scope, roadmap, or governance.
For these more consequential decisions, we discuss publicly on our community channels, and consult all team members and the wider community for input. We aim to reach a consensus among maintainers. In the rare cases we can’t, the head of the NIU has the final say and responsibility to decide for the project.
Joining and stepping down#
Growing the team is something we take joy in. New team members are nominated by an existing maintainer, usually after a stretch of thoughtful, reliable contributions. A nomination is approved by consensus among the maintainers, who are thereby committing to mentor new team members as they grow into the role.
A team member who takes on more work over time could be well-suited to
become a maintainer, should they want to, through the very same process.
There is also an alternative path to becoming a maintainer:
being a member of the NIU who is assigned to develop and maintain movement
as part of their job.
Life changes, and so does the time we can give to a project—so you’re welcome to step back at any point by simply letting us know. These roles reflect active involvement, not a lasting obligation, and stepping away carries no consequences. The door stays open if you’d like to return.
In the unlikely case that a maintainer or team member has not exercised their role in any way for longer than three months, the active maintainers will reach out to check in, and may decide to to revoke or downgrade their access rights, depending on the circumstances.
Governance model changes#
Governance model changes occur through a GitHub pull request that updates this document. The pull request is marked for review by all maintainers and is merged as soon as they all approve, or after two weeks if no objections are raised.