owned this note changed 4 years ago
Linked with GitHub

JupyterLab 4.0 Roadmap Planning

https://docs.google.com/spreadsheets/d/1r6_ySd18xZwfPexdmlkdFhHUWynaza0zXjrxMMIoLWw/edit

  • Prioritization of features we want should not preclude any open source contributor from working on something different if they feel like it. It should instead indicate a focus area for an upcoming release.
  • Roadmap needs to include both prioritization of features, and lay out of tentative release timeline, addressing competing

Rubric scoring

Focus of this exercise: users and extension authors. Important enough for release notes or a blog post.

List items that you imagine seeing as highlights in the 4.0 release notes or in the 4.0 blog post. Not all items in 4.0 are listed here, and the items here focus on the things we communicate to users or extension authors (for example, work on continuous deployment or testing infrastructure for JupyterLab itself is not among these items).

This is a decision-making tool, not a fixed-in-stone prioritization. The scores are used to help inform and guide decision discussions, and are not

  • Reach
    • 1 Some existing users or extension authors will use this
    • 2 Most existing users or extension authors will use this, but it probably will not attract many new users or extension authors
    • 3 Almost all existing users or extension authors will use this, and a significant number of new users or extension authors will start using or authoring extensions for JupyterLab because of this.
  • Impact
    • 1 Minor improvement to the way users or extension authors are able to leverage JupyterLab. Affects a relatively small part of the JupyterLab experience.
    • 2 Moderate improvement to the way users or extension authors are able to leverage JupyterLab. Major impact on a single critical extension, or moderate impact across a number of extensions.
    • 3 Major improvement to the way users or extension authors are able to leverage JupyterLab. Deep changes that affect a major part of the overall JupyterLab experience.
  • Effort
    • 1 Can be done by a single developer in less than a month.
    • 2 Can be done by a single developer over several months.
    • 3 Requires more than one developer over several months or longer.
  • Contributor Interest
    • Please add your GH username here if you plan on working on this (comma separated). Add your name here if you are planning on engaging with this work in a significant way (development, design, substantial review).

Time Budget

Proposal: Release 4.0 by Dec 1

Lessons learned from 3.0 release

  • Because the RC was much longer than anticipated, we saw a number of new features being merged in the RC as there was this tension between stabilizing some critical features and holding back on new things.
    • Suggestion: Branch when you do the RC so mainline development is not held back while things stabilize
  • Targeting two major releases in one calendar year is too aggressive for 2021. This is something we can revisit next year, but for 2021, targeting one major release (namely 4.0) is about as ambitious as we can hope to be.
  • In-person meetings can aggressively accelerate development and decision making.
    • Suggestion: (hopefully?) have an in-person meeting when we can in 2021
Select a repo