Move jupyter-ui-toolkit in the JupyterLab organization

[fcollonval]

As the Jupyter toolkit is now used in JupyterLab, I call for a vote to migrate the repository to the JupyterLab organization following the discussion at the weekly call.

To provide more background, the toolkit is today in the JupyterLab community organization that is not officially endorsed by Jupyter. So moving it in this organization will ensure official support for maintenance and publication rights. In addition it will allow some members to contribute as they may not be allowed to do so on the community organization due to company policy.

---

@jupyterlab/jupyterlab-council the vote is opened up to December 14th, 2023 (anywhere on earth):

• Jason Weill (@JasonWeill):
  • yes
  • no
  • abstain
• Afshin Darian (@afshin):
  • yes
  • no
  • abstain
• Alex Bozarth (@ajbozarth):
  • yes
  • no
  • abstain
• Andrii Ieroshenko (@andrii-i):
  • yes
  • no
  • abstain
• Steve Silvester (@blink1073):
  • yes
  • no
  • abstain
• Nicolas Brichet (@brichet):
  • yes
  • no
  • abstain
• Damián Avila (@damianavila):
  • yes
  • no
  • abstain
• Eric Charles (@echarles):
  • yes
  • no
  • abstain
• Brian Granger (@ellisonbg):
  • yes
  • no
  • abstain
• Eric Gentry (@ericsnekbytes):
  • yes
  • no
  • abstain
• Frederic Collonval (@fcollonval):
  • yes
  • no
  • abstain
• Fernando Perez (@fperez):
  • yes
  • no
  • abstain
• Gabriel Fouasnon (@gabalafou):
  • yes
  • no
  • abstain
• Isabela Presedo-Floyd (@isabela-pf):
  • yes
  • no
  • abstain
• Paul Ivanov (@ivanov):
  • yes
  • no
  • abstain
• Jason Grout (@jasongrout):
  • yes
  • no
  • abstain
• Jeremy Tuloup (@jtpio):
  • yes
  • no
  • abstain
• Michał Krassowski (@krassowski):
  • yes
  • no
  • abstain
• Martha Cryan (@marthacryan):
  • yes
  • no
  • abstain
• Mehmet Bektas (@mbektas):
  • yes
  • no
  • abstain
• R Ely (@ohrely):
  • yes
  • no
  • abstain

[jtpio]

following the discussion at the weekly call.

For context, would you mind linking to the meeting notes where this was discussed?

Maybe also to the issue or PR that added jupyter-ui-toolkit as a dependency to JupyterLab? Thanks!

[brichet]

This has been discussed during November 29, 2023 meeting, but there is no mention of the discussion in the notes #205 (comment).

The UI-toolkit has been introduced in Jupyterlab in jupyterlab/jupyterlab#15021, and was first admitted in #143.

[krassowski]

For context, the discussion started as an off-shoot of a discussion around a release blocker for 4.1 which is tracked in:

• Update fast stack to non-deprecated packages jupyterlab#15456 (in jupyterlab)
• Update fast stack to non-deprecated packages jupyterlab-contrib/jupyter-ui-toolkit#79 (originally)

I would appreciate a confirmation on what is the plan to address the above issue before I cast my vote.

[mbektas]

It is worth mentioning that we have been using jupyter-ui-toolkit for quite some time in JupyterLab Desktop as well.

[ivanov]

I'm abstaining from the vote, but want to repeat and reframe my earlier sentiment on moving projects to jupyter organizations: can we please provide more justification behind moving projects than just "we are using this"? It's perfectly fine for jupyter project to use libraries that aren't part of the jupyter organizations.

[fcollonval]

I'm abstaining from the vote, but want to repeat and reframe my earlier sentiment on moving projects to jupyter organizations: can we please provide more justification behind moving projects than just "we are using this"? It's perfectly fine for jupyter project to use libraries that aren't part of the jupyter organizations.

I added the following in the top comment:

To provide more background, the toolkit is today in the JupyterLab community organization that is not officially endorsed by Jupyter. So moving it in this organization will ensure official support for maintenance and publication rights. In addition it will allow some members to contribute as they may not be allowed to do so on the community organization due to company policy.

[ellisonbg]

There are a couple of other points that I think would be helpful to understand:

• Can you summarize the status of Fast (the underlying toolkit) and our usage of it. I know Fast itself doing quite a bit of refactoring and would like to understand where all of that is at.
• We had tried to use Fast for the Jupyter Scheduler work (just over a year ago) and found it to be poorly documented and difficult to use. Has that been addressed. Has that situation improved?
• How mature is the jupyter-ui-toolkit? Is it to the point where we should require it in JupyterLab/notebook? The text of the proposal is ambiguous on this point and sort of suggests that moving it to the JupyterLab org will mean that we are officially endorsing and recommending it for all things Jupyter.
• There have been a couple of other situations where we brough new repos in, but believed they were not fully mature and stable (Jupyter AI, pycrdt). In these situations we tagged them (in the README) as being under incubation to help set expectations. Does that make sense here?

[fcollonval]

* Can you summarize the status of Fast (the underlying toolkit) and our usage of it. I know Fast itself doing quite a bit of refactoring and would like to understand where all of that is at.

The utilities to create custom elements (aka web components) and handle their rendering lifecycle are being updated. But it does not impact consumers of the toolkit. The current status is unfortunately though to provide as the project as be slow since a year.

* We had tried to use Fast for the Jupyter Scheduler work (just over a year ago) and found it to be poorly documented and difficult to use. Has that been addressed. Has that situation improved?

Fast is an internal dependency of the toolkit. We should not advertise (at least in the short term) the internal tool used by the toolkit. The goal of the toolkit is to provide components on a shell and to consume them either through a framework like React or using vanilla JS. The demo project shows how you can consume the components with vanilla JS or with React. It does not need anything from FAST libraries.

* How mature is the jupyter-ui-toolkit? 

It is; see thoses extensions using the vanilla components or the React variant. It is also used in JupyterLab desktop - to highlight its power to be integrated anywhere in the opposite of React only toolkit.

The text of the proposal is ambiguous on this point and sort of suggests that moving it to the JupyterLab org will mean that we are officially endorsing and recommending it for all things Jupyter.

Not for all things in Jupyter (although it would be for the best). But yes for JupyterLab and yes we (the JupyterLab team) are endorsing it by definition of all projects within this org.

* There have been a couple of other situations where we brough new repos in, but believed they were not fully mature and stable (Jupyter AI, pycrdt). In these situations we tagged them (in the README) as being under incubation to help set expectations. Does that make sense here?

It will surely needs changes when more components are used within core. So not problem with tagging it as WIP.