I wanted to summarize some ideas shared during a recent discussion about the “all-Jupyter” community meetings. These meetings are intended to gather all Jupyter community members, across sub-organizations (for lack of a better word) and sub-projects, in a single video call.
The topic of discussion was: how can we repurpose the “all-Jupyter” video call to more effectively benefit the Jupyter team and community?
I’d like to use this thread to open the conversation to the community. My hope is that we converge on an enjoyable+productive format for future meetings.
I would break our dicussion today into 4 questions:
- What is the purpose of these calls?
- Who are we targeting?
- Who should attend?
- What should the format be?
In the rest of this post, I’ll share some ideas expressed in our meeting today.
A little background
In the past, Jupyter had a weekly all-Jupyter video call. The goal was to connect Jupyter team members once-a-week to discuss technical blocks and share updates in their daily development. This made sense when Jupyter was comprised of a handful of projects with similar goals. We’ve outgrown this format. The Jupyter ecosystem is now composed of various sub-organizations and many sub-projects. Sub-organizations began to grow, and Jupyter developers began working on vastly different projects.
As a result, attendance dwindled over time. This signalled that the meeting needed to be repurposed. There is a great benefit to getting all the Jupyter teams together (discussed below), but the old format wasn’t working. The goal of this post is to explore how we can effectively do this moving forward.
A major issue we’d like to address
There is often little cross-talk between Jupyter developers in sub-organizations and sub-projects. This isn’t personal; it’s one of the expected pains of being a large, open-source organization. I often find myself surprised by libraries, extensions, tools, etc. created by colleagues that I didn’t know about! While that’s a fun surprise, it can lead to each sub-organization re-inventing the wheel or worse, creating tools that do not work together (even though they are both from Jupyter devs!).
This also means that Jupyter users will likely miss important updates and cool features that could improve their Jupyter experience. Unfortunately, READMEs on Github are not the best way to learn of new projects. Even tweets with GIFs don’t always do it for me. Personally, I discovered more tools, extensions, and helpful hints from three days at JupyterCon than a year’s worth of tracking Github/Twitter. Sometimes, seeing a project demo’ed live from the core developer and having them answer questions in real-time is more effective at attracting users.
A (proposed) new meeting format
Here’s what I took away from our meeting today:
What is the purpose of these calls?
We discussed this meeting having a few main purposes:
- Developers (core or community) share their work. Use the video format to demo and screen-share their cool extension, feature, or sub-project.
- Users share how they’re using a Jupyter sub-project in some cool way. This could be highlighting a blog-post or screen-sharing their implementation of some Jupyter project.
- A member of the Jupyter steering council share any updates/announcements that the community should here.
More specific discussion about sub-organizations/sub-projects should happen in their own Team meetings separate from this all-Jupyter meeting (i.e. nteract, jupyterlab, and jupyterhub all have their own separate meetings).
Who are we targeting with these calls?
This call targets both Jupyter developers and users. Jupyter developers get to hear about other projects in the Jupyter ecosystem, offer technical feedback, and guard against problems that arise from a lack of communication. Jupyter users can hear about awesome things happening in the Jupyter ecosystem, ask questions in real-time, and share their experiences with the various sub-projects.
Who should attend these calls?
First, it’s absolutely critical that most of the core Jupyter developers participate in some capacity. Whether that’s preparing demos or speaking on the video call, having core developers attend demonstrates that we are invested in the team and the community.
After that, anyone and everyone is welcome! Whether it’s to present their work, engage in discussion, or just sit in and listen, everyone is welcome. This is a good chance for users to ask questions and meet other Jupyter people.
What should the format be?
We will likely need to iterate on the format. This thread is a good place to discuss and collection ideas for a format.
One initial idea is to follow a format similar to Jupyterhub/Binder meetings:
- The agenda is open and editable by anyone via HackMD.
- Users/developers “sign-in” and add agenda items.
- Two types of agenda items:
- Shout-outs/highlights that don’t require any discussion
- Demos showing a project, extension, etc. by screen sharing.
- Items can be added up-to 24 hours before the call.
- We’ll send out multiple reminders about agenda+meeting (a month before, a week before, and two days before) on Github, Gitter, Twitter, etc.
- We’ll organize the agenda items the day before the meeting.
- Notes/minutes will be added under each agenda item as the meeting is taking place.
- After the meeting ends, the moderator will publish the agenda+notes (somewhere… still up for discussion).
- Call once a month (last Tuesday each month).
- Call is recorded.
- Call moderator leads group through the agenda (I, Zach, will lead the first call).
- The moderator reads through the “shout-outs and highlights” section (no discussion to follow).
- The author of each agenda item leads its demo.
- A demo should be short (~5-7 minutes). Think of it as a “flash talk”. This isn’t meant to be a burden that requires tons of preparation.
- After each demo, the moderator opens the floor for questions/discussion.
- After all demos, a member of the steering council makes any further announcements/updates relevant to the whole team.
- Call ends, and moderator publishes it in the Jupyter YouTube channel.
I would also suggest we create a “team-compass” page (like Jupyterhub’s team-compass page), but that’s a separate discussion.
Our first meeting with this new format will be at 9am PST (your timezone) on Tuesday, March 26th, 2019.
I’ve created an initial agenda on HackMD.
Let’s use this discourse post to discuss. If anyone has an opinion or idea for these meetings, share them here. I just ask that we respect each other’s opinions and recognize that it’s extremely difficult to create a meeting that fits everyone’s goals. We’d love everyone’s participation (and patience) as we improve these team meetings.
I look forward to seeing you on March 26th!