Updated README with more detailed guidelines #2
Conversation
|
|
||
| ### Pros and Cons | ||
| Cons associated with this implementation include: | ||
| * Existing IPEPs (IPython Enhancement Proposals) will not be included in this migrated repository |
There was a problem hiding this comment.
There's nothing to say we couldn't really.
There was a problem hiding this comment.
@rgbkrk — you caught me! I was having trouble thinking of cons so I just put something down.
|
Fun fact: don't write a bunch in a comment, switch to file view, add a comment in line, and expect your comment text to stick around on the conversation view. 😠 (I just did this) |
|
|
|
This is a really good outline that I think is deserving of going in its own folder. The root README should be a bit more simple and direct to answer these questions:
On another topic, I'm personally thinking that adding numbers might be a bit silly when we already have a unique identifier - the PR or issue number. If we're updating a previous spec, that is a proposal in itself. I realize the precedence here comes from PEPs and IPEPs, but we have great decision solidifying technology right in front of us, complete with history, revisions, conversations, etc. |
|
I like how Python has PEP 0 as the index of PEPs and PEP 1 as the "PEP I also think that with a GitHub based workflow we don't necessarily need On Sat, Aug 29, 2015 at 2:20 PM, Kyle Kelley [email protected]
Brian E. Granger |
|
@ellisonbg and @rgbkrk — I agree on both your comments. Will update in next iteration. |
But people can open an issue for an specific enhancement proposal and having them numerated make easy to tag them with the proper short labels and have filtering trough github UI. |
| ### Pros and Cons | ||
|
|
||
| ### Interested Contributors | ||
| In order to submit a JEP, please read the Jupyter Enhancement Proposal Submission Guidelines, located [here](jupyter-enhancement-proposal-guidelines/jupyter-enhancement-proposal-guidelines.md). You can copy this file and use it as the starting point for outlining your own JEP. |
There was a problem hiding this comment.
Use "Jupyter Enhancement Proposal Submission Guidelines" as the link text instead of the "located here" text so it reads naturally (people will see the link with the name). This also helps in accessibility in terms of screen readers, so people don't have to backtrack on what "here" means.
|
+1 for number, I think we can use the number of the PR the introduce the proposal no? that makes it easy to cross reference in github. Otherwise I think that sticingclose to what Python does is nice too. |
|
Agreed with PR numbers. We're already uniquely assigned one and the github cross referencing is wonderful. |
|
Let's merge and iterate. |
Updated README with more detailed guidelines
Amen to that. |
add note about displaying metadata
Light editing
I changed the format of the README to be in the format of a JEP and added some more details.
@rgbkrk and @ellisonbg — I know there was some discussion about whether to allow people to link to repositories or have them use folders within the
enhancement-proposallibrary. In this case, I wrote it up so that users will generate folders on the repository. There are definitely pros and cons to this and I am open to changing it based on what everyone thinks.