22 July 2020 JupyterLab Weekly Team Meeting

[tgeorgeux]

22 July 2020 Weekly Meeting

• Steve
  • Module federation progress - heads down on this for at least the next week
• Tim
  • Jose is from the setting UI team for UCI
• Jose
  • Settings UI, research phase done, Design Phase taking place in this issue.
• Darian
  • Debugger conversation: Merge @jupyterlab/debugger into JupyterLab core #75
• Luciano
  • Would like to hear from others about direction from Microsoft regarding removing Jupyter support in favor of VSCode.
    • On October 9, 2020 the Azure Notebooks public preview site will be retired and replaced with integrated services from Visual Studio, Azure, and GitHub
    • See also Microsoft alternatives
    • Current marketshare of VS Code based on Stack Overflow Survey
• Eric
  • Initial VIM support in cell editors
• Jason
  • Working on module federation with Steve
  • JupyterCon CFP open - last day!!!
    • Suggesting making a Tutorial:
      • How to use JupyterLab proposal?
      • Creating JupyterLab extensions?
        • Volunteers: Alex, Martha, Max, Vidar (EU office hours), Tim (others?)
          • Max volunteered to write the proposal
• Additional Discussion
  • JupyterLab 3.0 timeline.
    • API Freeze Blockers
      • Extension System
      • Internationalization
      • Jupyter Server
      • Debugger
      • Single Document Mode (API portions already in?)
      • Content manager/factory
    • Possibilities
      • UI Refresh
      • Accessibility
      • ToC
      • JupyterHub (Replace LabHubApp entry point)
  • JupyterCon sprint.
  • Discussion around debugger.
  • Think about what are the next steps for 'how to keep up' in light of new decisions VSCode is making.
    • Have a monthly meeting around Product Management and product direction.

[choldgraf]

I would love to see notes from the conversations that @lresende brought up about vscode / microsoft. That is a topic of particular interest to me.

I can give my 2 cents quickly there: I think the question is whether "a development environment like VSCode can also be the best data environment". If the answer is 'yes', then it is going to be very difficult to compete with VSCode because MS has a bazillion engineers and a huge ability to push VSCode in front of people's eyeballs, and seems to have convinced people that it is "open source". If the answer is "a development environment like VSCode can do data, but an environment tailored for data will be better" then I think JupyterLab can be a nice complement to VSCode for data-focused workflows.

To that extent, it will be important to focus jupyterlab on the data scientist, not the developer, and make it clear that this is a distinguishing factor between it and VSCode. The recent efforts I've seen towards a single-document mode and attempts at improving the extension development workflow are a great step in that direction. Another obvious place to try and distinguish is that Jupyter stuff is truly open source and community-driven, as opposed to largely a microsoft product that happens to have many open source components underneath it.

I would also be curious to hear how other cloud providers think about VSCode. Do they see it as pure competition? Or something they'd like to adopt and use for their own products? It could be a way to rally support for Jupyter tools (as truly multi-stakeholder projects) from other companies.

[tgeorgeux]

@choldgraf that conversation is currently taking place in #80