It's the journey that counts: roadmapping efforts in JupyterHub

2026-11-06T10:48:00+00:00

This blog post had input from many JupyterHub project members.

Time to plot the route! Figure reused from The Turing Way under CC-BY 4.0. See end of the blog post for citation.

Over the course of the past few years, JupyterHub has been doing in-depth work examining the project’s history, achievements, and community, reflecting on the project and the people who have contributed to its successes, as a way of building towards the future. You can read more on some of this work at Voices of JupyterHub report. Several of the recommendations in the Voices of JupyterHub report signposted the project towards the need for a clearer vision and roadmap for where the project was heading over the next few years. We were therefore delighted to receive funding from the Jupyter Foundation to support our Roadmapping event in February 2026.

There are numerous advantages to roadmaps for open source projects. Having a clear statement of the priorities for core team members is enormously helpful for people who deploy JupyterHub, who can see what changes might be on the horizon, and weigh in on how they might affect their use of JupyterHub. We’re enormously grateful for those who can take the time to add their perspectives in this way! A roadmap can also bring clarity to newer contributors, who can see who is working on what, and what work is still waiting for someone to pick it up. An active roadmap gives everyone - maintainers, contributors, operators, and the wider ecosystem - confidence that the project community is invested in maintaining the software going forward and has a plan for where it’s going. This point was at the core of the discussions over the course of the workshop: the roadmap needed to serve these different audiences to some degree.

The truth is, once upon a time, JupyterHub did have a roadmap. It was clearly documented on the project website and outlined the features that the core project team had agreed were important in the near and medium term. It also had no clear owner, no integration into project workflows, and no obvious pathways for keeping it up to date. While a step in the right direction, we drew on these reflections when discussing what a second version of the roadmap should look like and how it should fit into JupyterHub’s existing practices.

There are still some tensions with developing a roadmap for an open source project maintained by both volunteers and paid project members. Volunteers have limited time to contribute and typically prefer to work on tasks that fit their interests and skillsets, which might not map to what’s on the roadmap. Potential new contributors might also be put off if they feel that they would either be “stepping on toes” or if they don’t see opportunities to share their skills with the project based on what has been publicly prioritised. There’s also the risk that developing a public roadmap puts the project in tension with organisations seeking funding to support their contributions: if a feature is on a roadmap does that make it easier or harder to secure additional resourcing to bring it to life? In the currently shifting funding landscape, the answer isn’t clear. What is clear is that none of these tensions outweighs the potential benefits of articulating a path for JupyterHub.

Designing the event

There were a number of different hopes and dreams for the JupyterHub roadmapping workshop in February 2026 - bringing them all together in a way that addressed them coherently was just one of the challenges for the organisers. Eventually, we identified that there were three main groups of participants: those who wanted to focus on the process underlying the roadmap, those who wanted to discuss the items to be included in the roadmap, and those who wanted to deep dive into specific topics or features. The workshop made space for all of these groups, each bringing a different perspective to the event.

We also tackled the challenge of bringing together a global contributor base with differing geographic locations, family commitments, work patterns, and sleep schedules. This is not an easy thing to do! To tackle this, recently the project has been trialling the concept of sync-async meetings. These are events where groups of contributors that have better aligning schedules meet together asynchronously from the rest of the project. The whole group, regardless of location, also has a short “overlap” session together at the most mutually (in)convenient time for everyone, where deep discussion and practical work can take place. These sessions tend to be more structured and facilitated compared to the async sessions, to help maximise the benefits of the time the project spends together.

To ensure participants all felt connected and part of the meeting together, we used shared documents and communication channels (usually Zulip) to help people catch up on what had been happening in other time zones. A shared presentation document contained participant intro slides so that people who joined late could understand who was who without redoing introductions. For hybrid sessions, we also asked that everyone, whether they were in person or online, joined the online call using their individual webcam.

Hybrid collaboration was a key feature of the Roadmapping Workshop design. Figure reused from The Turing Way under CC-BY 4.0. See end of the blog post for citation.

These sessions aren’t perfect - we are still figuring out as a project how to ensure the right people are “in the room” for certain discussions and for communicating between disparate geographies. If any other projects have solved the global collaboration and communication problem we’d love to share tips!

Outcomes

The goal of the workshop was to develop a roadmap. The first outcome: we have a roadmap! We have created a roadmap repository modeled after 2i2c’s initiatives repository. We have 11 open initiatives. We deliberately have initiatives in a variety of states, to explore the usefulness of this process: those actively being worked on, those in planning stages, collecting feedback, and those that are considered explicitly out of scope for now because it would require more resources than we have (i.e. funding contributor time), or needs to wait for some other reason.

So far, we think this approach supports the two main goals for the JupyterHub roadmap:

improve visibility of what’s being worked on to stakeholders (e.g. operators, prospective contributors), for whom watching all the issues and pull requests fly by on GitHub is not reasonable
help maintainers and contributors prioritise their limited time, when we know that, like most open source work, we have (and always will have) far more work to do than we can ever get done

While also integrating into GitHub, where the majority of the development work occurs.

We have had occasional check-ins on the roadmap process during our Collaboration Café meetings. We’ve learned that a role we need to describe is an “initiative shepherd,” whose only responsibility is tracking the state of an initiative (moving it from active to blocked, back to active, to done, etc.). The shepherd is not responsible for any management of the work itself, only making sure that our roadmap views accurately reflect reality.

So far, we have had some success, in that changes that had been in the works for some time (increasing strictness of server names) were noticed by users impacted by the change, which contributed to the discussion of how to implement the change. The work had been underway for some time, but had not reached people affected by it. This is a success of our first goal of stakeholders seeing work as it happens, when otherwise they likely would not have noticed until the recent JupyterHub 6 release.

We are still learning how best to use the roadmap as a tool for both communication and work planning, and will continue to iterate on our process. Any suggestions or ideas from contributors or other Jupyter ecosystem projects are also welcome.

Acknowledgements

Figures citation: The Turing Way Community, & Scriberia. (2021). Illustrations from the Turing Way book dashes (project-roadmap-with-text, hybrid-collaboration). Zenodo. https://doi.org/10.5281/zenodo.4906004

Jupyter Blog - Raniere Silva

It's the journey that counts: roadmapping efforts in JupyterHub

Designing the event

Outcomes

Acknowledgements