brainglobe
Search…
Governance model
How decisions are made within BrainGlobe

Aims

The aim of this page is to outline how decisions are made within the BrainGlobe project. BrainGlobe is intended as a community project, and so anyone with an interest in these tools can contribute.
The governance model exists to establish a streamlined and effective decision making process to guide future developments.

Individual roles and responsibilities

Interested users fall into (at least) one of three groups, with different levels of responsibility for the project:

Users and contributors

Anybody with an interest any part of the BrainGlobe project can contribute to the project in ways such as:
  • Filing issues on the GitHub page of the relevant repository
  • Submitting a pull request on the GitHub page of the relevant repository
  • Asking or answering questions on the Gitter channels
  • Reviewing pull requests
  • Discussing the project in open issues, pull requests, or any other channel
These users may contribute in any way they see fit with no responsibilities other than to follow the code of conduct of the individual repository.

Core developers

Core developers are a group of users who take responsibility for the development and maintenance of the "core" BrainGlobe repositories. Core repositories refer to those that many other BrainGlobe tools rely upon (e.g. the Atlas API). These developers will have additional rights to the repository (e.g. merge pull requests) and will vote on any changes to the project. The list of core developers is currently as follows:
Any interested party can join the core developers, based on the informal criteria of "a substantial contribution to BrainGlobe core repositories". Election will require a simple vote of existing core developers.
Core developers are expected to aim to contribute regularly to the code bases (e.g. comments, issues, pull requests), attend as many meetings as possible, and vote upon any major changes to the project.

Non-core developers

The BrainGlobe GitHub organisation includes many so called "non-core" software packages. These packages (e.g. cellfinder or brainrender) are in some way compatible with each other, and likely rely on some of the core BrainGlobe repositories.
These repositories are collected together for discoverability, and to create an informal community of developers that work together to create interoperable tools.
If you would like your tool to become part of BrainGlobe, please start a new topic on the BrainGlobe admin GitHub Discussions page.
Anyone can request that their tool becomes part of the BrainGlobe organisation, but the administration of these repositories will be the responsibility of the original developer(s), and not the BrainGlobe core developers.
The developers of non-core repositories have no formal responsibilities, but we would encourage communication with other BrainGlobe developers, and efforts to ensure compatibility and interoperability with other BrainGlobe tools as far as possible.

Steering committee

There exists a group of developers, separate to the core developers that exists for long-term decisions (e.g. funding acquisition) and if the core developers cannot reach a majority decision in any case. New members can be added based on a simple vote by the steering committee, based on the criteria of “substantial contributions to a number of BrainGlobe tools over a long period of time (e.g. > 1yr)”. It is expected that the vast majority of decisions are made by the core developers, and not by the steering committee. The steering committee is currently as follows:
The steering committee are usually expected to be core developers, and additionally discuss and vote upon the long-term direction of the project.
N.B. This governance model takes inspiration from the Napari model.
Last modified 2mo ago