Merge Lab and Notebook Subprojects #200
Conversation
|
Overall, I am in favor of this. From a practical perspective, is the idea to merge before they new SSC reps are elected to avoid having to figure out how to combine the two existing reps into one? |
|
I'm also in favor, and would indeed prefer to officialize the merger right at SSC rep election time, as @ellisonbg suggests. That seems the cleanest solution. |
|
Thanks @ericsnekbytes for starting this. I'm in favor of this too. However I announced some weeks ago that I'm stepping down as lab representative and that I'm reducing my involvement in the project. Therefore as much as I feel responsible for organizing the election of the next lab rep', I don't have time to do more or something else (like helping with this and its consequences). So I have a request to stop the current vote for Jupyterlab rep' in light of this proposal, we need a volunteer to carry out the nomination and election of the new group rep' (or the lab rep' if this was to be rejected). |
|
@fcollonval It was a pleasure working with you...the knowledge you share, the help you've offered, and your contributions to Jupyter are immense. Sad to hear you'll be less involved, but thank you for everything you've done :) How should we proceed with this merger vote? |
|
What should we do with the non-overlapping team members. While the two projects share a lot of the same people, some folks are listed on only one team. I would propose we just merge the two teams to start and then poll the group to see who would like to remain active. |
Thanks @fcollonval for taking care of this process! One option could be to send a message to the current JupyterLab council members and ask if someone would like to volunteer. Given the size of the council, there is a chance someone will agree to carry out the nomination and election.
That sounds good 👍 Also what was originally suggested in jupyterlab/frontends-team-compass#230 (comment) |
afshin
added
the
vote
|
@jupyter/software-steering-council, please vote on this when you can. |
Co-authored-by: Frédéric Collonval <fcollonval@gmail.com>
|
It looks like we've reached consensus with a majority of Yes votes, can someone on the Software Steering Council or Executive Council approve/merge this? Thanks everyone! |
|
Thanks, @ericsnekbytes! Merging away! |
Proposal
Merge the JupyterLab and Jupyter Notebook sub-projects into a single Jupyter Frontends sub-project
Description
Jupyter Notebook 7 has now been available for a couple of months (final was 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, and contributors.
For end users, installing the notebook package also brings the jupyterlab package automatically. Both JupyterLab and Jupyter Notebook also offer UI elements to seamlessly switch between the two user interfaces.
For contributors and maintainers, the Notebook 7 application is a simpler JupyterLab re-assembled in a different way. So developers who are familiar with JupyterLab development would also be comfortable working on Notebook 7, since they both follow the same structure and extension system.
For JupyterLab and Jupyter Notebook developers, merging the two sub-projects would help catch potential issues from decisions and technical choices happening upstream in JupyterLab, which can have an impact downstream in Notebook 7.
In other words, merging the sub-projects would help put Notebook 7 on the radar and keep the Notebook 7 use case in mind when designing features or making changes in JupyterLab. This would benefit end users as developing the two frontends more closely could help improve UX, general design decisions, and accessibility.
References
Original discussion: jupyterlab/frontends-team-compass#230
EC members/voting checkboxes
SSC members/voting checkboxes