Jupyter Blog - community

What you told us: results from the 2026 Jupyter User Experience and Product Enhancement Survey

2026-08-25T13:42:00+00:00

From time to time, Jupyter runs user surveys to understand how our communities use Jupyter technology (or alternatives) and how they feel about it. The Jupyter Foundation recently completed a user experience survey for 2026. It was open between 29 May and 29 June 2026, with 542 people providing answers. This post covers what we found, what you can do today about the most common problems, and where we are looking for proposals.

Each of the areas below rose to the top of pain points that users consistently felt. We would love to see applications in the 2026 Call for Proposals that address any of these areas by improving Jupyter technology. In some areas, there are already Jupyter or third-party open-source tools that address some of the issues, and we list them as a guide to readers who want to learn more.

About the responses*: Three of the six questions were free text, and 246 people wrote something in at least one of them, some at considerable length. Writing several paragraphs about environment setup or version control at the end of a survey takes real time, and that detail shaped most of what follows. We want to extend our heartfelt appreciation to everyone who answered this survey, high-quality experience stories like this are crucial at shaping Jupyter’s priorities and technical direction.*

Who answered

Two thirds of respondents (65%) use Jupyter for data science and analysis, and 55% use it in education. Smaller groups deploy Jupyter for others (14%), develop extensions (14%), or contribute to the open-source project (12%). These add to more than 100% because the question accepted multiple answers. See the Appendix below for a deeper dive into the respondents and the tools they reported using. Below we’ll focus on the pain-points and themes that were commonly reported, since those are the most actionable for our community to improve upon and learn from.

Common themes that people raised

We reviewed all 677 free-text responses and coded the recurring themes, cross-checking the coding against the source responses.

Environment and dependency management, and version control and collaboration, are the two largest friction themes, and between them account for 51 of the 246 people who wrote to us, with 7 raising both. Other themes follow closely: interface and editor parity (17 people), handling large data sets and performance (15), documentation and discoverability (14), respondents who use a different tool instead (13), deployment and multi-user operations (12), and security, authentication and compliance (6).

When we asked what is blocking people from using Jupyter more, 130 of 239 answers named something concrete, while 53 said that nothing is blocking them, either in a sentence or as a one-word “no”. Limited time and competing priorities appear throughout those 53 responses.

The Foundation is committed to finding ways to address these pain points across our community, and we’ll be exploring other ways to make progress in these areas in the coming months.

Environment and dependency management

This was the largest friction theme, raised by 32 people across 51 responses.

The responses concentrate in three sub-problems:

Installation and first run, and package and dependency management, account for 17 responses each.
Environment and kernel registration accounts for 13
Reproducing an environment on a second machine for 4.

What connects them is that the failures arrive early and are hard to diagnose from the error message alone. For example: an installation completes but the jupyter command cannot be found; packages install into one environment while the notebook runs a kernel from another; a course needs the same environment on thirty machines that nobody administers centrally. Each of these has a known cause, and in many cases, a known fix, but users struggle to find the right solution to these problems.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also listed a few open-source tools from Project Jupyter and the third-party ecosystem that partially address these challenges.

Open-source tools that partially address this problem:

From Project Jupyter:

JupyterLab Desktop bundles Python and JupyterLab in a single installer and removes most first-run failures. v4.6.2 was released recently.
JupyterLite and Binder avoid per-machine installation entirely, which is often the right answer for teaching.
python -m jupyter lab works when a pip install succeeds but the entry point is not on your PATH. This is a common cause of “command not found” straight after a successful install.
repo2docker fetches a git repository and builds a container image based on the configuration — useful for creating reproducible images for use with Binder or JupyterHub
%pip install and %conda install run inside a notebook and install into the environment the running kernel is actually using, which is usually what goes wrong when installing from a terminal

From third-parties:

better package installation from UI
- gator creates and manages conda environments from the JupyterLab interface
- package-manager browses and installs Python packages without leaving the interface
kernel per environment which encodes “lockfile”
- pyproject-local-kernel provisions kernels per environment for the project the notebook file resides in
- pixi-kernel Per-directory Pixi environments with multi-language Jupyter kernels
notebook itself can include requirements
- juv is CLI tool that encodes dependencies in the notebook using PEP 723 (inline script metadata) and creates ephemeral virtual environments for kernel execution
- juvio also encodes dependencies in the notebook using PEP 723 but also includes bespoke integration with jupyter kernel spec manager and a JupyterLab extension
better integration with other environment management tools
- nb-conda-kernels and nb-nebi-kernels provision kernel specs auto-discovered from all conda and nebi-tracked pixi environments respectively
- jupyterlab-launchpad replaces the launcher with one that has first-class support for kernels discovered from conda and nebi-tracked pixi environments
- jupyterhub-fancy-profiles allows JupyterHub users to select a Binder-like environment and build it at hub launch time

Several respondents asked for closer integration between Jupyter and environment managers, including a graphical option for people who do not work at a command line, which is part of what those extensions provide. A consistent environment and kernel story across package managers and operating systems still requires sustained work across several projects, and we would welcome proposals in this area. Another area where future work is needed is preventing the drift between server and kernel environments (join the discussion).

Version control and collaboration

This theme was raised by 26 people across 33 responses.

Git diffing and merging accounts for 13 responses, real-time collaboration for 9, sharing and publishing for 8, and review and commenting for 3.

The underlying cause is that the notebook format stores code, outputs and execution metadata in a single JSON document. Tools built to compare source line by line report changes that are technically accurate and hard to read: re-executing a cell without editing it can produce a large diff, and merges conflict on execution counts and output data rather than on anything a person wrote (which can be desirable when reproducibility is the primary goal, but less so when prioritizing iterative development). Reviewing a colleague’s notebook therefore costs more than reviewing an equivalent script, which pushes teams either toward exporting notebooks to scripts before review, or toward skipping review.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also sourced a few recommended tools within Jupyter and from third-parties that partially address these challenges, and list them below for readers that want to learn more.

Open-source tools that partially address this problem:

From Project Jupyter:

nbdime provides content-aware diff and merge that understands cells and outputs. Running nbdime config-git --enable --global once makes git diff on a notebook readable.
jupyterlab-git brings Git operations into the JupyterLab interface and uses nbdime for diffs.
jupyter-collaboration brings real time collaboration; it allows several people to edit the same notebook simultaneously and time-travel to older versions.

Third-party:

Jupytext pairs a notebook with a .py or .md file that diffs and merges like an ordinary source, which makes notebook changes reviewable in a normal pull request.
nbstripout tools remove most merge conflicts for teams that do not need outputs in version control. The community has produced at least three variants: nbstripout, the original; nbstripout-fast, a faster alternative; and fastai-nbstripout (no longer maintained). They differ in behaviour and performance, so pin whichever you adopt. We read this fragmentation as a consequence of the gap, and a single well-supported answer would be a reasonable thing to propose.

Most of the tools above ship separately from JupyterLab and have to be installed and configured before they help, which limits how many people find them. We are considering both closer integration of these tools into the default experience and approaches that reduce the underlying problem, and we would welcome proposals for either.

Review and commenting on notebooks remains the clearest gap. Nothing in the current open-source stack provides a way to leave a comment on a cell and resolve it later; that also works for colleagues who do not use GitHub.

The interface, and parity with editors

Seventeen people wrote about the interface, and their requests are concrete rather than architectural: completion as you type, a variable explorer, working drag and drop, faster scrolling in long notebooks, and a more modern appearance.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also sourced a few recommended tools within Jupyter and from third-parties that partially address these challenges (including a few JupyterLab plugins that directly solve the problem), and list them below for readers that want to learn more.

Open-source tools that partially address this problem:

From Project Jupyter:

JupyterLab Desktop. The project went through a period with little activity, which some respondents referred to. It now has active maintainers and regular releases, and v4.6.2 was published after the survey closed.
Jupyter Notebook v7 now includes multiple improvements covering features requested by respondents, inheriting them from JupyterLab; after reviewing the survey answers we improved the documentation to mention the variable explorer available in the debugger (which has basic support, while the plugin below has more in-depth support) and the opt-in as-you-type autocompletion.
jupyterlab-lsp adds better completion, jump-to-definition, signature help and diagnostics.

Third-party: the variable explorer people asked for, plus several conveniences carried over from mainstream editors.

jupyterlab-variableInspector and variable-inspector both provide the variable explorer that came up more than once
jupyterlab-quickopen jumps to a file by name.
jupyterlab-unfold gives a tree-style file browser.
jupyterlab-code-formatter formats code cells.
jupyterlab-favorites pins frequently used directories.
jupyterlab-vim for vim users
jupyterlab-search-replace for search and replace across file

Thirteen respondents told us they use another tool instead: VS Code, Google Colab, Spyder or Positron, marimo, or plain Python scripts. We are glad that support for Jupyter notebooks and kernels has landed in many editors and has inspired other notebook-based applications. Maintaining an open ecosystem where people can move between the tools that suit their workflow matters to us. For reactive execution in particular, ipyflow brings dataflow-aware execution inside the JupyterLab interface.

Artificial Intelligence

Twenty-four of the 246 people who wrote free text mentioned AI. Of those, 14 asked for more AI capability in Jupyter, 1 asked for it with explicit caveats, 3 objected to AI being a priority, and 5 mentioned AI (e.g. as a use case) but did not take a stance.

Three requests recur:

Explanation at the point of failure. Clearer error messages and guidance for people who are learning, including one request for a “fix code” action placed directly below an error.
Working with self-hosted and third-party models. Support for running against “own LLM-servers”, compatibility with proxy layers, and simpler installation of Jupyter AI, which one respondent described as too complicated to set up.
Help with libraries, and checking generated code. Finding relevant packages within a research field, and being able to validate generated code before running it against real data.

The objections are about prioritisation, and specifically that AI work displaces maintenance and work on features aimed at human users.

Over the past twelve months the Foundation has facilitated several rounds of AI workshops and summits, and more are planned. Anyone is welcome regardless of their stance. Working out how the project should respond to increasing AI usage in data analysis and teaching needs both positions in the room. Proposals through the funding process are welcome here too.

Other themes

Here we list a few more themes that showed up in the survey responses along with some open-source tools that can help as of August 2026.

Theme	People	What might help today
Performance with large data	15	Recent versions of JupyterLab/Notebook improve UI performance. Large outputs freezing the browser can be prevented by using visualisation and tabulation libraries that make use of rasterization and canvas renderers (e.g. plotly, ipydatagrid or newcomers like xy). Third-party extensions streamline work with large dataset in dedicated big data formats (e.g. jupyterlab-h5web for HDF5, NeXus, ANNData, etc; Arbalister for Parquet, CSV, Avro, ORC, SQLite, Arrow IPC).
Documentation and discoverability	14	Jupyter documentation and Discourse. We are aware that changelogs and breaking-change notes are missing or inconsistent across subprojects, and this needs addressing.
Deployment and multi-user operations	12	The Littlest JupyterHub for single-server teaching and Zero to JupyterHub on Kubernetes. batchspawner for Slurm and HPC, systemdspawner for resource limits and sandboxing. Third-party: jupyterhub-usage-quotas and jupyterhub-cost-monitoring.
Security, authentication and compliance (including accessibility)	6	JupyterHub authenticators cover most institutional identity providers, and Zero to JupyterHub documents TLS and network configuration. jupyterlab-a11y-checker is a UC Berkeley CDSS extension for assisting authors of extensions. New versions of Jupyter software include notable accessibility improvements: JupyterLab, myst-theme
Teaching and grading	8	nbgrader for assignment distribution and autograding, usually alongside JupyterHub.
Execution model and cell state	8	In IPython `%load_ext autoreload` followed by `%autoreload 2` gives hot reload while developing a package against a live kernel. Third-party ipyflow brings reactive execution to Jupyter interfaces.
Publishing and export	7	`jupyter nbconvert --to webpdf` produces PDFs without a LaTeX installation. Jupyter Book for longer documents and Voilà for dashboards. Third-party: Quarto.
Mobile and tablet access	3	No good answer today. Recent work on lumino is addressing certain limitations.
Non-Python kernels	3	Maturity varies by language. Specific bugs are best filed on the relevant kernel’s issue tracker, where they can be followed up.
Excel and spreadsheet interop	3	JupyterLab opens CSV and TSV files in a data grid without any extension. Third-party: jupyterlab-spreadsheet-editor makes CSV and TSV files editable in place, and jupyterlab-spreadsheet opens Excel workbooks read-only.

Submit a proposal

Most of what people asked for needs sustained work rather than a configuration change. The Jupyter Foundation’s Community Funding Proposals process is open through the 9th of September, 2026. Proposals do not need to come from existing maintainers, and you can propose work without intending to be the person who carries it out.

Larger changes may warrant a new Jupyter Enhancement Proposal, or completing work on an existing one. Both are in scope for community funding, and are expected to involve support and consensus building in the community.

Thank you

Once again, thank you to the 542 people that offered their time and expertise to provide responses to our user survey. For those interested in the 2026 Call for Proposals, we’d love to see submissions that address these pain points. Keep an eye open for future surveys, as they have a big impact on where Jupyter improves its technology moving forward.

Appendix

Here is some more information about the survey respondents and the kinds of tools they used in general. We share it below in case it helps provide context for the analysis above.

The data, and how to read it

An anonymized version of the dataset is available at jupyter.org/surveys (repo here: github.com/jupyter/surveys), together with the analysis notebook that produced every figure in this post, including its caveats and the checks that did not work.

Analysing the questionnaire turned up several problems worth fixing before reusing the questions, and worth taking into account when re-analysing the data: a question that asked for a single primary answer while accepting several, a list that mixed applications with libraries and server components, and a question that asked two things at once.

Around 6% of this dataset shows clear quality problems, rising to roughly 11% under a stricter definition that also counts respondents who selected every available option. We even had two self-identified AI assistants fill in the survey. We re-ran the headline figures with those responses removed and none of the percentages moved by more than a point.

Product-use numbers

We asked participants to note the Jupyter tools that they use, and share the results below. A caveat for this data: we learned that many Jupyter users do not easily distinguish between the many different tools in the “Jupyter Stack”, and respondents often only chose one tool while many were likely in-use (e.g. only choosing “IPython” but not choosing “Jupyter Server”, which is almost always used alongside IPython). We’ll try to improve our methodology to tease this out more effectively in the future, but share the data below for others.

To understand whether the above question was skewed by the effect of mistakenly only responding with one selection, while many selections were more appropriate, we broke down the answers to the above question by whether the respondent also selected at least one other option. Of 542 respondents, 303 ticked exactly one box.

Nearly half of all IPython/ipykernel selections came from people who ticked nothing else, which suggests that some respondents ticked the single item they recognised rather than enumerating everything they use. For example, jupyter-server usage should be equal or greater to that of JupyterLab and Notebook (while alternative servers such as jupyverse exist, adoption of these would not explain the gap). We would treat these percentages as reflecting name recognition at least as much as adoption. Which products are used together holds up better: among the 239 people who ticked more than one, Binder, JupyterHub, Jupyter Server, Jupyter Book and ipywidgets form a clear cluster.

Usage patterns

Just over half (53%) use Jupyter daily for more than thirty minutes, 15% once a day for shorter sessions, 17% weekly, and 16% monthly or less. The sample leans heavily toward regular users. The survey was open for a month, with almost all responses arriving in the final nineteen days.

Congratulations, Distinguished Contributors!

2026-06-24T15:08:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2025 cohort of contributors.

Project Jupyter Distinguished Contributors are recognized for their substantial contributions to Jupyter itself in both quality and quantity over at least two years. Contributions may include code, code review, infrastructure work, mailing list and chat participation, community help/building, education and outreach, fundraising, branding, marketing, inclusion and diversity, UX design and research, etc.

Please congratulate the winners of the 2025 cohort of Jupyter Distinguished Contributors!

James Colliander

Florence Haudin

Greg Mooney

Kirstie Whitaker

Jupyter User Survey

2026-06-18T15:04:00+00:00

The Jupyter Foundation is excited to gather your feedback on the Jupyter user experience through a brief survey. If you had a magic wand, what would you change or add to Jupyter? Your insights are incredibly important as we continue to invest in making Jupyter better for everyone.

The survey takes only about 3 minutes to complete, and we highly encourage you to participate. The survey will close on Sunday, June 28th.

TAKE THE SURVEY

Thank you for your time, your input, and your continued support of the Jupyter ecosystem!

Becoming the new JupyterHub and Jupyter Book community manager

2026-06-15T07:01:00+00:00

There are moments in life when things, simply, converge. You work and study, study and work, and then, simply, it happens. It starts one day when somebody tells you “there is this new thing called Jupyter Notebook, you should give it a try!”. So you install it, play around with it. It works like a charm. It’s easy, fast, nearly playful. It’s beautiful–and if you grow up in Italy, beauty always matters. Then, you have the urge to tell others about it. You organize a workshop at a conference in musculoskeletal image analysis and introduce marvelous novel tools for computational research: “You know? Nowadays we can do open science easily because somebody has created Jupyter Notebook, Binder, new Python libraries!” And then, together with some friends, you write a proposal for a Jupyter Community Workshop, and–unbelievable!–you get it. Initially, you think you are just organizing a workshop. But somehow, the number of people interested becomes larger and larger, and you find yourself co-founding and coordinating what is now the Open and Reproducible Musculoskeletal Imaging Research (ORMIR) Community. In ORMIR’s Python packages, the examples are in Jupyter Notebook, the documentation is in Jupyter Book. Sooner or later, we will have our JupyterHubs too; it’s just a matter of time. In parallel, life gives you some professional challenges. So you start teaching Python online, one-to-one. You look for material that fits your style, but you cannot find any. So you start teaching it your way, using Jupyter Notebook in JupyterLab and it works. Students find it easy, independent of their background. The teaching material seems to work, so you transcribe it into a book entitled Learn Python with Jupyter, and you make it open. At the same time, you are obsessed with keeping up to date. You go to JupyterCon, meet the people, watch their YouTube videos, participate in online meetings. And then, there is a job posting for a community manager. And you are like: “Nah, they will never hire me”, so you set it aside. But then somebody out of the blue tells you to apply because “100% of lottery winners played!”. So you give it a chance, and here I am: my name is Serena Bonaretti and I am the new JupyterHub and Jupyter Book community manager!

In this new role, I am very much looking forward to working with the JupyterHub and Jupyter Book communities! I will collaborate with maintainers to understand and document projects’ priorities and define the best processes to achieve their vision. I will support contributors in finding their way into the projects and make the real-world impact that they hope to achieve. I will dialogue with users to make sure that the tools we create are useful for their work. And I will share our activities monthly and what we learn with anybody interested, so that we can all benefit from this journey!

And you? How did you start using the tools of the Jupyter ecosystem? Do you work in JupyterHub? Have you ever written a Jupyter Book? Would you like to be a contributor? Are you an enthusiastic user? Write me on Discord (Jupyter Book/MyST) or Zulip (JupyterHub). The JupyterHub and Jupyter Book communities and I are looking forward to getting to know you!

Our new Jupyter Foundation Community Manager

2026-05-18T20:01:00+00:00

The Jupyter Foundation is excited to announce that we have contracted with Jason Grout to be a part-time Jupyter Foundation Community Manager. The primary purpose of this role is to strengthen the Foundation and assist the Foundation and its members in providing value to Project Jupyter.

In the year and a half the Foundation has existed, it has funded a number of strategic initiatives, including JupyterCon 2025, a series of Jupyter Workshops, community development and capacity grants, and a strategic marketing effort. In that time, we’ve found that planning, delivering, and improving these initiatives is difficult without dedicated capacity and expertise.

With the capacity and experience provided by this role, we are excited to continue growing our connection with and value in the community. Jason has a long history of service to the Jupyter project, and has spent several years serving on Jupyter’s Executive Council and more recently on the Jupyter Foundation Board. We’re excited for the expertise, wisdom, and positive spirit that Jason will bring to this role.

This is a new role, and we’ll shape the responsibilities and key deliverables as we learn. In the meantime, keep an eye open for Jason across the community and alongside various initiatives that the board is excited to continue this year.

-RP

Jupyter Foundation Governing Board Chair

700 JupyterLab 4 Extensions!

2026-03-13T17:18:00+00:00

700 extensions for JupyterLab 4, and counting!

The JupyterLab extension ecosystem just crossed 700 extensions compatible with JupyterLab 4!

That’s 700 community-built plugins — from astronomical data viewers to reactive notebooks, from genome browsers to workflow managers — created by hundreds of developers, research labs, and companies around the world.

What Are JupyterLab Extensions?

Extensions are how JupyterLab becomes a Git client, a dashboard builder, a genomics viewer, or an AI workspace — without changing the core application. Install one with pip install, and it activates automatically.

Popular JupyterLab extensions

This is by design: JupyterLab itself is built as a collection of extensions — the file browser, the notebook editor, the terminal are all plugins. The same architecture that powers the core lets the community build what they need. For background, see 99 ways to extend the Jupyter ecosystem.

The Ecosystem at 700

700+ extensions compatible with JupyterLab 4
~960 total extensions published on PyPI
~9.8 million downloads/month
100M+ total downloads in the past year

By any measure, a substantial software layer has grown around JupyterLab.

How We Got Here

The ecosystem crossed 600 JL4-compatible extensions in late October 2025, days before JupyterCon in San Diego. At the conference, we ran a full-day Extension Development for Everyone tutorial with hands-on rapid prototyping. By early March 2026, we hit 700.

The ecosystem has been growing at a steady pace, averaging about 18 new extensions per month, with November 2025 setting an all-time monthly record of 33. Modern tooling is helping: better templates, documentation, and code generation tools have lowered the bar for what once required deep familiarity with TypeScript, Lumino, and JupyterLab internals.

Where the Extensions Are

Number of JupyterLab extensions by category

Monthly PyPI downloads by category

Development & Version Control dominates both in count (267) and downloads (5.4M/month). Visualization & Dashboards (2.7M/month) and System & Resource Management (602K/month) round out the top three most downloaded categories. But the fastest-growing categories point to where things are heading. Here’s what’s new in 2026:

JupyterLab’s AI Layer Starts Taking Shape

AI isn’t yet the biggest category in JupyterLab, but it may be the clearest signal of where new interaction patterns are emerging:

jupyter-ai-acp-client — Brings external AI agents into JupyterLab’s chat via the Agent Communication Protocol. Ships with Claude Code and Kiro personas.
nb-margin — Annotate cells with margin comments, and Claude Code edits them. A different paradigm from chat-based AI.
jupyterlite-ai-kernels — AI-powered kernels for JupyterLite, from Jeremy Tuloup. AI-assisted computation entirely in the browser.
jupyter-chat-components — Reusable chat UI components from Project Jupyter — building blocks for the next generation of AI tools.

These extensions reflect what the JupyterLab team identified as a 2026 priority: first-class integration with AI tooling.

Reproducibility Gets a Toolchain

calkit-python is the most downloaded new extension of 2026 (11,000+ monthly downloads). It gives notebooks project-scoped environments, graphical package management via Astral’s uv, and one-click notebook pipelines with freshness tracking. Think “Makefiles for notebooks” meets “Poetry for Jupyter.”

Calkit manages notebook pipelines with environment tracking and one-click reruns. The orange ‘run’ button signals stale outputs that need to be regenerated.

jupyter-projspec (from the fsspec contributors) takes a complementary approach — it brings projspec into JupyterLab, letting you scan and analyze project structures directly from the notebook environment.

jupyter-projspec integrates to system filebrowser to show the project metadata

Science

fitsview — Stream FITS astronomical data slices directly in JupyterLab without downloading full files.
jupyterlab-urdf-test — 3D robot model viewer/editor (URDF + Three.js), from jupyter-robotics.
climb-jupyter-igv— Integrative Genomics Viewer with S3 access for bioinformatics.
ggblab— GeoGebra interactive geometry with bidirectional Python communication. Second most downloaded new extension of 2026.

Accessibility

Accessibility has been a growing focus for JupyterLab core and extensions are starting to address it too:

jupyterlab-a11y-checker— From UC Berkeley’s DSEP infrastructure team, this extension scans notebooks for WCAG 2.1 AA issues: missing alt text, heading structure, table headers, color contrast, and link text. Guided fix interfaces, optional AI suggestions, and a CLI for CI pipelines. Over 11,000 total downloads and a documentation site.
jupyterlab-change-ui-font-size-fix — Fixes file browser icon misalignment when users change the UI font size — a small but real pain point for anyone who needs larger text.

27 Extensions, One Platform

Stellars is a JupyterLab-based data science platform — GPU support, MLflow, TensorBoard, Optuna — assembled from 27 custom extensions covering everything from branding and file icons to kernel management and diagram rendering, VS Code file icons, trash management, Mermaid-to-PNG conversion, and more.

JupyterLab is now flexible enough that one developer can assemble a domain-specific product entirely from extension building blocks.

Want to Build Your Own?

The JupyterCon tutorial is fully available: step-by-step materials and the complete YouTube recording. It covers scaffolding, plugin architecture, publishing to PyPI, and rapid prototyping techniques. The tools have never been more accessible.

How We Track This

The data behind this post comes from the JupyterLab Marketplace, a community project that tracks all published JupyterLab extensions using PyPI data. The marketplace refreshes automatically and provides download trends, category breakdowns, and discovery tools.

JupyterLab Marketplace

For more on the data and methodology, see our PyData Boston 2025 talk.

What’s Next

New interaction patterns are still being figured out — chat-based assistance, cell annotations, agent protocols. Probably all of them for different use cases.
Reproducibility tooling suggests the community is ready for opinionated workflow management built into the notebook experience.

Ensuring extensions keep working as JupyterLab evolves is critical — the team has been discussing extension compatibility testing at recent contributors calls.

For the Marketplace itself, we’re working on:

Deeper integration with JupyterLab Extension Manager — deep links and “Install in JupyterLab” buttons to go from discovery to installation in one click.
Expanding Trove classifiers to indicate Jupyter Notebook and JupyterLite support. All three use the same extension system, with important caveats: Notebook extensions need to target different UI elements, and JupyterLite extensions cannot have a server component.
Better contribution signals — surfacing commits, PRs, and issues to help users gauge how actively maintained an extension is.

At 700 extensions, the community now shapes JupyterLab as much as the core team does. If you’re building extensions, thank you! Every one of them makes Jupyter better for someone.

About the author

Konstantin Taletskiy is a Senior Software Engineer at Anaconda working on open-source Jupyter. He is a contributor to JupyterLab, maintainer of mamba-gator and jupyterlab-latex, and the creator of the JupyterLab Marketplace.

Call for applications: Community Manager for JupyterHub and Jupyter Book

2026-03-05T16:44:00+00:00

The JupyterHub and Jupyter Book communities are hiring a community manager.

Join our community and support us all to grow, nurture, and build things together. Credit: The Turing Way and Scriberia, used under a CC-BY license https://doi.org/10.5281/zenodo.3332808

In JupyterHub, we are democratizing access to interactive computing environments to allow everyone, no matter where they are, to explore data, develop code, and advance knowledge without barriers. In Jupyter Book, we are building the next generation of open, community-driven technical publication tooling, leveraging the MyST document engine to create modular, reusable, and reproducible computational narratives.

We are excited to fund dedicated time for someone — maybe you! — to join these teams.

The community manager will be responsible for identifying and developing activities and communication pathways that align maintainer and contributor actions with the goals of each project, and that build bridges across the Jupyter ecosystem.

You can read more about our motivation for this role in the proposal, part of the Jupyter Foundation’s Community Funding initiative. We particularly encourage applicants to review the section “Impact Metrics: How do we define success?”

In this blog post we have outlined the community manager’s responsibilities, their preferred expertise, and how to apply.

This is a contract role, funded at $90,000 to be spent by the end of April 2027. The community manager will be engaged as a contractor of the Linux Foundation and will follow the standard Linux Foundation contractor onboarding process.

The deadline to apply is 29 March 2026.

Responsibilities

Strategic alignment and contributor guidance

Collaborate with the maintainer teams from both projects to understand, document, and broadcast each project’s priorities to their communities.
Actively connect contributors to open issues and workstreams that align with the respective project’s goals, and redirect well-intentioned contributions that are not aligned with the project’s currently prioritized efforts.
Efficiently connect contributors with maintainers to provide them the guidance and review needed to make efficient progress, managing workload on both sides of the mentorship pair.

Contributor growth and leadership development

Design, visualize, and manage a clear contributor journey, including identifying requisite skills and project context knowledge, for each community.
Identify engaged community members and create pathways for them to take on more responsibility, such as triaging issues, reviewing pull requests, or mentoring others within their project of interest.

Fostering knowledge sharing and collaboration

Identify and create opportunities for the community of each project to share information, best practices, and technical knowledge, while respecting their distinct roadmaps.
Facilitate cross-community events, such as running “collaboration cafes” for both JupyterHub and JupyterBook, and strategically shape them into meetings that provide value and foster connection for both projects.
Develop re-usable templates for explaining contributor pathways, such as onboarding documentation, skills maps/matrices for progression into contribution and maintenance roles, and collaboration cafe guides.

Learn in the open

Ensure all materials are publicly available and discoverable, including progress against our community health metrics described below.
Promote these learnings across the Jupyter community including within the Zulip channel, at regular community calls, and by “visiting” other sub-projects (at synchronous meetings or in asynchronous discussion spaces) to discuss community management efforts as requested.
Join the Jupyter Community Building Working Group and be an active member throughout their paid time on the project.

Preferred expertise

We have not marked any of the expertise categories listed here as required. We recognize that we are looking for a unicorn, and they are curiously hard to find! If you do not have expertise across all of these categories we encourage you to apply. We are looking forward to getting to know candidates better, including where they have identified opportunities for career and skill development as part of the JupyterHub and Jupyter Book teams.

Our assessment pathway is included as part of this list to guide applicants in curating their strongest application. If you are uncertain how to answer any of the questions and/or prompts, please ask in our Jupyter Hub Zulip channel or email Kirstie Whitaker directly at kirstie.whitaker@berkeley.edu.

Track record of contributions to open source projects.

Assessment: Cover letter & links

Understanding of multi-stakeholder, community governed open source community dynamics.

Assessment: Interview question. Describe two situations — one featuring a success and one a failure — where you have sought to align diverse stakeholders around a common goal. For both, share what you learned from the experiences.

Understanding of the challenges that Jupyter Hub and Jupyter Book are designed to solve (or reduce) in the world.

Assessment: Interview question. Describe two deployments — one each of Jupyter Hub and Jupyter Book — that each meet a need in either education, research or technical development. You do not need to have run these deployments yourself.

Technical skills in Python and/or TypeScript.

Assessment: Cover letter & links

Track record of identifying and completing tasks in the presence of significant uncertainty.

Assessment: Cover letter

Ability to work effectively with two distinct and diverse teams whose community members are geographically distributed with significant time zone differences.

Assessment: Cover letter. All instructions from this recruitment call followed, the letter is clearly and concisely written, includes concrete examples, and publicly accessible links where appropriate.
Assessment: Interview question. Given your knowledge of Jupyter Hub and Jupyter Book, and your previous experience, how will you know if you are working effectively within these two communities?

Ability to ask for help and self manage time allocations and tasks.

Assessment: Interview question. Which aspects of this role do you think will be hard for you? Which aspects will be easy (or easier) for you? Where do you expect to ask for help and/or support in the role?

How to apply

Submit a cover letter and resume through this Google Form: https://forms.gle/Qw6ddyJ8rzZY5vQm6

Please include:

Your motivation to apply for this role.

Links to up to 3 publicly available GitHub repositories that highlight engagement in issues, pull requests, community discussions (or equivalent conversations on alternative git forge platforms).

If you don’t have publicly available links, provide a letter from a team member from a private initiative who can endorse these collaboration skills.
If you can not meet this requirement, please note that in your application.

Links to up to 3 examples of code you have written in Python and/or TypeScript.

If you don’t have publicly available links, provide a letter from a team member on a private initiative endorsing these development skills.
If you can not meet this requirement, please note that in your application.

A description of a previous role (paid or volunteer) where you have identified and delivered outcomes in the presence of uncertainty.

Include links to task documentation (issue / PR / report) if publicly available.
If you can not meet this requirement, please note that in your application.

What to expect

We’ll accept applications from now through 29 March, 2026.

Once applications are in, here’s our process:

Resume and cover letter review: The recruitment panel will review all applications and invite up to 5 applicants for an interview on zoom at a time that is convenient for the applicant and the panel members.
Interview: The recruitment panel will meet with applicants for 30 minutes over Zoom. They will ask the same questions of every applicant.
Panel discussion & alignment: The recruitment panel will discuss interview outcomes and align on a decision.
Offer: We expect to communicate a final decision to all applicants by 30 April, 2026.

Timeline

29 March 2026, AoE: Deadline for resume and cover letter applications.
Before 5 April 2026: Invite up to 5 applicants to interview.
8 April — 17 April 2026: Interviews conducted over Zoom.
Before 11 May 2026: Communicate final decision to all applicants.
May 2026: Post holder coordinates a contract with the Linux Foundation, following their standard onboarding process.

Acknowledgements

This job description was co-created by April Johnson, Yuvi, and Kirstie Whitaker, with guidance from Chris Holdgraf, Min Ragan-Kelley, Raniere Silva, and Stéfan van der Walt, along with community input at the JupyterHub and Jupyter Book collaboration cafes.

Jupyter Community Call: February 2026

2026-02-16T13:26:00+00:00

February 2026 Jupyter Community Call

Hey Jovyans, we’d love for you to join us on our final community call of the year! We want to learn all about the great things you’re doing with Jupyter. The Community Building working group is holding an open call with the community, for people to discuss and share their work. Think of it as a “virtual JupyterCon”: It’s a place to announce and share new things happening in the Jupyter ecosystem.

We encourage brief (5 minutes or less) presentations with a demo or screen share, as needed. If you have a GitHub repo or demo web site, please remember to share it.

Anyone can attend, for free! Anyone can present; add yourself to the HackMD agenda. Anyone can sit in on the call. Presenters will lead a demo and may leave time to answer questions. Topics should be targeted to broad and global audience. Keep things simple and remember not every listener will be a software engineer.

Event details:

February 25, 2026, at 9:00 AM PDT (15:00 UTC; your timezone)

Agenda (add yourself!) on HackMD
Meeting channel: https://zoom.us/j/95228013874?pwd=Ep7HIk8t9JP6VToxt1Wj4P7K5PshC0.1
Meeting ID: 95228013874 / Meeting Passcode: 659973
Or connect via phone:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592
or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free)
International numbers: https://zoom.us/u/alwnPIaVT

Watch previous calls in our YouTube playlist.

Scaling “Maintainer Intuition” with Pull Request Triage Boards

2025-11-16T21:22:00+00:00

When I helped start 2i2c.org, one of my goals for the non-profit was to experiment with new and different ways of supporting the Jupyter ecosystem’s long term health. As part of that, we have identified how foundational contributions are very important (and distinct from directed contributions), and have been experimenting with new ways to make foundational contributions in sustainable and structured ways.

One such way was via systematically doing code reviews for Pull Requests from non-maintainers in the JupyterHub ecosystem. Reviewing PRs is a critical way that maintainers keep an open source project moving forward, but identifying PRs that can productively be merged is hard. This is a post describing our system for scaling this in our team. Each 2 week sprint, we:

Looked at all open PRs in the JupyterHub org who were not maintainers
Picked a PR that I deemed was reviewable and ideally mergeable within this time window
Have an engineer on the team pick up that PR, and try to get it to close
Report back on what we have learnt, so we can iterate on our process

We managed to do this for a majority of sprints over the last roughly 12 months! One key bottleneck we identified in the process was Step 2. In particular, I was relying on my maintainer intuition to pick a single PR that I believe can be merged, so others in the team can do review work. I started exploring what this intuition is, and if it can be scaled.

What is this maintainer intuition?

How did I pick a PR from a long list of open PRs? Observing my own behavior a few times, I noticed I was looking for:

PRs that aren’t too big, and are a reasonable size that can be merged within a 2 week window
CI tests passing, so at least our automated checks haven’t caught any issues with it
Features or bug fixes that I believe add value to the project and move us in the right direction towards being able to support our users as they need (this is the hardest!)
If the author of the PR is a newish contributor, as I want to encourage them to stick around by being responsive to their gift. All PRs are gifts that we may or may not choose to accept, but should do so with grace.
How long ago the PR was opened. There is such a big difference between a response to your PR 2 days after you make it vs 2 months vs 2 years. I prioritized newer PRs.
What kind of contribution is it primarily? Different engineers on our team have different skillsets (JS, Python, etc) and I wanted to match the PR to what the engineer preferred code reviewing.

While (3) is hard to scale, everything else seemed like something we could build systems for that let others follow a process, thus removing myself as a bottleneck. I experimented with some GitHub issue filters and project automations, and after finding them lacking, built out a brand new open source project to do this: pr-triage-board-bot!

PR Triage GitHub Boards

pr-triage-board-bot automatically maintains PR Triage Boards for a Github organization. You can check out the current boards to get a sense of how it looks: JupyterHub, JupyterLab, and GeoJupyter.

For each PR Triage Board, the bot will:

Add all open, ready for review PRs
Remove all closed or draft PRs
Annotate each PR with additional deterministic project fields that allow for sorting and filtering in the project board. To start with, it populates the following fields:
1. Author kind (Maintainer, Seasoned Contributor, First Time Contributor, Bot)
2. Size (Number of lines touched)
3. Date it was opened
4. If a maintainer has already interacted with the PR (One, Many, None)
5. Are there merge conflicts?
6. What kind of files were mostly changed? (Python, JS, Docs)
Keep this up to date by automatically running every hour via GitHub actions

Once these project fields are populated automatically, maintainers can create different Project Views for themselves to help with different workflows via filters and sorting. For example, the JupyterHub board contains the following views:

PRs split by author kind, sorted by newness and size so we can try to respond to PRs from new users as early as possible
PRs that have not had a single maintainer interaction on them, so we can acknowledge people’s contributions to us even if we can’t fully review it at the moment
Bot PRs with all tests passing and no merge conflicts, so we can more easily stay on top of automated updates
PRs that have been approved by a maintainer but not merged yet, as sometimes a maintainer wants to give others time to object but needs to go back and hit merge.
PRs that are primarily updating documentation, as the review process for this can be different

For our original purpose of getting more people to do code review, this board has served well — we can roughly say ‘Pick a PR that looks good to you from the top of the “First Time Contributor” or “Seasoned Contributor” list’, and that relieves me from being the bottleneck quite a bit. Other maintainers are also finding a lot of value in this board. For example, if you only have 15 min, you can probably get a clean bot PR reviewed and merged. Or look for PRs that haven’t been acknowledged by a maintainer and engage with them. Our next step is to help run structured social experiments, where we try to establish specific ceremonies in the open source ecosystem to get specific lists of open PRs (such as “PRs with no maintainer engagement, or PRs older than 2y”) down to zero. Stay tuned to hear more :)

We are essentially using GitHub Project Fields as a database, adding additional fields that are very valuable to maintainers but not available in GitHub by default. While ideally these would be contributed by us directly into GitHub, only Microsoft has control over what gets added to the product. So we find interesting workarounds like this to accomplish our goals :)

Successful Adoption

I was just playing with this, and Raniere from the JupyterHub team spotted it and asked about it on Zulip. Jason Grout from the JupyterLab team was also super interested, and with contributions from him, the bot quickly got adopted by the JupyterLab GitHub org as well. We cleaned this up a bit more, and found adoption within the GeoJupyter project too with help from Matt Fisher. As with everything we do at 2i2c, I had tried to design this to be widely useful to many orgs and maintainers rather than just us, and looks like I have wildly succeeded :)

I am happy to announce today that 2i2c is officially donating pr-triage-board-bot to Project Jupyter! I will still continue to contribute to maintaining the project, and welcome contributions from everyone else too!

If this looks useful to your open source project, consider adopting it by following these instructions. The project is still fairly new, so if you run into issues please let us know on the Project Jupyter Zulip chat or by opening an issue.

Hey Jovyans, we’d love for you to join us on our final community call of the year!

2025-11-13T16:18:00+00:00

December 2025 Community Call

We encourage brief (5 minutes or less) presentations with a demo or screen share, as needed. If you have a GitHub repo or demo web site, please remember to share it.

Event details:

December 04, 2025, at 8:00 AM PDT (16:00 UTC; your timezone)

Agenda (add yourself!) on HackMD
Meeting channel: https://zoom.us/j/95228013874?pwd=Ep7HIk8t9JP6VToxt1Wj4P7K5PshC0.1
Meeting ID: 95228013874 / Meeting Passcode: 659973
Or connect via phone:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592
or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free)
International numbers: https://zoom.us/u/alwnPIaVT

Watch previous calls in our YouTube playlist.

Jupyter Community Call: September 2025

2025-07-31T15:11:00+00:00

September 2025 Community Call

Hey Jovyans, we want to learn about the great things you’re doing with Jupyter! The Community Building working group is holding an open call with the community for people to discuss and share their work. Think of it as a “virtual JupyterCon”: It’s a place to announce and share new things happening in the Jupyter ecosystem.

We encourage brief (5 minutes or less) presentations with a demo or screen share, as needed. If you have a GitHub repo or demo web site, please remember to share it.

Event details:

September 04, 2025, at 8:00 AM PDT (15:00 UTC; your timezone)

Agenda (add yourself!) on HackMD
Meeting channel: https://zoom.us/j/95228013874?pwd=Ep7HIk8t9JP6VToxt1Wj4P7K5PshC0.1
Meeting ID: 95228013874 / Meeting Passcode: 659973
Or connect via phone:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592
or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free)
International numbers: https://zoom.us/u/alwnPIaVT

Watch previous calls in our YouTube playlist.

Jupyter Community Call: June 2025

2025-05-22T15:06:00+00:00

June 2025 Community Call

Hey Jovyans, we want to learn about the great things you’re doing with Jupyter! The Diversity, Equity, and Inclusion (DEI) standing committee is holding an open call with the community for people to discuss and share their work. Think of it as a “virtual JupyterCon”: It’s a place to announce and share new things happening in the Jupyter ecosystem.

We encourage brief (5 minutes or less) presentations with a demo or screen share, as needed. If you have a GitHub repo or demo web site, please remember to share it.

Event details:

June 11, 2025, at 9:00 AM PST (17:00 UTC; your timezone)

Agenda (add yourself!) on HackMD
Meeting channel: https://zoom.us/j/95228013874?pwd=Ep7HIk8t9JP6VToxt1Wj4P7K5PshC0.1
Meeting ID: 95228013874 / Meeting Passcode: 659973
Or connect via phone:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592
or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free)
International numbers: https://zoom.us/u/alwnPIaVT

Watch previous calls in our YouTube playlist.

Congratulations, Distinguished Contributors!

2025-05-15T15:15:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2024 cohort of contributors.

Please congratulate the winners of the 2024 cohort of Jupyter Distinguished Contributors!

Denisa Checiu

Rowan Cockett

Mahendra Paipuri

Isabel Paredes

David L. Qiu

Rick Wagner

Project Jupyter’s 2025 Executive Council Elections

2025-03-06T16:26:00+00:00

Project Jupyter recently completed its 2025 Executive Council (EC) election, marking an important transition in its leadership. The newly elected members — Afshin Darian, Chris Holdgraf, and Rick Wagner — will serve two-year terms, helping guide strategic and operational direction for Project Jupyter.

Rick Wagner, San Diego Supercomputer Center (2025–2027)
Afshin Darian, QuantStack (2025–2027)
Chris Holdgraf, 2i2c (2025–2027)
Ana Ruvalcaba, Cal Poly State University San Luis Obispo (2024–2026)
Jason Grout, Databricks (2024–2026)
Zach Sailer, Apple (2024–2026)

Who Are the Newly Elected EC Members?

The three elected members bring deep expertise and long-standing contributions to Jupyter:

Afshin Darian was part of the inaugural Executive Council in 2023 and is continuing in his role as an EC member. He has contributed to Jupyter’s transition to the Linux Foundation, alongside his work on the architecture of Jupyter and accessibility.
Chris Holdgraf has played a key role in JupyterHub, Binder, and Jupyter Book, helping to sustain and grow these vital subprojects. He is also the executive director of a non-profit called 2i2c that manages JupyterHub infrastructure for communities in research and education.
Rick Wagner has been active in Jupyter’s Security Subproject, advocating for secure development practices and leading major security initiatives.

Their collective experience spans technical innovation, community governance, security, and sustainability, ensuring that Jupyter continues to evolve in a way that serves users, contributors, and the broader ecosystem. Darian, Chris, and Rick will join the members serving in their current two-year terms, Jason Grout, Ana Ruvalcaba, and Zach Sailer. Together, the EC members represent industry, academic, and non-profit organizations.

Creating Open, Sustainable, Leadership

When Jupyter was created, it followed a “Benevolent Dictator for Life” (BDFL) style of governance that was popular in open source communities at the time. Throughout the 2010s, the project learned (along with many others in the open source ecosystem) that BDFL models for complex projects are not sustainable for both the project and for its contributors. As a result Jupyter began a long-term initiative to move away from its BDFL decision-making structure. It began by adopting a Steering Council model, where a group of peers made consensus-based decisions across the entire project. This distributed Jupyter’s decision-making authority, but did not efficiently represent the breadth and complexity of Jupyter’s ecosystem.

In 2022, Project Jupyter took the next step towards formalizing and decentralizing its governance. It adopted a more dynamic, distributed, and community-driven structure. Jupyter’s governance model guides the development of over a dozen distinct software components and several groups focused on specific activities, including accessibility and security. Software design and development is handled by individual Subprojects, with each Subproject typically responsible for one or more software components or packages. Subprojects elect representatives to the Software Steering Council which has jurisdiction over software-related decisions across Project Jupyter. The Executive Council is chosen via elections and has the ultimate responsibility for all aspects of Project Jupyter, including its software, finances, trademark, operations, etc. In 2024, this extended to the creation of the Jupyter Foundation, a directed fund of the Linux Foundation 501(c)(6) whose purpose is to raise, budget and spend funds in support of Project Jupyter and its mission. The Foundation Governing Board controls the resources of the Foundation, and works to build a healthy collaboration between the Jupyter community, Jupyter leadership, and members of the Jupyter Foundation.

Jupyter recently completed its 2025 election for the Executive Council. This election is especially significant because it marks the first time that Fernando Pérez and Brian Granger, two of Jupyter’s founding figures, will not serve in the executive leadership body of the project. Their voluntary departure from the EC reflects their confidence in the governance model established in 2022 and is an indication that the new model is progressing toward its goal: creating a self-sustaining leadership structure where contributors from across the Jupyter ecosystem can contribute their talents. Going forward, Brian will continue to be involved in Jupyter’s software and will serve on the Governing Board of the Jupyter Foundation. Fernando will remain actively involved with various parts of the Jupyter ecosystem, including JupyterHealth, MyST, Jupyter uses in science and education through 2i2c, Jupyter-AI, and the nascent GeoJupyter (independent) community effort.

What This Means for Jupyter’s Future

The success of this election signals a healthy, evolving open-source project, where leadership is dynamic, inclusive, and community-driven. It shows that Jupyter’s governance changes have not only ensured continuity but have also empowered new voices to take on leadership roles to serve the community.

The departure of Fernando and Brian from official leadership positions is not an end, but a milestone — a testament to our vision for an open, thriving, and community-led project.

The Jupyter community now looks ahead to the next era of innovation, collaboration, and sustainability with support from all of its contributors.

Join JupyterHub on Zulip chat!

2025-02-06T16:05:00+00:00

The JupyterHub team have just moved all their chat to a Zulip channel!

The Jupyter Zulip instance is a Jupyter-wide chat space allowing cross-team communication in channels, some of which can be viewed publicly without an account.

For the JupyterHub team, we have found better engagement from team members and across the wider eco-system by using the Zulip instance. To that end, we recently updated all of our Gitter rooms to “invite-only” so no new members could join, and left a pinned message with a link to the JupyterHub channel on Zulip and an invite to join the conversation there. We have also updated any of our repositories that had Gitter links to point to Zulip as well.

If you would like to keep in touch with the JupyterHub, we would love to hear from you over on Zulip!

Jupyter Community Call: February 2025

2025-01-30T22:59:00+00:00

Hey Jovyans, we want to see the great things you’re doing with Jupyter! The Diversity, Equity, and Inclusion (DEI) standing committee is holding an open call with the community for people to discuss and share their work. Think of it as a “virtual JupyterCon”: It’s a place to announce and share new things happening in the Jupyter ecosystem.

We encourage brief (5 minutes or less) presentations with a demo or screen share, as needed. If you have a GitHub repo or demo web site, please remember to share it.

Anyone can attend, for free! Anyone can present; add yourself to the agenda above. Anyone can sit in on the call. Presenters will lead a demo and spend a few minutes answering questions. Topics should be targeted at a broad Jupyter audience, not just programmers.

Event details:

February 19, 2025, at 9:00 AM PST (17:00 UTC; your timezone)

Agenda (add yourself) on HackMD
Meeting channel: https://zoom.us/j/95228013874?pwd=Ep7HIk8t9JP6VToxt1Wj4P7K5PshC0.1
Meeting ID: 95228013874 / Meeting Passcode: 659973
Or connect via phone:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592
or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free)
International numbers: https://zoom.us/u/alwnPIaVT

Watch previous calls in our YouTube playlist.

Project Jupyter joins LF Charities

2024-10-23T19:00:00+00:00

We are excited to announce that Project Jupyter is entering a new phase in our journey: we are joining LF Charities, a 501(c)(3) non-profit under the Linux Foundation. See the official press release from Linux Foundation and the blog post from NumFOCUS.

In the last decade, Jupyter has grown tremendously. From our roots as an evolution of the IPython project, Project Jupyter is now the de facto standard for interactive computation in data science, scientific computing, and machine learning. The software and standards developed by the Jupyter community span a rich and diverse ecosystem that includes data science, geospatial data analysis, physics, chemistry, CAD, and many other areas.

In order to sustain this momentum, continue innovating in the space of interactive computational tools for thinking and collaborating, and better serve our community, we are introducing the new Jupyter Foundation, a vehicle for the project to formally engage with industry partners and other organizations. We invite organizations of all types, including companies, government agencies, and non-profits who support our mission to join us through the Jupyter Foundation. For information on joining, please see https://jupyterfoundation.org.

As background for this change, the Project Jupyter Executive Council began exploring options for the next phase of our growth over a year ago. In March 2024, we presented a high-level proposal to the community for Jupyter to transition to LF Charities as its legal home. An open discussion was hosted on GitHub for the community to discuss this idea, generating a lot of feedback, which was incorporated into the main proposal document. Once discussion settled, on June 14, 2024, we moved to a formal vote as per our governance model, in which the Jupyter Executive Council and the Jupyter Software Steering Council jointly approved moving forward with the transition to the LF Charities. We have since then worked with both NumFOCUS and Linux Foundation leadership to formalize the transition, which is completed today. We sincerely thank NumFOCUS for their support of IPython and Jupyter, and we look forward to continuing collaborating with the entire community of NumFOCUS projects.

If you are a user or supporter of Jupyter in any capacity, please help us spread the word about this new phase for the project, and encourage organizations to support our mission through the Jupyter Foundation.

November 2024 Jupyter Community Call

2024-10-21T20:12:00+00:00

Hey, Jupyter community! We want to see the cool things you’re doing with Jupyter, so the Diversity, Equity, and Inclusion (DEI) standing committee is holding an open call with the community for people to share and chat about their work. Think of it as a “virtual JupyterCon”: It’s a place to announce and share fun things happening in the Jupyter community.

We encourage brief (5 minutes or less) presentations with a demo or screen share, as needed. If you have a GitHub repo or demo web site, please share it!

Event details

November 13, 2024, at 9:00 AM PST (17:00 UTC; your timezone)
Agenda (add yourself) on HackMD
Meet on Zoom

Anyone can attend, for free! Anyone can present; add yourself to the agenda above. Anyone can sit in on the call. Presenters will lead a demo and spend a few minutes answering questions. Topics will be targeted at a broad Jupyter audience, not just programmers.

Watch previous calls in our YouTube playlist.

Announcing the 2023 Jupyter Distinguished Contributor Award Recipients

2024-09-04T16:46:00+00:00

We are delighted to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2023 cohort.

Project Jupyter Distinguished Contributors are recognized for their significant and sustained contributions to Jupyter over a period of at least two years. These contributions encompass a wide range of areas, including code development, code review, infrastructure work, participation in mailing lists and chats, community building and support, education and outreach, fundraising, branding and marketing, efforts in inclusion and diversity, UX design, and research.

Please join us in congratulating the winners of the 2023 cohort of Jupyter Distinguished Contributors:

Nicolas Brichet
Piyush Jain
Duc Trung Le
Jason Weill

Their dedication and hard work have been instrumental in advancing the Jupyter project and community.

Johan Mabille — on behalf of the Jupyter Distinguished Contributors

Community Building Report: Project Jupyter

2024-08-29T19:21:00+00:00

The Jupyter Community Building Working Group would like to share a report and community building recommendations from interviews with members of Project Jupyter subprojects. We invite you to view the full report by clicking here and we welcome feedback on the Jupyter Discourse channel.

Community Building Report: Executive Summary

In late 2023, the Jupyter Community Building Working Group (JCB) launched a series of discussions with subproject representatives to better understand and support their community-building needs: a Jupyter Community Building Survey. The goals of the survey were to understand community-building needs and goals for each subproject, to gather information necessary to advise the Executive Council (EC) on where and what types of resources would be most impactful to meeting these needs and goals, and to identify and share community practices across Project Jupyter.

The JCB used a hybrid approach including a written survey followed by a 30 minute in-depth interview. The report includes our methodology and findings broken out by cross subproject topics and by subproject interviews. A copy of the interview questionnaire is included as Appendix A. This report will be publicly shared and sent to the EC to inspire or serve as a catalyst for strategic activities moving forward. If you have ideas or feedback, we invite you to reach out to us on Discourse.

Here is a brief summary of our recommendations (in no particular order).

1. Create a sustainable events program for subprojects
Project Jupyter should establish stable sources of funding, allocation procedures, and logistical support specifically for subprojects to conduct synchronous, in-person, collaborative meetings on an annual basis. The Project should also provide a way for associated events funded externally to label themselves as “affiliated” or “endorsed” by Project Jupyter.

2. Establish a mechanism for requesting resources
Project Jupyter should establish a procedure for accepting, reviewing, and funding proposals from subprojects. This could include support for external consulting services, infrastructure, or other items that have the potential to benefit the subproject itself and by extension the wider Jupyter ecosystem.

3. Increase Cross Project Coordination
Project Jupyter should create a regular program of Jupyter-wide meetings (virtual and in-person). These meetings should include opportunities to share news between subprojects, discuss best practices and lessons, and also provide opportunities for the wider user community to share information with contributors.

4. Improve onboarding processes for contributors
Project Jupyter should establish a dedicated effort to improve onboarding processes for contributors. This could be a working group, strategic initiative, or paid staff and should focus on creating a more streamlined, consistent, and inclusive onboarding experience for all contributors. An approach that includes code and non-code contributors is important to success.

For more context on these four recommendations and some idea of what next steps are for implementing them, please visit section 4 of the full report.

Acknowledgements

The members of the Jupyter Community Building Working Group — Rollin Thomas (Berkeley Lab NERSC), Martha Cryan (Plotly), Ana Ruvalcaba (Cal Poly, San Luis Obispo), and Jason Grout (Databricks) — would like to thank all involved in this survey. We extend our gratitude to the subproject participants who found time in their busy schedules to respond to our survey questions and meet with us for interviews! We enjoyed learning more about the different subprojects and connecting with their contributors. This report represents a significant investment of time and we hope that its contents will help drive new strategic initiatives at Project Jupyter.