# Governance Model

## Abstract

The purpose of this document is to formalize the governance process used by the
`bioio` project, to clarify how decisions are made and how the various
elements of our community interact.

This is a consensus-based community project. Anyone with an interest in the
project can join the community, contribute to the project design, and
participate in the decision making process. This document describes how that
participation takes place, how to find consensus, and how deadlocks are
resolved.

## Roles And Responsibilities

### The Community

The bioio community consists of anyone using or working with the project
in any way.

### Contributors

A community member can become a contributor by interacting directly with the
project in concrete ways, such as:

- proposing a change to the code via a
  [GitHub pull request](https://github.com/bioio-devs/bioio/pulls);
- reporting issues on our
  [GitHub issues page](https://github.com/bioio-devs/bioio/issues);
- proposing a change to the documentation via a
  [GitHub pull request](https://github.com/bioio-devs/bioio/pulls);
- discussing the design of bioio on existing
  [issues](https://github.com/bioio-devs/bioio/issues) and / or
  [pull requests](https://github.com/bioio-devs/bioio/pulls);
- reviewing [open pull requests](https://github.com/bioio-devs/bioio/pulls)

among other possibilities. Any community member can become a contributor, and
all are encouraged to do so. By contributing to the project, community members
can directly help to shape its future.

Contributors are encouraged to read the [contributing guide](./CONTRIBUTING.md).

### Core developers

Core developers are community members that have demonstrated continued
commitment to the project through ongoing contributions. They
have shown they can be trusted to maintain bioio with care. Becoming a
core developer allows contributors to merge approved pull requests, cast votes
for and against merging a pull-request, and be involved in deciding major
changes to the API, and thereby more easily carry on with their project related
activities. Core developers appear as team members on our
[@bioio-devs/trusted-developers](https://github.com/orgs/bioio-devs/teams/trusted-developers)
GitHub team. Core developers are asked to review code contributions. New core
developers can be nominated by any existing core developer.

### Steering Council

The Steering Council (SC) members are core developers who have additional
responsibilities to ensure the smooth running of the project. SC members are
expected to participate in strategic planning, approve changes to the
governance model. The purpose of the SC is to ensure smooth progress from the big
picture perspective. Changes that impact the full project require analysis informed by
long experience with both the project and the larger ecosystem. When the core
developer community (including the SC members) fails to reach such a consensus
in a reasonable time-frame, the SC is the entity that resolves the issue.

The steering council is currently fixed to only include members directly from Allen
Institute for Cell Science. This may be changed in the future, but this results in the
steering council currently consisting of:

- [Eva Maxfield Brown](https://github.com/evamaxfield)
- [Daniel Toloudis](https://github.com/toloudis)

New members are added by nomination by a core developer. Nominees should have
demonstrated long-term, continued commitment to the project and its
[mission and values](./MISSION_AND_VALUES.md).

## Decision Making Process

Decisions about the future of the project are made through discussion with all
members of the community. All non-sensitive project management discussion takes
place on the [issue tracker](https://github.com/bioio-devs/bioio/issues).
Occasionally, sensitive discussion may occur through a private core developer channel.

Decisions should be made in accordance with the
[mission and values](./MISSION_AND_VALUES.md) of the bioio project.

bioio uses a “consensus seeking” process for making decisions. The group
tries to find a resolution that has no open objections among core developers.
Core developers are expected to distinguish between fundamental objections to a
proposal and minor perceived flaws that they can live with, and not hold up the
decision-making process for the latter.
