owned this note   changed 4 years ago  
Linked with GitHub

JupyterLab Weekly Meeting Minutes - Archive Oct 19 - June 2020

09 October 2019 - 24 June 2020

Future Meeting Note

https://hackmd.io/Y7fBMQPSQ1C08SDGI-fwtg

Archive July - Oct 2020

https://hackmd.io/P1Y_TM2WSxOENvQzWVsnvw?view

24 June 2020 Weekly Meeting

17 June 2020 Weekly Meeting

10 June 2020 Weekly Meeting #ShutDownSTEM edition.

  • Why we're doing this.
  • Suggestions from https://www.shutdownstem.com/
    • Education: If this is new to you, start reading the resource materials; these exist and you need to learn from them. Keep learning by reading books and blogs, watching movies, listening to podcast and following the suggested people on social media.
    • Action: Take responsibility to be actively anti-racist in your spaces of influence. You need to change how things are done and support organization that are continuing this work.
    • Healing: Racism creates this toxic space and those affected need to heal from it. We need to make time and space for this emotional work to occur.
  • What is JupyterLab's role in all this?
    • What actionable steps can we make as a team?
      • All take a book from the beginners list and present a summary of what we learned
        • Steve has "How to Be an Antiracist" on audio
      • All take an episode from one of the recommended podcasts and present what we learned
      • Consider attending a course like Introduction to Being an Antiracist (Steve has already signed up - email at steven.silvester at gmail dot com or Atlanta @ devopsdays.org if you need your cost covered)
      • Encourage our employers to sponsor events like DISC or provide travel so we can attend
    • What is the impact of JupyterLab software on these systems?
      • Can we move that impact in any positive way?
      • Are there any pitfalls to be aware of?
    • Are there any things we can take back to our employers?
      • Adding organizations to the list of charities that employers will match funds for.
      • Short Term: Give employees time off to join protests.
  • Notes
    • On data anlysis that picks up on and perpetrates racist signals.
      • The first line of defense her is how data scientists are trained.
    • What can we do that's positive?
      • We can do a https://covid-oss-help.org style website to prioritize people who are working on anti-racist data analysis to push them to the front of the line for getting help.
      • Working to keep getting diverse groups of new contributors and helping get people involved who otherwise wouldn't have the oppourtunity.
        • Career launchpad - Intership with follow up steps that helps students have a path to working in Jupyter.
      • Increase the demand on a more diverse work force that puts upward pressure on the supply.

03 June 2020 Weekly Meeting

  • Brian
  • Wei Ouyang
  • Saul Shanabrook
  • Steve Silvester
    • Picking back up the extension system refactor. We influenced the design of Webpack to provide exactly what we would have built ourselves to solve our problem
  • Athan Reines
    • What is the status of evaluating potential ToC integration into core?
    • Should we hold off on any further feature development or go ahead?
  • Jason
    • Also picking back up the extension system refactor. Excited about the recent webpack developments.
  • Additional Discussion
    • Where do we stand on thinking about the classic notebook mode for JLab?
      • What is the delta between Classic Mode and Single Document Mode?
      • Pieces of Classic that are important:
        • Allow /tree/ interactions. (multiple browser tab experience.)
        • Make it look more like classic mode?
      • Tasks:
        • Improve Single Document via CSS.
        • Restructure UI to have more whitespace and use side drawers.
        • Work on multi-tab experience.
        • Experience surrounding switching between modes.
        • Explore single document mode for other activities.
    • Should we add Eric as a core committers?
    • How should we add new core committers?

27 May 2020 Weekly Meeting

20 May 2020 Weekly Meeting

More discussion:

13 May 2020 Weekly Meeting

  • Vidar

    • Made a script for whether published checking lab extensions support the latest version of lab. Current results:

      Up to date (193)
      Outdated (379):
      Support ends at v2.x: 3
      Support ends at v1.x: 173
      Support ends at v0.x: 203

    • Will put it in team compass

  • Max

  • Alex

  • Saul

    • RTC meeting time:
      • When is ipywidgets meeting time?
      • after voilla meetings everyone
      • Calender
      • RTC repo
      • gitter
      • Team compass
    • proposal for standardizing versioning process
      • https://github.com/jupyterlab/team-compass/pull/54#discussion_r424366374
      • Questions:
        • Can/should we allow bumping versions of different sub packages
        • things shouldn't be in lockstep? This would make things easier for extensions, because jlab forces singletons of these packages.
          • rendermime
          • coreutils
        • As we go, the hope is that we become more stable as we go so we have less breaking changes.

  • Additional Discussion

    • Details of Provisional Features

06 May 2020 Weekly Meeting

29 Apr 2020 Weekly Meeting

  • Steve
  • Eric
    • JupyterLab as Server Extension PR1 and PR2 on Jupyter Server 0.3
      • Only Windows JS test fail on GitHub Actions
      • Need to align across jupyterlab/jupyter-server/nbclassic supported python version (3.5, 3.6, 3.7, 3.8) and platforms (linux, windows) combination
  • Max
  • Jason
    • Extension rework
  • Saul
    • Git branch/release flow
      • Discussed in this issue https://github.com/jupyterlab/jupyterlab/issues/8195
      • Have a current WIP RFC here https://github.com/saulshanabrook/team-compass/blob/master/rfc/development-cycle.md
      • Open questions:
        • Things would be a lot simpler if we just did an automatic release after every minor and patch PR merge. This should be fine with semver. I believe there was some pushback last time this came up. How strongly do people feel about this? What's the rationale? There are a lot of wins in terms of development time!
        • Can we bump all JS packages in unison, even for breaking changes?
          • are there previous discussions here?
        • Are the docs only deployed from master? Are we currently making changelogs for 1.2.x releases? Are these changelogs going into master?
  • Darian
    • Some thoughts on sunsetting classic notebook: feature parity, checking with other Jupyter projects
    • Lab on Mobile
      • Vidar: Do we need changes in Lumino?
  • Additional Discussion

22 Apr 2020 Weekly Meeting

Aditional Discussion:

  • Meeting about federated build

15 Apr 2020 Weekly Meeting

Aditional Discussion:

  • Favorites UI resourcing?
    • Shreya do you have funding to help support this work, even if you don't have time yourself?
    • Or is someone here volunteering to take this on and support it?
    • Usually things that are brought into the jupyterlab core have someone who is responsible for maintaining them.
    • It's unclear to me if anyone in core has spare resources to devote to this. I would't want it to just be something added to our plate and us not have enough time to maintain it.
    • Result:
      • Basically we won't put a lot of resources into improving it neccesarily, but can allow new contributions and act as shephards for new maintainors. Also increases visibility of project

08 Apr 2020 Weekly Meeting

  • Eric

  • Ed

  • Saul

    • Things have been released…
    • A few questions on releasing…
      • How do we get to end goal of hitting a button to release on Github?
        • auto generate changelog, enforcing stricter syntax in PR description
        • figure out what backports should/could be done for each PR
      • How often do we release things?
        • If we can automate, it makes it less of a burden to actually do release
        • and so "when" it happens can be based more on first principles than on who is available (maybe?)
      • Should we be clearer about our intentions, both around getting PRs in and doing releases? So that we understand the conflicting priorities possibly between our employer's desires and the project's needs?
      • As a benchmark, this release took somewhere between 16-30 hours of Saul's time and 16-30 hours of Jason's time
        • changelog took maybe 12 hours total
    • Make an issue for Testing automation on releases

  • Jason

    • Exploring webpack module federation and other issues around the extension system rework
    • Will try to set up a meeting with at least Eric and Steve later this week to push forward

  • Darian

    • Debugger update

  • Tim

    • I would like to set up a meeting with UCI teams and stakeholders for Debugger and JupyterLab-FS/Data Explorer stuff.

  • Alex

Aditional Discussion:

  • Releases:
    • We released 2.1.0 and 2.0.2 (thanks Saul!)
    • We still have the beta freeze at 19 Jun 2020, so if you plan to work on a major feature, now is a good time to plan out the work.
  • New Zoom channel, takes effect next week:
  • Extension system rework
    • Concerns we are addressing:
      • Can we ship an extension that does not require a post-install phase that re-compiles the JupyterLab application? In other words, can an extension be a simple set of static assets that resides in a well-known location? Can I untar some file into a directory and refresh the page and have it magically work?
        • System is not magic for extension authors: Giving extension authors more control over the environment their code is built in, before being run in the browser, would be useful. For example, currently we run all extensions in our webpack config. This is an issue, if extensions have their own config they would rather run. It's also confusing for them, because the post install build step is opaque and not documented. So when it fails (as pointed out above) we get weird issues. Also, it fails on user machines, not extension athors machines, which is even harder to debug.
      • Track versioning between frontend extensions, backend extensions, jupyterlabs server versions, jupyterlab version. We currently have two package manager resolutions working seperately. It would be nice if we could just use one to properly resolve versions between frontend and backend code and extensions.
      • One package per extension, even if that involves both a frontend and backend component
      • A way to minimize the download size for clients on slow networkd
      • debuggability
      • Make it easier to develop multiple extensions independently
      • allow for the creation of seperately deployable built artifacts from each extension

03 Apr 2020 Extension system refactor

Resources

  • Steve has some design time
  • Saul has some time to work on design discussion
  • Jason has some cycles
  • Darian can test, research, put some time into discussion

Primary win:

  • end users don't need node and internet access
  • packaging is easier - you package up a single "binary" with all dependencies

Timeline:

  • Beta slated for June 2020, so we have about 2.5 months

Approaches:

  • We could have two modes, a compiled mode like we have now, and a totally amd-based solution (where we could concatenate multiple amd modules into a single requested file).
  • Webpack federated modules

First steps

  • Identify the concerns we are solving and prioritize those
  • Investigate the webpack federated modules as a possible new technical alternative

01 Apr 2020 Weekly Meeting

Updates

  • Max
  • Jason
    • Help Saul with JLab 2.1/2.0.2
      • Thank you! - Saul
    • Start planning for extension rework work for 3.0
  • Saul
    • Release party this week!
      • 2.1.0 alpha release is out, please test!
      • plan: 2.0.2 release on thursday
      • another 2.1.0 release on thursday as well
      • 1:30-3pm EST on thursday
    • Working on a cross interface mime renderer abstraction, to make it easier to write comms based renderer
  • Luciano
  • Eric
    • Extensions Manager: Black/White Listings + Badges released in 2.1.0-a.0: Thx Saul and Steven for reviews and merges!
    • Jlab on JServer: WIP with Zach to align on latest Server branch

Additional Discussion

  • 2.1/2.0.2 plan
  • Planning meeting for extension rework (see #5672 and #7468)
  • Which restart-and-run icon: #8091 or #8136?

25 March 2020 Weekly Meeting

Updates

Additional Discussion

  • Should we have a policy for how to warn about JS deprecations (e.g. console.warn() on access)? See
  • Release plans:

18 March 2020 Weekly Meeting

  • Please introduce yourself when it's your turn.
  • Tim
  • Darian
    • Minor PR to include .yarnrc
    • Jupyter governance work is proceeding well.
    • Debugger 0.2 target release this Friday, 1.0 to either ship with JupyterLab 3.0 or coincide with its release
  • Max
  • Eric
    • Black and White listings: Dev done (specs by Tim and Mars, reviewed by Saul) PR1 PR2. Open for 1 or 2 weeks for review, then candidate for merge.
    • Extensions splash screeen to be planned.
    • Once merged, we can enable the extension manager by default.
  • Vidar
    • More extensions lab 2.0, all good still
  • Additional Discussion

11 March 2020 Weekly Meeting

04 March 2020 Weekly Meeting

  • Introductions
  • Tim
  • Steve
    • Released 2.0.0 and 1.2.7
    • Updated and released jupyter-renderers for 2.0
  • Eric
  • Jeremy:
  • Alex
    • Helping update TOC to lab 2.0
    • working on a lab-git issue
    • no work on lab linter yet
  • Ed (Kite)
  • Darian
    • Source-only version of PyPI package was missing package_data and now it is not (which is part of why Steve published 1.2.7), but it still ignores dot files unless we explicitly add them. This matters because of .yarnrc
  • Saul
    • Had a fun time with Glue folks last week in NYC
      • Built a lil demo for them on building dashboards in jupyterlab https://github.com/Quansight-Labs/jupyter-widgets-takeover#jupyter-widgets-takeover
        • I can demo this
      • TLDR is blurring lines between "dashboard" and "notebook", need ways to start users in constrained environment and then move slowly to less contstrained
      • Many technical next steps to make this viable
      • Conflicting with curent Voila stack. Might be nice to chart out unified best way forward if possible
    • Working on performance improvements on switching between notebooks
      • profiled, mostly in style updates
      • going to try to do virtualized dom to update
      • strategy is to not change any API for output widget but under the hood put a later of React in the middle between two layers of Lumino widgets
      • Then use react virtualized library
      • https://github.com/jupyterlab/jupyterlab/issues/4292
      • Here is an in-progress discussion about a web standard that enables native browser virtualized scrolling for some cases: https://github.com/WICG/display-locking/
      • At one point Jason explored making a Lumino widget for virtualized scrolling. No code to show for it, but Jason would be interested in discussions around this.
  • Jason
    • Helped with changelog and fallout from 2.0 and upgrading and migration challenges
    • Upgrading custom widget packages for jlab 1 and 2 turns out (through a lot of work :) to be as easy as adding ||^3 to @jupyter-widgets/base dependency version.
  • Luciano
    • Helping releasing JupyterLab extensions that support JupyterLab 2.0
      • TOC for Lab 2.0 release by end of the week
      • Git for Lab 2.0 (Any ETA? I could help with release by end of the week as well)
  • Max
  • Zach
    • NBClassic: add Jupyter Server / Notebook config shim layer.
    • Add a simple class to jupyterlab_server for a "transition period" that manages config shims.
    • Remove this class after transition period ends—little disruption to Jupyter Lab.
    • https://github.com/Zsailer/nbclassic/pull/7
  • Aditional Discussion:
    • Release meeting you're interested in this meeting you please put your name below, and I'll reach out to schedule the meeting
      • Tim @tgeorgeux
      • Max @telamonian
      • Saul @saulshanabrook
      • Vidar @vidartf
      • Steve @blink1073
      • Brian @ellisonbg
      • Darian @afshin
      • Luciano @lresende lresende@us.ibm.com
    • Extension Manager.

26 February 2020 Weekly Meeting

  • Introductions
  • Saul
  • Alex
    • Helped my teammates on work on the TOC and git extensions
    • Will most likely start looking at Lab lint this week
  • Martha
    • Working on updating TOC extension to 2.0 rc1
    • Working on making TOC compatible with python files
  • Steve
    • Fixed RTD build
    • Reviewed PRs
  • Max
    • icons are all fixed up now
    • new icon styling system, try it out and give me feedback
      • see docstrings in ui-components/src/icon/labicon.tsx and ui-components/src/style/icon.ts
    • starting work on multi-contents manager
  • Darian
  • Jason
    • Released 2.0 rc1 and rc2, updated changelog, etc.
    • Continued working on porting ipywidgets to jlab 2.0 and making a release plan coordinating ipywidgets and custom widgets releases for jlab 2.0.
  • Eric
  • Additional Discussion
    • JupyterLab 2.0 final timeline?
      • RC2 released yesterday
    • Acknowledgments
      • provide a way to acknowledge individuals and sponsoring organizations
      • easy to keep up to date (or clearly point-in-time so no need to update)
      • provides visibility to incentivize contributions and sponsorship
      • in interest of fairness, has a clear decision criteria for an acknowledgment
      • two current proposals:
        • a special acknowledgements file that is kept up to date manually
          • harder to keep up to date
          • subjective criteria for inclusion
        • an acknowledgement in the changelog and/or release blog post
          • clearly point-in-time, but harder to update ex post facto
          • subjective criteria for a big callout, but can also easily include all contributors

19 February 2020 Weekly Meeting

12 February 2020 Weekly Meeting

  • Introductions
  • Darian
    • Checked out the Lumino UMD branch to play with examples. Not sure what I was doing wrong…
  • Steve
    • Working with Max on icon finalization before cutting final release - some Lumino packages were bumped
      • Tentative ETA? I believe we have a dependency on these and we wanted to try these before GA.
  • Jason
    • Working on ipywidgets 8. Good news is I think we actually can release a jupyter lab manager that allows us to have ipywidgets 7 in jlab 2.0, so pressure is off for people to migrate.
  • Saul
  • Max
  • Aditional discussion

5 February 2020 Weekly Meeting

  • Introductions
  • Tim
    • Working on Command Palette and in-Cell UI for 3.0
  • Darian
    • Another debugger 0.2 alpha release this week
    • Question about FontAwesome
    • Update on governance / question for discussion
  • Steve
  • Alex
    • Was working on moving our extensions onto the 2.0 beta/rc specifically becoming familar with the new LabIcon work. Starting this week will be setting time aside to work on jupyterlab issues specifically (not just our extensions) -> open to direction
  • Gordon
  • Jason
    • Working on ipywidgets 8 (and JupyterCon, etc.)
    • FYI, zmq has default "high water mark" of 1000 messages, after which it can start dropping messages, so if you ever are in a situation where you have a lot of messages coming from the kernel and some are dropped, think about the zmq buffer (1, 2)
  • Max
  • Vidar
  • Additional Discussion
    • When to Freeze API for 3.0 release.
      • Should we appoint a release manager and let them take input and make a final decision?
      • We will hold a meeting about this post-2.0 final release.
    • Governance questions re: delegates
    • Lumino packaging UMD (min files / sourcemaps / types)

29 January 2020 Weekly Meeting

  • Max
    • icons!
      • #7767 is done, there's also some docs
      • where should dev docs go?
    • should we have a core-interfaces package?
  • A. T. Darian
  • Tim
    • No updates - Hiring interns.
  • Jason Grout
    • continued work on ipywidgets targeting 8.0 release shortly after JLab 2.0 (needed for support).
    • Small PR moving the notebook logging to the notebook extension. Could easily be moved to 3.0.
  • Steve Silvester
    • Released a beta3 and 1.2.6 last Friday with a bug fix for extension authors using our CI helper
    • Working with Max on the icon refactor
    • Finished initial exploration of module transpilers and loaders, need to type notes
  • Saul Shanabrook
    • JupyterLab 2.0 issue text:

      • JupyterLab 2.0 is currently in beta and will be released soon. If you have an extension for JupyterLab, you will likely need to release a new version for it to be installable in the new version. To test your new extension with JupyterLab 2.0, you can install it with pip install --pre jupyterlab and then try to install your extension.

      • We have put together a guide on the latest docs on things you need to change to update: https://jupyterlab.readthedocs.io/en/latest/developer/extension_migration.html

      • If you encounter other things that you need to change, please submit a PR to that document!

    • Adding "History" section to JupyterLab git
    • Updates on CZI grant
      • Fernando gave some comments, suggested we include real time commenting
      • Will send out a version later today after I edit for any comments to whoever is interested
      • Google Doc
  • Luciano
    • Volunteering to help migrate TOC extensions to JupyterLab 2.0
  • Addtional Discussion
    • RC and release
      • Jason thinks we should have at least week between first RC and final release.
      • We need to push in major changes earlier so we have time for them to bake. As we get closer to beta/api freeze, we should be more conservative about merging major changes.
    • Release process
      • We will schedule a seperate sub-group

22 January 2020 Weekly Meeting

  • Darian
  • Steve
    • Experimenting with JS loaders and transpilers. Will write up findings and recommendations
    • Investigating a strange bug affecting our browser_check (in core and for extensions)
  • Jason
    • Mainly been working on ipywidgets. Upgrading it to JLab 2.0 has worked great. There was a small subtle issue dealing with kernel startup being different now (i.e., no .ready anymore), but it is simpler code now than before, I think.
    • On ipywidgets, we've switched to GitHub Actions and it is great.
  • Luciano
    • Finally able to make progress with JupyterLab 2.0 extension migration and trying to look into small ui side effects (e.g. icons, output areas).
      • Lots of changes related to new KernelManager infrastructure/API.
      • Will start contributing to Darian's PR and Blog based on my (our) experience.
    • Released notebook 6.0.3, so it works with Python 3.8 on Windows now!
  • Max
  • Additional Discussion

15 January 2020 Weekly Meeting

  • Tim

  • Vidar

    • Widgets workshop
    • Some small refactor PRs

  • Darian

    • Added Lumino lm-* namespaced events, selectors, and data attributes to JupyterLab
    • Made one final 0.1.x release of @jupyterlab/debugger before switching to JupyterLab 2.
    • Working on narrative(ish) blog post for extension migration. Plan on finishing it this week.
    • Follow up meeting with Kite folks to talk about completion API

  • Steve

  • Saul

    • Two meetings coming up on Friday:
      • RTC Grant Call Friday, January 17, 12-1pm EST
        • jupyter zoom
      • Kite Integration Call Friday, January 17, 1-2pm EST
    • Show what companies funded what work? "Sponosored" branding? (our client wants some marketing)

  • Eric

  • Alex

    • Trying to understand how TabBar handles Signals in lumino, would appreciate insight (first caught tabClose signal clears remaining callbacks)

  • Addional Discussion

    • Ship UMD in lumino?
    • When should extension author port their extensions?
      • Announcement - Can extension installers port now?

      • Put this info in the Changelog under an extension Developer heading << Now is the time to check it works locally, open a PR; then for 2.0 merge and release.

    • How should we recognize companies pouring money into JupyterLab development?
      • two sigma and bloomberg helped support jlab debugger, this will go into blog post.
      • README and changelog branding?
      • For now, write a blog-post with a Jupyter Dev.
    • JLIcon
      • Remove backwards

8 January 2020 Weekly Meeting

2 January 2020 Weekly Meeting

18 December 2019 Weekly Meeting

11 December 2019 Weekly Meeting

  • Saul
  • Jason
    • Finishing up kernel services refactor
  • Steve
  • Vidar
    • Strict null checks incoming (since we now have partial JSON structures in Lumino). Starting with coreutils to do this piecewise (limits risks of merge conflicts, and piecewise reviews are better)
      Image Not Showing Possible Reasons
      • The image file may be corrupted
      • The server hosting the image is unavailable
      • The image path is incorrect
      • The image format is not supported
      Learn More →
    • Want to help Jason get the kernel services refactor done
  • Luciano
    • Working on dependency updates
      • Updates to script are ready to review #7599
      • Updates to dependencies are mostly done, pending codemirror build issues #7590
  • Tim
    • Wrapping up UI tweaks to include in 2.0.
    • Final UX review for Celltags
  • Max
  • Alex
    • Opened PR #7611 addressing transient file editor configs as discussed last week
  • General Discussion
    • Refactor coreutils somewhat? Polling is upstreamed to Lumino, should we extract any other parts into separate packages?
    • Community Workshop CFP deadline Dec 15!
    • When is 2.0 RC target? 20 Dec 2019 Beta, RC 6 Jan 2020.
    • ipykernel vs xeus https://github.com/jupyterlab/debugger/issues/274

4 December 2019 Austin Dev Meeting Edition

  • Packaging
  • RTC Find more info here
    • Lumino datastore and existing RTC libraries.
    • Current issue with lumino datastore
      • Unpaired surrogates
      • ID generation
    • Where to put all the code we're working on?
    • Should we require node on the server side?
      • We need a definitive yes or no on whether to include this.
      • Pros:
        • Enables us to move notebook state to server.
        • Can forward kernel messages to the datastore on the server side.
        • Can have a server side datastore client.
        • Datastore is written in nodejs.
      • Cons:
        • Have to ship node.
    • Protocols on top of REST
    • We can keep moving in the same direction for now, and move it to python later if we need to.
    • ID Generation
      • Datastore utils package is bisecting the inverval?
        • SQRT is making things more uniform, but not fixing altogether
        • We could use a uniform spacing for a set of ID's across a given range.
    • Next steps:
      • Keep exploring in node for now.
  • UI Components
    • Add Storybook
    • Remove Blueprint
    • Add Material UI for complex components only. (Eg. dialogue boxes)
      • Pros:
        • Gives us access to much better modal dialogues.
        • Porting is less work than building certain complex components from scratch.
      • Cons:
        • Another dependency
        • Because they're meant to be general purpose they're extrodinarily complex, but they're complex enough to use in ways that completely break accessibility.
          • Also there's a burden that's a basic button class we have in JupyterLab it's very small.
          • Blueprint and Material UI buttons have many more props.
    • What we want in a JupyterLab UI Framework.
      • Simple components with small # of props.
      • Possible to work with Accessibility.
      • Specifically applies to JupyterLab only, doesn't need to be general purpose.
    • Next steps
      • Add Storybook
      • Go through and remove blueprint components with Custom JupyterLab components.
        • Brian has a design contact for accessibilty at Amazon that can review components.
        • Don't bring bagage from Blueprint Props into the new components.
    • Future Steps
      • It's not objectionable to use Material UI for more complex components that would require a lot of work for us to replicate.
  • Recording notebook timings
    • Currently there's a notebook metadata option to record timing.
    • New step will be having a Jupyterlab-wide setting to turn notebook timings on or off.

20 November 2019

  • Tim
    • Continued discussion from last week:
      • Tests: Azure, Github, Travis?
  • Darian
  • Steve
    • Created and released lumino packages 🎉
    • Checklist to move over to using lumino
      • We are blocked on using them in JupyterLab until we have API docs for lumino
      • Yarn resolutions
      • Update names in jupyterlab
  • Saul
  • Vidar
    • Looking further at api-extractor / api-documenter. Probably going to try for lumino first, then lab afterwards if applicable.
  • Max
  • Brian
    • Working with Steve on the lumino fork (ok, I just talked to him)
    • Will be remote for the Austin meeting.
    • Should we commence a weekly lumino call?
    • Let's begin to open issue on lumino to spec out where we want to take it in the short term and long term.
    • Race conditions in the Jupyter server.
    • Jupyter Community Workshops! Deadline is 12/15 for submissions.
      • JupyterLab?
      • Accessibility?
      • Maintenance (tech debt)?
    • Accessibility critical mass.
  • Jason
  • Additional Discussion Topics
    • @jupyterlab/debugger in core for 2.0?
      • Targetting 0.1 release for December (depends on having the xeus-python Kernel).
    • @jupyterlab/shortcutui in core for 2.0?
    • Discuss Austin meeting if we have time.
      • Daily 10 AM (Austin Time) meetings to set up for the day on https://zoom.us/tgeorgeux (Excluding Tuesday)
      • Tuesday 10am (CT) is a presentation on JupyterLab to a seminar over video conference
      • Add video channels to topical discussion as we can.
    • Should we link back to phosphor issues on lumino?
      • For small discussions, probably not.
      • For larger discussions, case by case.
    • Lumino Readme Copy (or perhaps a very abbreviated mention is in the readme, with something like this in the changelog?):
      • Lumino was originally developed as a framework for JupyterLab, much of the code originated in the PhosphorJS repo. The project is officially a part of the JupyterLab org now!
      • Lumino was originally developed as a foundation for applications like JupyterLab under the PhosphorJS name. When the main developer of PhosphorJS retired from open source in November 2019, the other PhosphorJS maintainers continued development as the Lumino project as part of Project Jupyter, under Jupyter governance and Jupyter code of conduct.
      • Lumino is a toolkit for building extensible and high-performance browser applications like JupyterLab. Lumino is a Jupyter project, under Jupyter governance and Jupyter code of conduct. Lumino was formerly known as PhosphorJS.

13 November 2019

Further Discussion:

  • (Carry over to next week) The future of tests:
    • Azure? Travis? Github?
  • Phosphor fork name possibilities (needs to be available as an npm org)
    • @sol
    • @solar
    • @lumino
    • @lightstick
    • @glowstick
    • @glow
    • @lumo (esparanto)
    • @lux (latin)
    • @luce (italian)
    • @marama (maori)

6 November 2019

Further Discussion:

  • Phosphor repo archived.
    • Team Compass issue to be followed up by gitter comments.

30 October 2019

  • Vidar:

    • RTC sprint with Darian
    • Jupyter server for 2.0?

  • Darian

    • RTC sprint with Vidar
    • Short debugger update

  • Steve

    • Exploring the concept of environment-aware JupyterLab

  • Max

  • Tim

    • Working on Design Debt.
      • Adding "atoms" to JupyterLab Design System.
        • Can we add the design assets to the repo?
          • Yes. Let's tie them to JupyterLab Releases.

  • Mike

    • Working on jupyterlab-lsp, will open an issue on the future of the integration with Jupyter project organizations / JupyterLab core

  • Discussion Points

    • Question about @jupyterlab/coreutils#Poll et alia possibly in PhosphorJS: Next time there is a major version change in @jupyterlab/coreutils, move Poll and its relatives into a separate @jupyterlab/poll package.

23 October 2019

15 October 2019

09 October 2019

  • Vidar:
    • Mostly reviewing various bits and pieces.
    • Saul had an interesting point about making it easier for rendermime renderers who use Comm to get access to that, vs phoila (Phosphor Viola) https://github.com/vidartf/phoila/issues/7
  • Steve
  • Jason
  • Tim
    • Ongoing work on protype icon system for MIME types.
      • If this works out we will have a better lookings icon set for JupyterLab.
  • Max
  • Discussion
    • in-person meeting venue
      • IBM Austin space available for the week of Dec 2-6.
        • PyData Austin is Dec 7-8
        • There is close food and a local contact.
        • Jupyterlab team hasn't been here yet.
        • We have tentatively decided on Austin, waiting to hear from others not on this call.
      • Bloomberg San Francisco space available for the week of Dec 2-6.
        • Will have catered Breakfast and Lunch.
      • Potentially JPMorganChase in NYC, but unconfirmed.
        • Jupyterlab team hasn't been here yet.
    • 1.2 release
      • Jason will put some cycles into 1.2 release to include log console and maybe some very high priority PRs.
    • Comm access for Phoila
Select a repo