# Binder Project Governance

The following sections describe governance and high-level principles surrounding the Binder Project.

### Project mission
The mission of the Binder Project is to create, advance, and promote open technology that makes it easy for people to connect their data science communication, education, and scientific reproducibility work with computational environments which can run their work.

The Binder Project pursues this mission by advancing the tools surrounding BinderHub, an open-source tool for hosting ad-hoc environments in the cloud. The project also serves as the primary maintainer of `mybinder.org`, a public service and demonstration of the BinderHub technology.

### Membership
Membership in the Binder Project is open to anyone who is nominated by an existing member. Members form the trusted group of individuals who manage the Binder Project.

Membership comes with [privileges](https://hackmd.io/UYG1jAM9TO-bqm9yNdXyYA?both#Team-privileges) and [responsibilities](https://hackmd.io/UYG1jAM9TO-bqm9yNdXyYA?both#Team-expectations).

Currently, the Binder Project team overlaps 100% with [the BinderHub team](https://jupyterhub-team-compass.readthedocs.io/en/latest/team.html#binder-team). However, these two groups may diverge in their membership over time.

A list of members and their roles will be maintained at XXX. This list is authoratative.

### Team privileges
* recognition
* team members can speak for the project in public
* merge privileges on the project repositories
* red members can nominate other individuals to team membership

### Team responsibilities
Each member of the Binder Project team is expected to spend a "reasonable" (intentionally vague) amount of time contributing to the technology used by Project Binder as well as maintaining `mybinder.org`. This might mean contributing features, making patches, responding to issues, reviewing PRs, teaching about BinderHub, making organizational connections, welcoming new contributors, or evangelizing and helping others deploy BinderHub. They should be receptive to comments and ideas on the GitHub issues or in the Binder gitter channel. They should strive to make project decisions that reflect these community opinions.

This list is non-complete.

### Team roles
* Team leader. This is a person who has impasse-breaking authority to make decisions if we can't agree on something. This authority should be used exceedingly sparingly. Currently, @minrk serves this role.
* Red member. You spend a large part of your time coordinating and promoting the Binder Project as well as the service at `mybinder.org`. You are expected to coordinate your actions with other red members so that the project presents a coherent position towards the outside. You are expected to prepare and attend the monthly team calls. Being a red member is not a life sentence. We expect red members to teach and grow other members so that they can pass their responsibilities on to them. This encourages diversity, reduces burn-out and allows team members to shift their focus in reaction to changing life circumstances.
* Blue Member. This is where your journey starts. You spend a large part of your time facilitating contributions from others to the project (e.g. reviewing work, answering questions, maintaining project infrastructure). We expect blue members to teach and grow contributors that can become blue members. This encourages diversity of the team. After building a good understanding of the technology and social stucture of the project you can change to a red member by volunteering for tasks which a red member is expected to perform. After a while of doing so the team will ask if you want to become a red member and if you agree recognise you as such at a monthly team meeting.

There are no other specific roles, but we may revisit this in the future.

### How decisions are made
The Binder Project team will make decisions [as colleagues](https://en.wikipedia.org/wiki/Collegiality) and by attempting to reach consensus among team members. If this is not possible, then the team leader can use their power to make a decision.

### Team size
There is no limit to the size of the team.

There is no hard cap on the number of senior members that can exist, though this will be re-evaluate if the group becomes big enough to be unwieldy. We see the ideal number of senior members to be around 6-10 people.

### Modus operandi
All team business is conducted in public.