From c5d4b98f8db679f39079b32dcbf2fdef662b50ca Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Sun, 2 Apr 2023 01:12:00 +0200 Subject: [PATCH 1/6] Reviewed JEP process --- jep-process-v2/jep-process-v2.md | 164 +++++++++++++++++++++++++++ jep-process-v2/jep_status.drawio.svg | 4 + 2 files changed, 168 insertions(+) create mode 100644 jep-process-v2/jep-process-v2.md create mode 100644 jep-process-v2/jep_status.drawio.svg diff --git a/jep-process-v2/jep-process-v2.md b/jep-process-v2/jep-process-v2.md new file mode 100644 index 00000000..211c14c8 --- /dev/null +++ b/jep-process-v2/jep-process-v2.md @@ -0,0 +1,164 @@ +--- +title: Jupyter Enhancement Proposal +authors: | + Jason Grout ([jason@jasongrout.org](mailto:jason@jasongrout.org)), Safia Abdalla ([safia@safia.rocks](mailto:safia@safia.rocks)), John Lam ([jflam@microsoft.com](mailto:jflam@microsoft.com)), Kevin M. McCormick ([mckev@amazon.com](mailto:mckev@amazon.com)), Pierre Brunelle ([brunep@amazon.com](mailto:brunep@amazon.com)), Paul Ivanov ([pi@berkeley.edu](mailto:pi@berkeley.edu)) +issue-number: 27 +pr-number: 29 +date-started: "2019-02-23" +type: P - Process +--- + +# Jupyter Enhancement Proposal + +## Background + +Project Jupyter has an existing repository and process for “Jupyter Enhancement Proposals” or JEP for short. The repository is here: + + + +This format was originally used by [IPython (IPEP)](https://github.com/ipython/ipython/wiki/IPEPs:-IPython-Enhancement-Proposals) and continues to be used by the [Python Core language (PEP)](https://www.python.org/dev/peps/). As currently envisioned, JEPs are written documents, in the form of a Pull Request to this repo, which describes significant proposed units of work on the projects. The README of the repo summarizes this as: + +“Jupyter Enhancement Proposals will be used when presenting changes or additions that affect multiple components of the Jupyter ecosystem OR changes to a single key component.” + +Since the JEP process was created, Jupyter has grown in the number of users, diversity of usage cases, number of contributors, and number of repos/org. For a variety of reasons, the JEP process has not scaled with this growth. The current situation is characterized by: + +1. Given the scope of development, it is difficult to follow all of the activity; +2. As a result, most decisions are made in a distributed manner by local teams of contributors working on particular repos and orgs (hub, lab, ipython, jupyter-widgets, etc.); as a consequence: +3. Distributed decisions that affect the project as a whole are made, without all relevant parties being able to participate and contribute. +4. This is leading to fragmentation and slow progress in project wide concerns, such as the core protocols and standards of Jupyter. + +As a result, there is a need to revitalize and reorganize an efficient and robust centralized proposal and decision making process for major work units across the project. + +## Goals and Tenets + +Project Jupyter has adopted the Jupyter Enhancement Proposal process (JEP) to address distributed collaboration and experimentation as the project scales in the dimensions of contributors, components, and lines of code. At a high level, the primary guiding principle of the JEP process is to encourage collaboration and discussion as early as possible in the lifecycle of a major proposed change in Jupyter, with the goal of preventing costly rework, competing ideas, and unnecessary forking or fragmentation of ideas. + +Several sub-goals exist for this process: + +- **Maximize success of large proposals** that get stalled in the wrong venue (e.g. a single PR comment thread) +- Provide a **better alternative to “piecemeal” development** where multiple PRs to build an end-to-end set of functionality are split across multiple GitHub project without broad consensus, context, or guidance. +- Provide a **clear, time-limited, and authoritative process for work proposals**, to facilitate funding conversations. (e.g. provide a concrete artifact to reference in a grant proposal, roadmap item, etc.) +- Provide a **consolidated “stream” of all proposals across the entire Jupyter community** that contributors of all levels can monitor and selectively engage in. + +With that in mind, the JEP process operates under the following tenets: + +- **The JEP process is intended for proposed changes of non-trivial scope.** “Non-trivial” is addressed below in the “JEP / Not-a-JEP Rubric” of this document. If proposals that go through the JEP process do not receive the benefits listed above, the JEP process should be amended to better scope what applied. + +- **The JEP process naturally complements the PR process, but does not replace it.** A thoroughly-reviewed and approved JEP is a valuable reference during a PR to reduce friction, reduce time-consuming context sharing, and encapsulate decisions and other discussions. Moving a premature PR into a JEP should be a lightweight process that doesn’t cause friction for the contributor. + + - GitHub issue and PR templates, for example, across the entire Jupyter project, should have references to the JEP process as a possible outcome of a given PR. + +- **There is one JEP repository, all Jupyter-governed projects must use it.** To faciliate the easiest possible adoption and high visibility of ideas, a single JEP repository will be used. Even if a JEP only applies to a single organization. + +- The JEP process **has multiple valid use cases**. Each use case might have a slightly different expected workflow or base JEP template. Some expected use cases include: + + - Non-trivial feature proposals within a single component that would benefit from process. (e.g., a non-trivial change to JupyterLab that would benefit from formal process within the JupyterLab project) + - Non-trivial features or improvements that span multiple projects. + - Any proposed changes to published APIs or core specifications (e.g., nbformat) + - Changes to the JEP process itself. + - Creating a new GitHub repo in one of the official Jupyter orgs + + +## JEP Submission Workflow + +### Phase 1: Pre-proposal + +This is the least formal stage of any jupyter enhancement proposals. During this phase, discussions on the mailing list, in-person, on github issues are all fine to gauge community interest, feasibility, consequences, and to scope out technical impact and implementation details. + +In order to transition out of the pre-proposal stage, the following checklist must be complete: + +1. A github issue on the Jupyter Enhancement Proposals repo is created that +2. 1. Briefly outlines the proposal + + 2. Suggests reviewiers (optional) in addition to the SSC members. + + 3. Why it should be a JEP + + 4. 1. See the “JEP / Not-a-JEP Rubric” below. +3. A *Shepherd* is identified to see the process through. Shepherds are assigned from a set of people actively involved in the project (Sotfware subprojects, SSC or EC, Standing committees and Working groups), based on the scope of the JEP. The Shepherd can be the author of the JEP. +4. A number is assigned to the JEP to track it through the rest of the process. + +Outcome: + +The Shepherd decides if the JEP criteria have been met. + +- *It's a JEP!* Please create a new PR with the JEP contents using template X. On that basis, you can resolve this issue unless you have further questions.* +- *It’s not a JEP*. (Provide reasons and close the issue.) + +### Phase 2: RFC for the JEP + +Submission: The author submits an initial draft of the JEP as a PR to the JEP repository starting from the relevant template decided in the pre-proposal stage. The number assigned to the PR by Github is the JEP number. The Shepherd optionally assigns reviewers in addition to the SSC. Reviewers and the SSC are refered as the Review Team in the following. + +Request For Comment (RFC) phase: The proposal is iterated on with feedback from the Review Team and the community at large. The Shepherd helps engage the Review Team. When the proposal matures, if there are no major objections, the Shepherd calls to a vote from the SSC members. + +Waiting Decision (WD) phase: The vote follows the rules described in the Decision-Making Guide of the Jupyter Governance. The SSC members have seven days to vote, although the council may consider longer voting periods. If the vote results in an acceptation of the JEP, the Shepherd initiates the Final Comment Period. Otherwise the JEP is considered as rejected. + +Final Comment Period (FCP): The community at large has 10 calendar days in which to provide any final comments on the JEP. A JEP may revert back to RFC if objections are supported by the Review Team. If not reverted to the RFC phase, the JEP is approved at the end of the FCP. + +### Phase 3: Work Commences + +Once a JEP has been merged into the jupyter/enhancement-proposal repository, development work can commence on the JEP. As the implementer(s) is submitting a pull request or pull requests in relation to the JEP, they should provide a reference to the JEP so that reviewer has background context on the JEP. + +As the JEP is being implemented, the implementer(s) are submitting pull requests for the JEP, they should update the JEP with addendums to denote the progress of the implementation using the following stages. + +1. In progress implementation via (list of PRs). +2. Fully implemented via (list of PRs). + +If in the course of implementation, it is discovered that the implementation needs to be radically different from what was defined in the original JEP, then a pull request needs to be submitted to modify the original JEP with the new necessary implementation and a note citing the need for a modification to the JEP. This pull request should be re-approved by the original review team. + +If in the course of the implementation, the implementer(s) can choose to withdraw from the original JEP if they are no longer interested in implementing the JEP or see infeasibilities in the JEP. + +### Paths of the status of JEPs + +![img](jep_status.drawio.svg) + +- Pre-proposal: first stage of the JEP +- RFC: Request For Comments, proposal is under active discussion and revision +- Waiting for answer: authors have been pinged and we will wait 2 weeks before revising the status +- Waiting for decision: final decision to approve or not to be sanctioned by SSC +- FCP: Final Comment Period, 10 days period for any final comment before approval +- In progress: JEP has been approve, implementation is on progress +- Completed: Implementation has completed +- Withdraw: at any stage the author cn decide to withdraw the JEP +- Deferred: Inactive draft that may be taken up again at a later time +- Rejected: The JEP has been rejected and will not be implemented + + +## What qualifies as a JEP? + +This section contains a set of principles to help determine when something is a JEP. The principles will be used to determine when something becomes a PR during the JEP pre-proposal stage, as well as to determine when a PR becomes a JEP at an individual repo level. + +**Principles to follow** + +Below are a few example guidelines to follow when deciding if an idea should include +a JEP (If yes, it requires a JEP). Under each question is a relevant example proposal. + +- Does the proposal/implementation require PRs across multiple orgs? + - Defining a unique cell identifier +- Does the proposal/implementation PR impact multiple orgs, or have widespread community impact? + - Updating nbformat +- Does the proposal/implementation change an invariant in one or more orgs? + - Defining a unique cell identifier + - Deferred kernel startup +- Does the proposal/implementation create a new concept that will impact multiple repositories? + - Sandboxed cell outputs +- Does the proposal involve creating a new repository or subproject? + +## Distribution + +This section describes how information about the JEP process (e.g., new JEPs, updates to +current JEPs, etc) is communicated to the community. + +Note: This JEP repo is the **canonical "source of truth"** for individual JEPs, the JEP process, and activity on JEPs. + +### The JEP public archive website + +A public website contains a readable archive of all JEP proposals. +It contains list of all JEPs that have entered a "final" state +(e.g., "Completed", "Withdrawn", "Rejected"). The content of each JEP will +be displayed in a readable fashion. When a JEP enters into a final state, it +is added to this website. + +Note that the JEPs themselves contain the content, while the website is just a +quick way to display them in a reading-friendly format. + diff --git a/jep-process-v2/jep_status.drawio.svg b/jep-process-v2/jep_status.drawio.svg new file mode 100644 index 00000000..8dd6f8d6 --- /dev/null +++ b/jep-process-v2/jep_status.drawio.svg @@ -0,0 +1,4 @@ + + + +
Pre-proposal
Pre-propos...
RFC
RFC
Waiting for decision
Waiting fo...
FCP
FCP
Waiting for answer
Waiting fo...
Submission
Submission
In progress
In progress
PHASE 2
PHASE 2
Approved
Approved
PHASE 1
PHASE 1
Completed
Completed
PHASE 3
PHASE 3
Deferred
Deferred
Rejected
Rejected
Withdraw
WithdrawText is not SVG - cannot display \ No newline at end of file From cb6e1cff97284e8bf553707a7c4d0a76e8ce8fab Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Mon, 24 Apr 2023 18:51:50 +0200 Subject: [PATCH 2/6] Added fallback for the shepherd --- jep-process-v2/jep-process-v2.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/jep-process-v2/jep-process-v2.md b/jep-process-v2/jep-process-v2.md index 211c14c8..93b8d33d 100644 --- a/jep-process-v2/jep-process-v2.md +++ b/jep-process-v2/jep-process-v2.md @@ -75,7 +75,8 @@ In order to transition out of the pre-proposal stage, the following checklist mu 3. Why it should be a JEP 4. 1. See the “JEP / Not-a-JEP Rubric” below. -3. A *Shepherd* is identified to see the process through. Shepherds are assigned from a set of people actively involved in the project (Sotfware subprojects, SSC or EC, Standing committees and Working groups), based on the scope of the JEP. The Shepherd can be the author of the JEP. +3. A *Shepherd* is identified to see the process through. Shepherds are assigned from a set of people actively involved in the project (Sotfware subprojects, SSC or EC, Standing committees and Working groups), based on the scope of the JEP. The Shepherd can be the author of the JEP. If the author of the JEP cannot +identify a Shepherd, the SSC is responsible for designating one. 4. A number is assigned to the JEP to track it through the rest of the process. Outcome: From d3cf7d48e04e87e1ddefb9ba69f37899595c5603 Mon Sep 17 00:00:00 2001 From: Paul Ivanov Date: Tue, 18 Jul 2023 17:51:50 -0700 Subject: [PATCH 3/6] fix typos --- jep-process-v2/jep-process-v2.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/jep-process-v2/jep-process-v2.md b/jep-process-v2/jep-process-v2.md index 93b8d33d..3e9f8f89 100644 --- a/jep-process-v2/jep-process-v2.md +++ b/jep-process-v2/jep-process-v2.md @@ -48,7 +48,7 @@ With that in mind, the JEP process operates under the following tenets: - GitHub issue and PR templates, for example, across the entire Jupyter project, should have references to the JEP process as a possible outcome of a given PR. -- **There is one JEP repository, all Jupyter-governed projects must use it.** To faciliate the easiest possible adoption and high visibility of ideas, a single JEP repository will be used. Even if a JEP only applies to a single organization. +- **There is one JEP repository, all Jupyter-governed projects must use it.** To facilitate the easiest possible adoption and high visibility of ideas, a single JEP repository will be used. Even if a JEP only applies to a single organization. - The JEP process **has multiple valid use cases**. Each use case might have a slightly different expected workflow or base JEP template. Some expected use cases include: @@ -70,12 +70,12 @@ In order to transition out of the pre-proposal stage, the following checklist mu 1. A github issue on the Jupyter Enhancement Proposals repo is created that 2. 1. Briefly outlines the proposal - 2. Suggests reviewiers (optional) in addition to the SSC members. +2. Suggests reviewers (optional) in addition to the SSC members. 3. Why it should be a JEP 4. 1. See the “JEP / Not-a-JEP Rubric” below. -3. A *Shepherd* is identified to see the process through. Shepherds are assigned from a set of people actively involved in the project (Sotfware subprojects, SSC or EC, Standing committees and Working groups), based on the scope of the JEP. The Shepherd can be the author of the JEP. If the author of the JEP cannot +3. A *Shepherd* is identified to see the process through. Shepherds are assigned from a set of people actively involved in the project (Software subprojects, SSC or EC, Standing committees and Working groups), based on the scope of the JEP. The Shepherd can be the author of the JEP. If the author of the JEP cannot identify a Shepherd, the SSC is responsible for designating one. 4. A number is assigned to the JEP to track it through the rest of the process. @@ -88,7 +88,7 @@ The Shepherd decides if the JEP criteria have been met. ### Phase 2: RFC for the JEP -Submission: The author submits an initial draft of the JEP as a PR to the JEP repository starting from the relevant template decided in the pre-proposal stage. The number assigned to the PR by Github is the JEP number. The Shepherd optionally assigns reviewers in addition to the SSC. Reviewers and the SSC are refered as the Review Team in the following. +Submission: The author submits an initial draft of the JEP as a PR to the JEP repository starting from the relevant template decided in the pre-proposal stage. The number assigned to the PR by Github is the JEP number. The Shepherd optionally assigns reviewers in addition to the SSC. Reviewers and the SSC are referred as the Review Team in the following. Request For Comment (RFC) phase: The proposal is iterated on with feedback from the Review Team and the community at large. The Shepherd helps engage the Review Team. When the proposal matures, if there are no major objections, the Shepherd calls to a vote from the SSC members. @@ -118,9 +118,9 @@ If in the course of the implementation, the implementer(s) can choose to withdra - Waiting for answer: authors have been pinged and we will wait 2 weeks before revising the status - Waiting for decision: final decision to approve or not to be sanctioned by SSC - FCP: Final Comment Period, 10 days period for any final comment before approval -- In progress: JEP has been approve, implementation is on progress +- In progress: JEP has been approved, implementation is in progress - Completed: Implementation has completed -- Withdraw: at any stage the author cn decide to withdraw the JEP +- Withdraw: at any stage the author can decide to withdraw the JEP - Deferred: Inactive draft that may be taken up again at a later time - Rejected: The JEP has been rejected and will not be implemented From 79497cc75e462ccf48d63aa487151ddebdce28d1 Mon Sep 17 00:00:00 2001 From: Paul Ivanov Date: Tue, 18 Jul 2023 18:36:53 -0700 Subject: [PATCH 4/6] withdraw -> withdrawn --- jep-process-v2/jep-process-v2.md | 2 +- jep-process-v2/jep_status.drawio.svg | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/jep-process-v2/jep-process-v2.md b/jep-process-v2/jep-process-v2.md index 3e9f8f89..6cbcc220 100644 --- a/jep-process-v2/jep-process-v2.md +++ b/jep-process-v2/jep-process-v2.md @@ -120,7 +120,7 @@ If in the course of the implementation, the implementer(s) can choose to withdra - FCP: Final Comment Period, 10 days period for any final comment before approval - In progress: JEP has been approved, implementation is in progress - Completed: Implementation has completed -- Withdraw: at any stage the author can decide to withdraw the JEP +- Withdrawn: at any stage the author can decide to withdraw the JEP - Deferred: Inactive draft that may be taken up again at a later time - Rejected: The JEP has been rejected and will not be implemented diff --git a/jep-process-v2/jep_status.drawio.svg b/jep-process-v2/jep_status.drawio.svg index 8dd6f8d6..75199e29 100644 --- a/jep-process-v2/jep_status.drawio.svg +++ b/jep-process-v2/jep_status.drawio.svg @@ -1,4 +1,4 @@ -
Pre-proposal
Pre-propos...
RFC
RFC
Waiting for decision
Waiting fo...
FCP
FCP
Waiting for answer
Waiting fo...
Submission
Submission
In progress
In progress
PHASE 2
PHASE 2
Approved
Approved
PHASE 1
PHASE 1
Completed
Completed
PHASE 3
PHASE 3
Deferred
Deferred
Rejected
Rejected
Withdraw
WithdrawText is not SVG - cannot display \ No newline at end of file +
Pre-proposal
Pre-propos...
RFC
RFC
Waiting for decision
Waiting fo...
FCP
FCP
Waiting for answer
Waiting fo...
Submission
Submission
In progress
In progress
PHASE 2
PHASE 2
Approved
Approved
PHASE 1
PHASE 1
Completed
Completed
PHASE 3
PHASE 3
Deferred
Deferred
Rejected
Rejected
Withdrawn
WithdrawnText is not SVG - cannot display From 7ba5081143e3f54297131919a3ab4ff67fcf37f7 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Mon, 9 Oct 2023 21:05:24 +0200 Subject: [PATCH 5/6] Reworked jep workflow and added Active status --- jep-process-v2/jep-process-v2.md | 9 +++++++-- jep-process-v2/jep_status.drawio.svg | 4 ++-- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/jep-process-v2/jep-process-v2.md b/jep-process-v2/jep-process-v2.md index 6cbcc220..028cb474 100644 --- a/jep-process-v2/jep-process-v2.md +++ b/jep-process-v2/jep-process-v2.md @@ -5,6 +5,7 @@ authors: | issue-number: 27 pr-number: 29 date-started: "2019-02-23" +last-update: "2023-10-10" type: P - Process --- @@ -88,7 +89,7 @@ The Shepherd decides if the JEP criteria have been met. ### Phase 2: RFC for the JEP -Submission: The author submits an initial draft of the JEP as a PR to the JEP repository starting from the relevant template decided in the pre-proposal stage. The number assigned to the PR by Github is the JEP number. The Shepherd optionally assigns reviewers in addition to the SSC. Reviewers and the SSC are referred as the Review Team in the following. +Submission: The author submits an initial draft of the JEP as a PR to the JEP repository starting from the relevant template decided in the pre-proposal stage. The number assigned to the PR by GitHub is the JEP number. The Shepherd optionally assigns reviewers in addition to the SSC. Reviewers and the SSC are referred as the Review Team in the following. Request For Comment (RFC) phase: The proposal is iterated on with feedback from the Review Team and the community at large. The Shepherd helps engage the Review Team. When the proposal matures, if there are no major objections, the Shepherd calls to a vote from the SSC members. @@ -98,7 +99,7 @@ Final Comment Period (FCP): The community at large has 10 calendar days in which ### Phase 3: Work Commences -Once a JEP has been merged into the jupyter/enhancement-proposal repository, development work can commence on the JEP. As the implementer(s) is submitting a pull request or pull requests in relation to the JEP, they should provide a reference to the JEP so that reviewer has background context on the JEP. +Once a JEP has been merged into the jupyter/enhancement-proposal repository, it becomes active and development work can commence on the JEP. As the implementer(s) is submitting a pull request or pull requests in relation to the JEP, they should provide a reference to the JEP so that reviewer has background context on the JEP. As the JEP is being implemented, the implementer(s) are submitting pull requests for the JEP, they should update the JEP with addendums to denote the progress of the implementation using the following stages. @@ -109,6 +110,10 @@ If in the course of implementation, it is discovered that the implementation nee If in the course of the implementation, the implementer(s) can choose to withdraw from the original JEP if they are no longer interested in implementing the JEP or see infeasibilities in the JEP. +### Updating an accepted JEP + +When one needs to amend a JEP that was merged, they need to open a new JEP. If the new JEP gets accepted and merged, the old JEP loses its "Active" status; a note should be added to the old JEP with a link to the one it is replaced with. + ### Paths of the status of JEPs ![img](jep_status.drawio.svg) diff --git a/jep-process-v2/jep_status.drawio.svg b/jep-process-v2/jep_status.drawio.svg index 75199e29..f76bf44e 100644 --- a/jep-process-v2/jep_status.drawio.svg +++ b/jep-process-v2/jep_status.drawio.svg @@ -1,4 +1,4 @@ - + -
Pre-proposal
Pre-propos...
RFC
RFC
Waiting for decision
Waiting fo...
FCP
FCP
Waiting for answer
Waiting fo...
Submission
Submission
In progress
In progress
PHASE 2
PHASE 2
Approved
Approved
PHASE 1
PHASE 1
Completed
Completed
PHASE 3
PHASE 3
Deferred
Deferred
Rejected
Rejected
Withdrawn
WithdrawnText is not SVG - cannot display +
Pre-proposal
Pre-propos...
RFC
RFC
Waiting for decision
Waiting fo...
FCP
FCP
Waiting for answer
Waiting fo...
Submission
Submission
In progress
In progress
PHASE 2
PHASE 2
Approved
Approved
PHASE 1
PHASE 1
Completed
Completed
PHASE 3
PHASE 3
Deferred
Deferred
Rejected
Rejected
Withdrawn
Withdrawn
ACTIVE
ACTIVEText is not SVG - cannot display \ No newline at end of file From 0544a053e14079dda59b94928a8ba3d2c1d63ea2 Mon Sep 17 00:00:00 2001 From: Johan Mabille Date: Wed, 11 Oct 2023 21:31:07 +0200 Subject: [PATCH 6/6] Changes according to review --- jep-process-v2/jep-process-v2.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/jep-process-v2/jep-process-v2.md b/jep-process-v2/jep-process-v2.md index 028cb474..b037b491 100644 --- a/jep-process-v2/jep-process-v2.md +++ b/jep-process-v2/jep-process-v2.md @@ -57,7 +57,7 @@ With that in mind, the JEP process operates under the following tenets: - Non-trivial features or improvements that span multiple projects. - Any proposed changes to published APIs or core specifications (e.g., nbformat) - Changes to the JEP process itself. - - Creating a new GitHub repo in one of the official Jupyter orgs + - Creating a new official GitHub organization. ## JEP Submission Workflow @@ -143,12 +143,13 @@ a JEP (If yes, it requires a JEP). Under each question is a relevant example pro - Defining a unique cell identifier - Does the proposal/implementation PR impact multiple orgs, or have widespread community impact? - Updating nbformat -- Does the proposal/implementation change an invariant in one or more orgs? +- Does the proposal/implementation impact the interoperability of software components developed in separate Jupyter Subprojects? - Defining a unique cell identifier - Deferred kernel startup - Does the proposal/implementation create a new concept that will impact multiple repositories? - Sandboxed cell outputs -- Does the proposal involve creating a new repository or subproject? +- Does the proposal involve creating a new GitHub organization or subproject? + - jupyter-xeus ## Distribution