Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a website for current / historical JEPs #51

Closed
choldgraf opened this issue May 27, 2020 · 14 comments
Closed

Create a website for current / historical JEPs #51

choldgraf opened this issue May 27, 2020 · 14 comments

Comments

@choldgraf
Copy link
Contributor

We recently created a little jupyter book for the governance documentation (https://jupyter.org/governance/). The goal was to make the information more discoverable, easier to browse, etc.

What do folks think about doing the same for the enhancement proposals? I really like the idea of these structured proposals, and especially with the meta-JEP that @captainsafia put together I'd like that information to be more discoverable.

So what do people think about a website with two parts:

  1. Information about JEPs (background, guides for the JEP process, reusing the meta-JEP language, etc.
  2. A list of past and present JEPs, broken down by "inactive" and "active".

This could be hosted at jupyter.org/enhancement-proposals, and could be a way to give more visibility to this process. What do folks think?

@Zsailer
Copy link
Member

Zsailer commented May 27, 2020

I love this idea.

@blink1073
Copy link
Contributor

image

@captainsafia
Copy link
Member

Sounds like a good idea overall.

We might be able to build upon the UI that Python.org uses for PEPs. @willingc might have more insight here.

@willingc
Copy link
Member

willingc commented May 28, 2020

In general, I think it's a good idea. I think at minimum that there should be:

  • a repo that is the source of truth for JEPs.
  • that repo should be used for rendering of any website content
  • do we have a process similar to PEP 1 about purpose and guidelines as well as well written PEPs

I think it's important to move JEP 29 from draft status to accepted before publishing JEPs on a website.

@choldgraf
Copy link
Contributor Author

Some quick thoughts

  • a repo that is the source of truth for JEPs.
  • that repo should be used for rendering of any website content

👍 I was imagining that the addition I'm suggesting wouldn't change the structure of the current JEP repository, it would probably instead be adding a github action to it + some config that would render the JEPs that are here and push to gh-pages.

  • do we have a process similar to PEP 1 about purpose and guidelines as well as well written PEPs

I haven't seen any, but I thought that @captainsafia made a good start here: https://github.com/jupyter/enhancement-proposals/pull/29/files#diff-f6c91f7d040c33d1fb435d5e1b758bedR30

I think it's important to move JEP 29 from draft status to accepted before publishing JEPs on a website.

Now I feel silly, I thought it had already been "accepted" but now I see that it is in "submitted" state. I agree that it makes sense to formalize that process before publishing publicly (since one of the reasons I wanna do this is precisely to highlight that process). I am happy to help with nailing down the process / language in the meta-JEP if others are interested in getting it closer to acceptance (which I guess requires a steering council vote?)

@damianavila
Copy link
Member

+1 on the idea! Thanks @choldgraf for your continuous effort trying to make visible these sorts of things!

@willingc
Copy link
Member

Thanks @choldgraf. Perhaps the website would increase the sense of urgency to move JEP 29 to accepted.

@choldgraf
Copy link
Contributor Author

I was looking through the JEP documentation here and have a couple of points to note:

  1. According to the JEP process described there (which is linked in the readme, once a PR is merged then it is "Accepted", but not yet "implemented". So considering that JEP 29 was merged I would take that to mean that it is "Accepted" and is just awaiting implementation. Do others agree?
  2. The word "completed" is used in the JEP readme, but isn't mentioned in the JEP docs, which I believe instead use the word implemented. Are these synonyms?

@choldgraf
Copy link
Contributor Author

choldgraf commented Jun 5, 2020

OK, I haven't heard any objections to the above, so I am going to consider that @captainsafia's JEP is accepted (I believe this is true according to both versions of the JEP rules, because it has been merged), and I will try and make a PR implementing part of the vision that she lays out. I'll try to get something done soon as a first step towards improving this process.

@captainsafia
Copy link
Member

Sounds good. Thanks for putting in the work, @choldgraf!

@blink1073
Copy link
Contributor

Awesome, thanks @captainsafia and @choldgraf !

@nealmcb
Copy link

nealmcb commented Mar 24, 2021

Thanks folks, this sounds good.

I don't know if it has been discussed yet, but I'd like to see clear documentation of when each process change takes place, e.g. the date that a JEP is accepted. E.g. I ran across this JEP: Cell ID Addition to Notebook Format
and I was confused trying to figure out what its status was. I guess the document itself didn't change after it was accepted, and the sidebar visible there doesn't provide a date for the acceptance. I guess the answer is based on when it was merged as #62, but I'm still not sure.

So the status list of various JEPs should at least show the date of the last change for each document, and I think the documents themselves should also be updated with their status.

@westurner
Copy link

Could JEP metadata be collected from one or some JSON[-LD] cell outputs? Or is front matter YAML sufficient for collecting JEP metadata into a TOC/Index/Table of JEPs GitHub Project Board?

@JohanMabille
Copy link
Member

JohanMabille commented Jun 3, 2024

Closing as implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants