Jupyter Notebook Team Compass

This page contains links to the notes from team meetings with the Jupyter Notebook community. For more some more technical information and links to various Jupyter Notebook repositories, see the Team Compass README.

Team Compass Resources

The following pages contain information about the Jupyter Notebook team, resources for community members, and team practices for governance and planning.

Current team members

This page lists (alphabetically) the officially named Jupyter Notebook Team.

Active members

Active team members are actively participating in the development, maintenance, planning, and discussion around projects in the Jupyter Notebook Github organization.

Damián Avila UMSI and 2i2c	Eric Charles Datalayer, Quansight, Anaconda	Sylvain Corlay QuantStack	Afshin Darian QuantStack
Eric Gentry Anaconda	Kevin Goldsmith Anaconda	Brian Granger Amazon Web Services	Andrii Ieroshenko Amazon Web Services
Paul Ivanov Noteable	Isabela Presedo-Floyd Quansight Labs	Rosio Reyes Anaconda	Zach Sailer Apple
Steve Silvester MongoDB	Jeremy Tuloup Quantstack

Inactive members

Inactive team members are (temporarily or not) pausing their active participation in the Jupyter Notebook community. They can reactivate themselves at any point in the future; it does not require a nomination by a current active member.

Software Steering Council Representative

Each official subproject in Jupyter gets a single Software Steering Council Representative. Jupyter Notebook’s representative is elected by the active team members. This representative should be re-elected every year (i.e. in January).

(Jupyter Notebook’s representative hasn’t been nominated yet).

Becoming a team member

Team member responsibilities

Active team members actively carry out the responsibilities listed in the Membership Guide Page.

Active and inactive membership

There are two types of team members, active and inactive.

Active members:

• Must be nominated by a current team member.

• Can be elected as the Software Steering Council representative for Jupyter Notebook.

• Get a vote in a voting situation.

• Count towards quorum in a voting situation.

• Are expected to participate in a majority of the team votes.

• Can nominate new team members.

• Should actively participate, either synchronously or asynchronously, in team meetings.

Inactive members:

• Were previously an active team member.

• Do not vote.

• Are not counted towards voting quorum.

• Can “reactivate” at any time by expressing their change in status publicly.

Team members can freely pass between active and inactive at any time. They should publicly state their status change in a pull request that updates the contributors.yaml file with their status change.

This means an inactive team member can “reactivate” themselves at any time by publicly stating their change in status. This does not require a nomination from another team member.

For example, a team member who is going out on a long leave/vacation (>2 weeks) can temporarily move to the inactive team during their absence and immediately reactivate upon return. This isn’t required, but this can relieve them from having to watch this repository for any formal votes that happen during their absence.

Nominating a new member

For someone to become a team member, they should already be a consistent, positive, productive member of the community. Newcomers are encouraged to become team members after they’ve shown a sustained interest in engaging with the community. Moreover, team members should be interested in continuing their engagement over a long-ish period of time (at least one year), generally putting in more time and effort than non-team members. This doesn’t have to mean contributing code - it can be assisting others in forums/issues, reviewing pull requests, participating in team meetings, etc.

Any new team members must be nominated and championed by an active team member. This process takes the following steps:

1. The champion should first discuss internally with team members to ensure that there’s general consensus before officially starting the process.

2. If there seems to be team consensus, the champion contacts the potential new team member and asks if they are interested. Don’t forget to run them by the Membership guidelines page to make sure they understand what they’re signing up for. If so, then move to the next step.

3. The champion opens a new issue in the team compass repository. The issue should state your support of the new team member, discuss why you think they are great and why they should join the team.

4. This issue should stay open for around 7 days to give members of the team a chance to weigh in their thoughts (and support!).

5. If there are no objections that haven’t been resolved, the new team member is welcomed into the community as an official team member!

Membership Maintenance

Every six months, one currently active member should open an issue in the team-compass repo asking all currently active team members to reply if they still consider themselves active. If not (or no response is given by a team member), it will be assumed that they have gone inactive. This will help keep the active team up-to-date.

Remember, an inactive member can return at any time by simply changing their status on the team-compass page.

How decisions are made

The Jupyter Notebook team follows the “Decision Making” Guidelines described in the main Jupyter governance documents.

In short, we’ll first seek an informal consensus. If a clear consensus cannot be reached, an active team member can call for a vote. The voting process then follows the guidelines laid out by the Jupyter Governance model.

Team size

There is no limit to the size of the team. We follow the guidelines laid out by the broader Jupyter governance model which encourages a large, highly participatory decision body:

The new governance model and decision-making guide is designed to support large, highly participatory decision-making bodies. As such, even Subprojects that have a clear decision-making body today may wish to increase the size of that body to include more contributors.

Membership guidelines

This page holds resources for members of the Jupyter Notebook team. They’re meant to guide team members to be happy, productive members of the team!

What are the team resources?

There are a few resources that are particularly useful for team members. Here’s a quick list to get you started.

• The Jupyter Notebook Team Compass is a repository with lots of information about team-related things. It has development tips, information about team meetings, milestones and roadmaps, etc.

• The Jupyter Notebook Team Compass issues are where we often discuss specific, actionable things related to the team (e.g., discussing whether to change something in the team-compass repo).

General policy about communication channels

We are trying to organize our discussions in order to help both contributors and maintainers find and choose the right communication channels and have a positive experience.

In this respect, we are using:

1. GitHub issues for specific discussions related to changing a repository’s content (e.g. feature requests, bug reports).

2. The Discourse forum for general discussions, support questions, or just as a place where we can inspire each other.

How can I help?

As a member of the team, you are encouraged to continue helping in the same ways that you already have. Your contributions to documentation, code, etc are always welcome.

Don’t forget that, as a member of the team, you’re representing the community when you interact with people (online and offline). Try to keep a friendly, positive attitude, and be welcoming and helpful in bringing others into the community and answering their questions.

Are there any specific responsibilies?

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:

1. “Watch” the team compass repository so that you’re notified when team conversations are happening.

2. Stay up-to-date on team meetings. You can find a notes from previous meetings pinned at the top of the team-compass issues page.

3. Vote. Participate in at least 2/3 of votes happening in the team-compass repo. You should be automatically pinged on Github when a vote is called.

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

5. 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 approval than to self-merge.

When should I merge a pull request?

As a team member, you’re encouraged to help others contribute to the project by reviewing their code, guiding them towards making a contribution and improving it, and ultimately merging their contribution into the project.

Having merge rights is both a privilege and a responsibility - please be thoughtful when using it! To that extent, here are a few guidelines when deciding to merge things into one of our repositories:

• Use your best judgment. As a member of the Jupyter Notebook team, we trust your judgment, and we ask you to use your best judgment in deciding when to take an action.

• Make sure it’s quality code. We know this is somewhat subjective, but ensure that the code is well-organized and thoughtfully-written, that any new features are documented, and that it abides by best-practices in Python, JavaScript, etc.

• Make sure there are tests. We try not to merge any new features (or bugfixes!) without adding tests for them. It’s easy to consider something minor-enough that it doesn’t warrant a test, but try to avoid doing this! Adding tests usually only takes a moment, and our future selves will thank us for it later.

• Make sure there’s been enough time for discussion. We’re an open community with an inclusive decision-making process. This means that sometimes we need to slow down to make sure others have a chance to review and provide their thoughts on changes. There’s no hard rule for this, but try to make sure people have a chance to weigh in. Consider pinging people that you think might be interested in a question, and give it a few extra days before merging if you think a topic will be complex enough to warrant discussion.

• Don’t be afraid to merge! We know this is a bit counter-intuitive given what we just said, but don’t be afraid to merge new code. If you think a change is really complex or potentially controversial, give it some time, but for most changes it is fine to just go ahead and merge. Again, we trust your judgment, and we don’t want these guidelines to become a burden that slows down development.

Why have a Team Compass?

This repository helps the Jupyter Notebook team set a weekly course for project activity. Our overriding goal is continuous team and project improvement.

As projects and their growth evolve rapidly, the contents of this repo should aid us in setting project direction and adjusting the course as needed. The repo contains:

• team meeting agendas and archives

• direction and action plans

• communication and culture of respectful teamwork

• recognitions and team celebrations

We sail together

While we value each others individual strengths and contributions, we succeed or fail as a team. Whether taking corrective actions for a bug or being recognized for good work, the team, instead of an individual, shoulders the burden and success.

Code of Conduct

The Jupyter Notebook community follows the broader Jupyter Community’s Code of Conduct.