Reviving the all-Jupyter community meetings

General
1

Hello Jovyans,

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. :slight_smile:

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:

  1. Developers (core or community) share their work. Use the video format to demo and screen-share their cool extension, feature, or sub-project.
  2. 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.
  3. 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:

Meeting Agenda:

  • The agenda is open and editable by anyone via HackMD.
  • Users/developers “sign-in” and add agenda items.
  • Two types of agenda items:
    1. Shout-outs/highlights that don’t require any discussion
    2. 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).

Video call:

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

What’s next?

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. :slight_smile:

I look forward to seeing you on March 26th!

4 Likes
2

I like the idea and suggested format!

One thing I’d change is the wording around demos by Jupyter core team members and others. I’d just call it “demos by people who work on things related to jupyter” so that there is no distinction during the meeting. The fact that part of the responsibility of being a core team member is to demo stuff is somehow an “internal” thing.

Should we add a comment/explainer to the shout-outs along the lines of “2min max, no questions or discussion. If you need more time make it a agenda item.”?

I think we should change the “who is it for” part to just be “anyone in the community” and/or rename it to “Jupyter community call”. “Jupyter team meeting” makes me think this is primarily a meeting for and by the team, not the community. I think that is what it used to be but now it feels like the intent is to focus more on the community as a whole.

6 Likes
3

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.

As a fair warning, one of the issues we had with previous meetings was number of attendees. It tends to become hard on bandwidth and some hardware.

I’d love for these meetings to also engage new contributors on non-technical things (a group to write a summary on discourse?).

I’d love to also get a 5 minute “how do I…”, and not necessary from core-dev.

Zach, do you have access to the Jupyter Twitter ? Do you want to send a pin a tweet that links to March26 agenda ?

1 Like
4

First off, I think it’s great that you all put time into thinking about this, thanks for getting the ball rolling!

I want to echo some thoughts others have brought up, and suggest that we stop trying to create a hard diving between “core” people and “the jupyter community”. I’d also suggest we replace the word “developer” with something else…maybe “contributor”. It should be clear somewhere what kind of work each person is contributing to Jupyter, but I think all kinds of contributions to Jupyter should be treated equally. Maybe @willingc has ideas for how to think about that kind of language?

For demos, I’d also love to see things from the broader community as well. If there’s one thing that @psychemedia’s newsletters taught me, it’s that there are people out there doing super cool things in the jupyter ecosystem that I never even knew about. We should be highlighting and supporting those people, and looking for ways to integrate them with the broader Jupyter community.

Perhaps we could have a public sign-up sheet that people can put their names on in an append-only fashion (aka, first come, first served). Then there is a hard-cut for how many people can talk about what they’re working on, and a hard time limit for how long they have to demo?

One final thing I’ll note - it isn’t clear to me that this will solve the original problem that it sounds like the first meetings were supposed to address: encouraging cross-talk between Jupyter teams in order to discuss technical challenges and blockers. How were you hoping to include this kind of material in there? And if not, it still seems like this kind of thing would be important to discuss somewhere, no?

5

Learner-level here,

I want to echo carreau in: “I’d love for these meetings to also engage new contributors on non-technical things (a group to write a summary on discourse?). I’d love to also get a 5 minute ‘how do I…’, and not necessary from core-dev.”

Also from carreau - please explain the challenges you describe: “It tends to become hard on bandwidth and some hardware.”
It may benefit the attendance to address this as we proceed.

If there can be circulated a requirements.txt or equivalent is would greatly help those who may need to navigate some of the dependencies. May I also suggest a format similar to a roaming conference where presenters introduce/advance some core topics/take Q&A - with a focus on real-world applications.

I would be interested in seeing choldgraf’s “public sign-up sheet” and would request or contribute to the following:

  1. Typeset an Active/Advanced Textbook: Markdown, LaTeX, D3.js, Matplotlib, Shiny R, HTML, ipywidgets, PDF, …
  2. Kernel Science - Best Practices in irkernel
  3. Virtual Environments and Jupyter
  4. “How to Manage My System/Python Settings So I Can Contribute Effectively” - We Were All There Once

Is there already a shared calendar that people can subscribe to who do not use some of the other services you describe?

Thanks, it’s great to read some ideas here.

6

Hey everyone,

FWIW I would love to attend these meetings :slight_smile:

2 Likes
7

A reminder that this call is happening next Tuesday.

Here’s some important info for the call:

  • We’ll meet at 9am PST (your timezone) on Zoom here.
  • The HackMD agenda is here.

Sign into the agenda if you’ll be there. Also, feel free to add a topic to the agenda list!

8

May I suggest to create a celendar reminder that people can subscribe to ? I believe @Ruv7should have access to the ProjectJupyter google calendar. You can also create an .ics file in websites like https://apps.marudot.com/

1 Like
9

Great points. I’ve updated the post and changed some language to be more community focused (removing the phrase “jupyter team”).

Totally. I didn’t think of that. Let’s see how this first call turns out. If it becomes a problem, we can cross that bridge for the next call?

I don’t think I have access to the Jupyter Twitter. Would you like to tweet out the meeting?

That’s actually my intention and goal for this meeting. This would become a platform for anyone to add their super cool Jupyter “thing” to the queue. This call can be a mechanism for anyone to advertise Jupyter related content/ideas.

I was thinking the HackMD file would be exactly that–a public sign-up sheet where people append their topic. This is open to all. We’ll work through that list during the call. If we run out of time, we’ll bump them to the next month?

You’re right. I don’t think this is the purpose of the call. We might need to find another mechanism to solve this issue. I think this call should remain more community focused. I think we need a separate call for developers to chat…

10

I’d try to decide before the meeting starts how far we will get in the list (maybe be conservative). I think the stress of preparing to say something to then learn you got bumped to next month is a turn off. Would be for me in any meeting that I don’t regularly attend.

11

I would opt for contributors and specifically define as any activity that benefits the projects, their use, or the community.

1 Like
12

These are great suggestions. Perhaps a 5 minute show and tell from a community member.

I spoke at UCSD last night and learned a bunch about how folks are using Jupyter on their campus which was really cool to hear.

13

I may have missed it, but did someone tweet from the ProjectJupyter account about the meeting tomorrow? (No access here but happy to tweet/retweet.)

14

cc @Zsailer and @carreau

15

Tweeted. @Zsailer should be able to tweet from https://tweetdeck.twitter.com/ and as @betatim seem so excited you know can tweet from ProjectJupyter as well…

1 Like
16

Cross-linking: I started All-Jupyter Community Calls as a place to post information about the upcoming and past calls.

3 Likes
17

Thinking about the purpose of these video calls…

I’ve been describing them as “monthly, virtual JupyterCons”.

The idea is:

  • anyone can attend (for free!)
  • anyone can present (as long as they add themselves to the agenda)
  • anyone can just sit in on the call.
  • topics should target a broad audience (not overly technical)
  • authors will present and end with a few minutes for questions

Something I didn’t expect–after the last call, many people stuck around on the call to introduce themselves. It was so cool!

4 Likes