Merge the JupyterLab and Jupyter Notebook subprojects?

jtpio commented 9 months ago

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: https://github.com/jupyter/notebook-team-compass/issues/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 https://github.com/jupyter/notebook-team-compass/issues/30.

For reference two other Jupyter subprojects were merged previously: https://github.com/jupyter/governance/pull/174

tonyfast commented 9 months ago

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 commented 9 months ago

+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:

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

jtpio commented 9 months ago

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 commented 9 months ago

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

SylvainCorlay commented 8 months ago

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

ivanov commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

jtpio commented 8 months ago

For reference and as a follow-up to the JupyterLab meeting yesterday (https://github.com/jupyterlab/team-compass/issues/229#issuecomment-1896983165) we are current drafting the proposal in https://github.com/jupyter/governance/pull/200.

Will report here once https://github.com/jupyter/governance/pull/200 is ready for review.

jtpio commented 8 months ago

Will report here once jupyter/governance#200 is ready for review.

https://github.com/jupyter/governance/pull/200 should now be ready for review.

jtpio commented 8 months ago

https://github.com/jupyter/governance/pull/200 has been merged.

So it looks like some of the next steps could be:

merge the council members from the Notebook council (listed in https://github.com/jupyter/notebook-team-compass) here, and ask council members if they want to be part of the merged council
document the merge in https://github.com/jupyter/notebook-team-compass, and archive https://github.com/jupyter/notebook-team-compass
continue with the ongoing SSC representative election

ellisonbg commented 7 months ago

Should we combine the team compasses into a new one frontends-team-compass?

On Fri, Feb 2, 2024 at 8:26 AM Jeremy Tuloup @.***> wrote:

jupyter/governance#200 https://github.com/jupyter/governance/pull/200 has been merged.

So it looks like some of the next steps could be:

merge the council members from the Notebook council (listed in https://github.com/jupyter/notebook-team-compass) here, and ask council members if they want to be part of the merged council

document the merge in https://github.com/jupyter/notebook-team-compass, and archive https://github.com/jupyter/notebook-team-compass

continue with the ongoing SSC representative election

— Reply to this email directly, view it on GitHub https://github.com/jupyterlab/team-compass/issues/230#issuecomment-1924212263, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGXUBD6JRAKLDXYNKX5VLYRUHUZAVCNFSM6AAAAABBLN32GWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRUGIYTEMRWGM . You are receiving this because you are on a team that was mentioned.Message ID: @.***>

-- Brian E. Granger

Senior Principal Technologist, AWS AI/ML @.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

jtpio commented 7 months ago

Should we combine the team compasses into a new one frontends-team-compass?

Good question. https://github.com/jupyter/governance/pull/200 picked the JupyterLab team compass for the merge, mostly for convenience. Regarding the name maybe we could indeed consider renaming it to frontends-team-compass? Although it would probably be easier if the repo stays under the jupyterlab organization on GitHub (for using teams, also most of the development is happening in the jupyterlab org).

ellisonbg commented 7 months ago

I think the rename sounds good (and keeping it in the JupyterLab org).

jtpio commented 5 months ago

Closing as the repo has now been renamed (in https://github.com/jupyterlab/frontends-team-compass/pull/246).

Thanks all!

jupyterlab / frontends-team-compass