|
| 1 | +--- |
| 2 | +title: <your-JEP-title> |
| 3 | +authors: <list-of-authors> |
| 4 | +issue-number: <pre-proposal-issue-number> |
| 5 | +pr-number: <proposal-pull-request-number> |
| 6 | +date-started: <yyyy-mm-dd> |
| 7 | +--- |
| 8 | + |
| 9 | +# Summary |
| 10 | + |
| 11 | +One paragraph explanation of the proposal. |
| 12 | + |
| 13 | +# Motivation |
| 14 | + |
| 15 | +Why are we doing this? What use cases does it support? What is the expected outcome? |
| 16 | + |
| 17 | +# Guide-level explanation |
| 18 | + |
| 19 | +Explain the proposal as if it was already implemented and you were |
| 20 | +explaining it to another community member. That generally means: |
| 21 | + |
| 22 | +- Introducing new named concepts. |
| 23 | +- Adding examples for how this proposal affects people's experience. |
| 24 | +- Explaining how others should *think* about the feature, and how it should impact the experience using Jupyter tools. It should explain the impact as concretely as possible. |
| 25 | +- If applicable, provide sample error messages, deprecation warnings, or migration guidance. |
| 26 | +- If applicable, describe the differences between teaching this to existing Jupyter members and new Jupyter members. |
| 27 | + |
| 28 | +For implementation-oriented JEPs, this section should focus on how other Jupyter |
| 29 | +developers should think about the change, and give examples of its concrete impact. For policy JEPs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. |
| 30 | + |
| 31 | +# Reference-level explanation |
| 32 | + |
| 33 | +This is the technical portion of the JEP. Explain the design in |
| 34 | +sufficient detail that: |
| 35 | + |
| 36 | +- Its interaction with other features is clear. |
| 37 | +- It is reasonably clear how the feature would be implemented. |
| 38 | +- Corner cases are dissected by example. |
| 39 | + |
| 40 | +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. |
| 41 | + |
| 42 | +# Rationale and alternatives |
| 43 | + |
| 44 | +- Why is this choice the best in the space of possible designs? |
| 45 | +- What other designs have been considered and what is the rationale for not choosing them? |
| 46 | +- What is the impact of not doing this? |
| 47 | + |
| 48 | +# Prior art |
| 49 | + |
| 50 | +Discuss prior art, both the good and the bad, in relation to this proposal. |
| 51 | +A few examples of what this can include are: |
| 52 | + |
| 53 | +- Does this feature exist in other tools or ecosystems, and what experience have their community had? |
| 54 | +- For community proposals: Is this done by some other community and what were their experiences with it? |
| 55 | +- For other teams: What lessons can we learn from what other communities have done here? |
| 56 | +- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. |
| 57 | + |
| 58 | +This section is intended to encourage you as an author to think about the lessons from other languages, provide readers of your JEP with a fuller picture. |
| 59 | +If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages. |
| 60 | + |
| 61 | + |
| 62 | +# Unresolved questions |
| 63 | + |
| 64 | +- What parts of the design do you expect to resolve through the JEP process before this gets merged? |
| 65 | +- What related issues do you consider out of scope for this JEP that could be addressed in the future independently of the solution that comes out of this JEP? |
| 66 | + |
| 67 | +# Future possibilities |
| 68 | + |
| 69 | +Think about what the natural extension and evolution of your proposal would |
| 70 | +be and how it would affect the Jupyter community at-large. Try to use this section as a tool to more fully consider all possible |
| 71 | +interactions with the project and language in your proposal. |
| 72 | +Also consider how the this all fits into the roadmap for the project |
| 73 | +and of the relevant sub-team. |
| 74 | + |
| 75 | +This is also a good place to "dump ideas", if they are out of scope for the |
| 76 | +JEP you are writing but otherwise related. |
| 77 | + |
| 78 | +If you have tried and cannot think of any future possibilities, |
| 79 | +you may simply state that you cannot think of anything. |
| 80 | + |
| 81 | +Note that having something written down in the future-possibilities section |
| 82 | +is not a reason to accept the current or a future JEP; such notes should be |
| 83 | +in the section on motivation or rationale in this or subsequent JEPs. |
| 84 | +The section merely provides additional information. |
0 commit comments