Team structure and responsibilities#
This page describes the team structure that we use in the JupyterHub community, as well as how you can get involved.
Contribute and join đź’—
For more information about how you can contribute to the team, see our contribution guide.
Expectations of all team members#
We don’t want team membership to be a big burden (many of us have one or more other jobs too!) but there are a few things that you should do as a new team member:
“Watch” the team compass repository so that you’re notified when team conversations are happening.
Semi-regularly attend team meetings. You can find a calendar of upcoming meetings on the team meetings page.
Commit at least 6 months to team membership. 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!
Let us know if you’ll be unavailable or out of town for an extended period of time. It’s no problem if you need to focus on other things for a bit, but it’s helpful for the team to know who will be around. To do so, open an issue in the team-compass. If it’s something you’d rather not mention to the public then send an email to one of the team members letting them know, and they can communicate it to the others.
Foster open and inclusive discussion. As a team member, you are responsible for ensuring that conversation in our communities is positive and inclusive. Open public issues to discuss things with the team. Try to do most communication in public spaces where others can join, or report back to team members if important conversations happened offline. When creating issues, provide enough context so that others can understand and provide their input. Encourage feedback and input from others often, and be patient when merging code - it is almost better to wait a bit for an approve than to self-merge.
Our teams#
JupyterHub is organized into a few teams with varying levels of responsibility and expectations:
JupyterHub Contributors#
Comprised of any individuals that have made significant contributions to the project.
Expectations and responsibilities#
Abide by the Jupyter Code of Conduct.
Generally do what they can to support the project.
How to join#
Anybody that has made ongoing or significant contributions to the project is welcome to join the JupyterHub Contributors team.
Here are examples of things that may grant you Contributor status:
Provide helpful responses in several Forum topics, GitHub Issues, or Pull Requests
Provide Pull Request reviews that are productive and helpful
Make several small improvements to any of our repositories.
Make a significant improvement to any of our repositories.
Be an advocate for the JupyterHub project to others.
Contributors are added by Maintainers, who do so by adding a GitHub username to the jupyterhub-team team on GitHub.
Team size#
The Contributors team is very large and has no limit. Once you are a Contributor, you are always a Contributor. We encourage this group to be as large as possible.
Maintainers#
The maintainers are stewards and leaders of the JupyterHub community. They ensure that our repositories and collaborative spaces are healthy, inclusive, and productive.
Expectations and responsibilities#
Maintainers commit a larger part of their time stewarding our projects and doing the kinds of things that casual or infrequent contributors do not do. This may be focused on a subset of the JupyterHub organization (e.g., a specific repository or communication space).
For example:
Watch issues. Monitor and provide helpful responses to issues in one or more repositories.
Respond on the forum. Monitor the JupyterHub categoriy in our forum and provide helpful responses.
Guide the work of others. Provide helpful ideas and feedback so that others can make fast progress contributing to our projects.
Triage issues. Identify what needs to happen, loop in relevant team members for discussion, get issues to an actionable state, and close completed issues.
Mentor contributors. Share skills and knowledge, look for opportunities to let others earn and receive responsibility. Grow our tema.
Review pull requests. Look over the changes others propose in repositories, provide feedback that improves them, and invite others to join you.
Ensure healthy communication. Put extra effort into building a healthy, productive, friendly community dynamic amongst our community members.
Attend our meetings. Try to attend our Team Meetings whenever you can.
Maintainers generally have heightened privileges (e.g., “Moderator” privileges in a forum, or “Administrator” privileges on a repository). They also inherit all responsibilities from the JupyterHub Contributors team.
How to join#
Maintainers may be added by any other maintainer. To add a new maintainer, a current maintainer should recommend their addition via issues in our Team Compass, or via private communications channels. If there are no objections to adding a new maintainer, add them to our list of maintainers.
Team size#
There is no limit to the number of maintainers that may exist in the JupyterHub Project. We hope to have a large and growing pool of regularly-engaged maintainers.
Our goal is to have at least two maintainers for any project within the JupyterHub community.
Steering Council#
This group focuses more of their efforts on leadership and stewardship over the JupyterHub community, ensures its long-term impact and sustainability, and represents the JupyterHub community with the broader Jupyter community.
Expectations and responsibilities#
Represent our mission and values. The Steering Council is our most visible organizational body, and they should represent the JupyterHub community in a way that is collaborative and inclusive.
Advocate for the project’s mission. The Steering Council should identify opportunities that could advance the mission of the organization, such as forging partnerships, finding funding, or growing our community.
Steward team processes. The Steering Council should oversee the processes, systems, and norms that guide the community in general, and continuously improve them to align with our mission and values.
Provide tie-breaking authority. If we cannot reach consensus in a decision, the Steering Council has the decision-making authority to choose a path forward.
They also inherit all responsibilities from the JupyterHub Maintainers team.
How to join#
Steering Council members should have made exceptional contributions of a sustained period of time, and demonstrated interest in carrying out the extra expectations and responsibilities described here.
Steering Council members are elected by other Steering Council members following a similar process as the one described for Maintainers.
Team size#
There is no limit on the number of Steering Council members we may have, though we believe 5-10 people is a healthy number.
mybinder.org operations team#
This is a special team that is dedicated to operating and supporting the ongoing public service at mybinder.org. While all of our teams involve some kind of ongoing service work (e.g., responding to GitHub issues), we call out this one specifically because it involves an unusually large amount of service and operations work given the scale of the mybinder.org service.
Expectations and responsibilities#
Respond to incidents on
mybinder.org. If there are incidents that affect service reliability, this team should respond to improve them.Operate and improve Binder’s cloud infrastructure. This team should continuously seek to improve our cloud service to improve its reliability and functionality.
Coordinate with the Steering Council around funding. Binder’s cloud infrastructure is run with credits, and this team should surface upcoming credit issues to our Steering Council to define a path forward. They are not responsible for getting the funding, but ensuring that others know about any upcoming funding needs.
Particularly focus time on Binder’s technology. The mybinder.org operators should particularly focus their open source efforts on the projects listed on our team and tools page.
They also inherit all responsibilities from the JupyterHub Maintainers team, though are expected to spend relatively more time in ongoing service support and operations.
How to join#
The mybinder.org operators team generally consists of people with experience or interest in running cloud services on Kubernetes.
Any team member of this team may be added by any other team member, following a process similar to the one described in the Maintainers section above.
Team size#
There is no limit to the number of mybinder.org operations team members.
Team Lead#
The Team Lead is a role with impasse-breaking authority to make decisions if the team can not agree. This authority should be used exceedingly sparingly. The Team Lead is expected to grow team members so that they can pass on their position to them.
Expectations and responsibilities#
The team lead’s expectations do not differ significantly from those of the Steering Council, other than the assumption that they roughly dedicate more of their time and energy to the JupyterHub project’s mission.
In the event that the Steering Council cannot come to a consensus on a decision, the Team Lead has tie-breaking authority.
They also inherit all responsibilities from the JupyterHub Steering Council.
How to join#
If a new team lead must be elected, they are elected by the Steering Council through a majority vote.
Team size#
The Team Lead is held by a single person at a time, with no limit to their tenure.
Offboarding team members#
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.
For members of Maintainers, the Steering Council , and the mybinder.org operators, we ask that individuals commit themselves to at least ~6 months of team membership.
Declare yourself inactive#
If at any time a team member feels that they would like to take a break from active team membership, they’re can choose to be inactive by making a pull request to the JupyterHub team membership database.
Any team members that step down are considered “inactive”. This means they no longer commit to the responsibilities of their previous team, but they retain their JupyterHub Team Membership status for life.
We keep a record of any inactive team members for the team in which they previously served. This is both to recognize their contribution, and to have a reference in case they wish to become active again.
Return from a break#
Any Inactive team members may elect to re-join a team at any time. To do so, they should notify the other team members in our Team Compass, and add themselves to our team member list.
Removing team members#
If a team member violates the Jupyter Code of Conduct, they will be removed from team membership permanently (including from the JupyterHub Team in general).