Binder Project Governance

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

The Binder Project is a member of Project Jupyter, which is a fiscally sponsored project of NumFocus, a US 501c3 non-profit.

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 communications, educational materials, and scientific work with computational environments where their work can be run and shared with others.

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 and responsibilities.

Currently, the Binder Project team overlaps 100% with the BinderHub team. However, these two groups may diverge in their membership over time.

The authoritative list of members and their roles (alphabetical sorting) can be found at the JupyterHub Team section.

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, diversifying the team, growing the community, creating an open project culture, evangelizing and helping others deploy BinderHub. They should be receptive to comments and ideas on the GitHub issues, in the Binder gitter channel, and on the discourse forum. They should strive to make project decisions that reflect these community opinions.

Team members are expected to keep themselves informed about issues and PRs on the team-compass repository. We use this repository for important discussions and decision making, sometimes with a timeframe of ~48h. One way to keep yourself informed is to “watch” (button in the top right corner of the GitHub UI). You are free to use other mechanisms that work for you.

Because we ask all team members to watch this repository, please be respectful of others’ time and attention, and try to keep conversations on-topic.

Team members are expected to pass on their authority and responsibility to others by creating a open, transparent and inclusive culture for users, team members, future team members and the community at large.

We ask that you can commit to the above responsibilities for at least 6 months when joining the team. Training and mentoring new team members is an investment by the existing team, hence team membership requires commitment from both sides. Beyond 6 months, if active team membership is no longer possible for you, you can always join the green team! See A note on team membership and growth over time.

This list is non-complete.

Team roles

  • Team leader. This is a person who has impasse-breaking authority to make decisions if the team can not agree. This authority should be used exceedingly sparingly. The team leader is expected to grow team members so that they can pass on their position to them.

  • 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.

  • Blue member. This is where the journey of a new team member 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). After building a good understanding of the technology and social structure of the project you can change to a red member by volunteering for tasks which a red member is expected to perform.

  • Green member. Your life situation has changed so that you prefer to (temporarily) not take on the rights and responsibilities of being an active member. You can return to active membership by resuming your community activities. Your return will be announced at the next monthly team meeting.

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

A note on team membership and growth over time

Being a team member is not a life sentence. We expect team members to teach and grow other members so that they can pass their organizational responsibilities on to them. This encourages us to increase diversity, reduce burn-out and allow team members to shift their focus in reaction to changing life circumstances.

We ask that team members commit themselves in ~6 month cycles for new team members, and for shorter cycles if you are transitioning from the green team. If at any time a team member feels that they would like to take a break from active team membership, they can choose to join the “green team” by making a pull request to the JupyterHub team membership or Binder team membership files.

How decisions are made

The Binder Project team will make decisions as colleagues and by attempting to reach consensus among team members (similar to a lazy consensus model that encourages active participation from team members). If this is not possible, then the team leader can use their power to make a decision.

There is currently no formal specification for this decision process.

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 red team members to be around 6-10 people.

Modus operandi

All team business is conducted in public.