Merge the JupyterLab and Jupyter Notebook subprojects?

[jtpio]

Problem

Jupyter Notebook 7 final has now been available for a couple of months (released in July 2023). There is a migration guide for Classic Notebook (v6) users, but now most of the development work is focused on Notebook 7.

As Notebook 7 is built on top of JupyterLab, there seems to be more overlap between the JupyterLab and Jupyter Notebook subprojects, in terms of scope, community, features, code base.

So the question is: do we still need to keep the JupyterLab and Jupyter Notebook subprojects separate? Or could the two subprojects be merged into a single "Jupyter Frontends" subproject? As a way to make it even more visible that JupyterLab and Jupyter Notebook are the two official frontends being developed by Project Jupyter.

Proposed Solution

Notebook 7 is pretty much JupyterLab re-assembled in a different way, so folks familiar with JupyterLab development would also be comfortable working on Notebook 7. For JupyterLab and Jupyter Notebook developers, this could also help catch potential issues from decisions and technical choices happening upstream in JupyterLab, that can have an impact downstream in Notebook 7.

Having Notebook 7 on the radar could help keep the Notebook 7 use case in mind when designing features or making changes upstream in JupyterLab. This would benefit end users as developing the two frontends more closely could help improve UX and general design decisions.

Summary of the proposal:

• Merge the JupyterLab and Jupyter Notebook meetings: Merge meeting for Notebook and Lab jupyter/notebook-team-compass#30
• Merge the subprojects, and decide on a name. Maybe "Jupyter Frontends" would be a good candidate?
• Merge the council members into a single council

Additional context

Opening this issue here in the JupyterLab team compass repo to get an idea of what people think, before opening an issue or PR in https://github.com/jupyter/governance.

This was also briefly discussed in jupyter/notebook-team-compass#30.

For reference two other Jupyter subprojects were merged previously: jupyter/governance#174

[tonyfast]

this makes a lot of sense to me judging by the contents of the meetings. this change would free up space for some other efforts potentially, or room for the docs working group to grow. the notebook team did an amazing keeping those efforts through all the difficult releases. merging meetings seem to signal positive growth.

i think this change could be really good for reinforcing accessibility changes. right now, a lot of changes are being made to jupyterlab components because it is our flagship. notebook should be the accessible flagship and i think merging the meeting might allow more folks to contribute to accessibility improvement notebooks when it shares equity with jupyterlab in meetings.

[jasongrout]

+1 to this idea, thanks for posting here, Jeremy!

As with the recent Foundations/Standards subproject merge, and as you hinted above, the process is:

1. Get consensus between the two subprojects that they'd like to merge
2. Open an PR in the governance repo, like Merge Foundations and Standards subprojects jupyter/governance#174
3. The SSC and EC vote on it (as it is a governance change)
4. Presuming it passes the vote in step 3, the PR is merged and the new combined subproject is official. Congratulations!

[jtpio]

Thanks!

Pinging the JupyterLab council for awareness: @jupyterlab/jupyterlab-council

And the current member of the Notebook council (the team can't be mentioned directly as it is in the jupyter organization): @afshin @andrii-i @blink1073 @damianavila @echarles @isabela-pf @ivanov @kevingoldsmith @RRosio @SylvainCorlay @Zsailer

[Zsailer]

This makes a lot of sense to me. Thanks, all.

[SylvainCorlay]

I am +1 on this. Thank you for opening the issue @jtpio.

[ivanov]

I support this change, with the minor caveat that if the new name was "Jupyter Frontends", we would be in a place where qtconsole is a frontend that is not in the "Jupyter Frontends" .

"Jupyter Web Frontends" might be too much of a mouthful. Another approach would be to explicitly point to qtconsole as another frontend that's not under the purview of this new lab+notebook unified subproject.

[echarles]

Thx for opening this @jtpio.

Would that new "Jupyter (Web) Frontends" meeting/council also cover the Notebook 6 line, or just focus on the JupyterLab stack.

It is hard to know the numbers, but there is still a significant portion of users on Notebook 6 and wonder where they would be supported?

[echarles]

Not sure atm if the github notebook council team is updated, so I have also sent a mail to the Notebook council members via google groups to give visibility.

[krassowski]

Jupyter Web Frontends

Then jupyterlab-server does contain non-frontend code though. JupyterLab does too for that matter (e.g. extension manager, all the lab-specific CLI stuff). Either Jupyter Frontends or Jupyter Web Frontends would feel like a misnomer. Some other options to explore would be Jupyter Clients or Jupyter User Interfaces (CLI is a user interface too). Or just Jupyter Notebook & Lab.

Edit: there is also JupyterLab Desktop and a potential to have Jupyter Notebook Desktop, for these the proper name does feel like Client or UI rather than web interface because Electron while built using web-adjacent stack is a thing of its own with its own desktop-centric APIs.

[echarles]

Or just Jupyter Notebook & Lab

That has the merit to be explicit. If we want more explicit (more is better in this case), this could be Jupyter Notebook>7 & Lab

CLI is a user interface too

100% onboard with that, and it looks like this proposal does not cover CLI stories if I am not mistaken.

[davidbrochart]

Then jupyterlab-server does contain non-frontend code though. JupyterLab does too for that matter (e.g. extension manager, all the lab-specific CLI stuff). Either Jupyter Frontends or Jupyter Web Frontends would feel like a misnomer.

I would be in favor of a "Jupyter Frontends" project, with the condition that frontends are well separated from the backend. For instance, JupyterLab should be backend-agnostic, but it currently requires jupyter-server. This is an issue for users who want to use Jupyverse, because it brings additional installation constraints (see this issue).