# JupyterLab In Person Meeting 2019

The in-person JupyterLab meeting is an intensive code sprint focused on JupyterLab 2.0. We have a limited number of spots, with a goal of producing a JupyterLab 2.0 release candidate by the end of the week as well as a roadmap for the future.

## Monday Schedule

Groups:
* Merge into core:
* Shortcut UI - Darian, Tim (UX Review)
* Debugger - Darian
* Cell Tags - Max Klein review

* 2.0 triage:
* Darian
* Jason
* Tim
* Max
* Steve

* Kernel refactor:
* Jason

* Jupyter Server
* Eric
* Zach
* Kevin Bates (particularly kernel launch parameters)
*

* Prep for presentation tomorrow
* Tim
* Jason
* Zach

* Contents Management API/Data Registry conversation
* Zach
* Saul
* Max

* Team Structure
* Luciano
* Saul
* Tim

* Extension Building
* Max
* Saul
* Vidar
* Steve
* Luciano

* UI Components
* Tim
* Saul
* Max
* Brian
* Steps:
* Remove blueprint
* Add storybook
* Potentially add material UI

## Tuesday Schedule

### Morning
* JupyterLab demo call
* Governance call

* Lumino
* Vidar

### Afternoon

* Contents Management API / `DataRegistry`
* Max

* RTC Plan
* Saul
* Vidar
* Darian
* Steve
* We need to figure out:
* Should we use lumino datastore or another CRDT library? like https://github.com/automerge/automerge
* Two existing lumino datastore issues
* unpaired surrogates unicode
* paste issues (unicode ID lengths)
* maybe not production blocker
* Reason we created our own is because all existing libraries didnt have features and scalability
* Features:
* Mutable blob of text
* Type safety
* scalability of amount of clients
* Maybe Brian can give us more things we are looking for
* We could make a profiling suite to simulate inputs and see how long things take.
* Where to put this code?
* `jupyterlab/rtc-incubator` monorepo where we can put all of these parts
* Definitely seperate JS package for lumino that doesn't require Python or Jupyter
* Should we have a server side datastore client? And if so, should it be in Node or in Python?
* Patch server is just networking, doesn't need to know about patches.
* Should we require node?
* A number of LSP servers use node.
* It's not node that is causing our issues, but yarn and webpack.
*
* Tasks/questions
* Review other libraries
* Profiling for lumino datastore, so we can compare against other implementations
* Should we spend time reviewing another library or getting ours working?
* If we want to attract non JupyterLab users, we need to come up with a documentation suite and full examples.
* And we will have larger support burden.
* We could make a virtual layer to switch between lumino datastore and automerge.
* Can we require node to be installed?
* Can we write server side client so that we can use it in browser as well.
* Write it first for server side then see if there is user demand.
* Should we use another protocol mechanism instead of building our own on websockets and http.
* RPC / pubsub
* https://resgate.io/
* https://www.cncf.io/blog/2018/10/24/grpc-web-is-going-ga/
* https://wamp-proto.org/
* Replicated logs:
* https://github.com/automerge/hypermerge (https://github.com/mafintosh/hypercore)
* Potential next steps to discuss tomorrow:
* Create new repo
* Create issues on it

* JupyterLab Themes and other ui customizations
* Luciano
* Alex Bozarth
* Alex Swain

## Wednesday Schedule

* `@lumino/*` major release cadence discussion (Steve, Darian, Jason)
* At most, two major releases per year, more likely one.
* We should use JupyterLab as a proving ground for libraries that may migrate up to Lumino, *.e.g.*, `@jupyterlab/coreutils: Poll`

* Dev call
* RTC
* Created jupyterlab/rtc repo
* Added more notes here https://github.com/jupyterlab/team-compass/issues/30#issuecomment-561782241

* UI Components
* Add storybook
* remove blueprints components
* potentially add material UI
* Record notebook timings
*
## Thursday Schedule

* Jupyter Server dev meeting

* Lab Internationalization and translation capabilities
* Luciano
* Alex
* Jason ?
* Git extension roadmap
* Luciano
* Athan
* Max
* Alex

## Friday Schedule

* Kernel refactor work done by mid next week and then release a 2.0 alpha
* Jupyter server tests are still being fixed, then release of 0.2
* After that do a refactor using "kernel providers".
* Kevin bates has a proposal open for parameterizing kernels, that people should look over
* Open cell tags PR to JupyterLab core from intern work
* Moved over JupyterLab to Lumino
* Work to get keyboard shortcut UI into core, by disabling shortcuts when in this UI
* Plan for next core meeting is to have a community workshop and try to encourage calpoly interns. So we should be aware of location and time when scheduling next meeting
* Published new version of the JL debugger package
* Git extension UI/UX improvements
* Using rxjs observables in datastore
* Looking into collapsed cells in JupyterLab, outside of ToC extension
*

## Topics

### UI Components & Lumino
We need to discuss the interplay between Lumino and React, and decide on whether it makes sense to leverage a UI library such as Material-UI or build from scratch for acccessibility purposes.

### 2.0 release candidate

A primary goal of the week is to ship a release candidate of 2.0. This includes a UX and documentation review.

### Testing

If we still are having sporadic failures in a testing framework, this is a good time to finally clean those up.

### Versioning and backports

Cadences, what should each branch track, backwards incompatability, monorepo

### Team Roles

Defining different team roles like, issue triager, release manager, etc. So that we can make these roles more accessable to others in the community and get more help for them

### Jupyter Server
Work on moving JupyterLab to Jupyter Server

### Plan for 3.0

We are scheduled to ship JLab 3.0 in June 2020. What should be in it?

Can we set a direction for jupyterlab to focus on that addresses user needs? https://discourse.jupyter.org/t/benefits-of-the-classic-ui-and-use-cases-for-classic-over-jupyterlab-was-why-is-tim-not-moving-to-lab/2419/6

### Extension building

### RTC

### Contents manager API/Data registry