JEP: Add Jupyter Book as subproject #123
Conversation
|
Is there any discussion or questions that we need to answer to move this forward? How can we make progress on this? |
|
This JEP should be discussed during the SSC working hours today (according to the triage last week). I think it has been opened long enough so that we can move it to the voting phase. |
|
This JEP has been discussed in the pre-JEP issue, there were Q&A sessions during the SSC working hours, it's time to move to the voting phase. |
|
Since adding a subproject to Jupyter requires both SSC and EC approval (as Fernando mentioned here), we discussed this briefly in the EC meeting today. Since the SSC is already voting on this proposal, we (the EC) will wait to see the result of this vote. As a next step, if this is approved, the EC asks that a PR be opened to the governance repo adding the subproject to the official list of subprojects, and the EC can officially vote on the subproject addition in that governance PR. |
|
I marked @minrk as "yes" because he approved the PR. I think only @gabalafou remains. For the decision, am I correct in my understanding from the governance docs that this only requires a majority vote from the SSC? This is what I'm basing this on: https://jupyter.org/governance/decision_making.html#required-aspects-of-decision-making If that's the case then we can move forward with the steps that @jasongrout recommends |
|
Since there is general consensus so far (and one "no vote"), I went ahead and created a PR so that the Executive Council has something to vote on if they decide that this conversation can be considered "decided": |
|
voted, sorry for the tardiness! |
| ### Why split the `executablebooks/` repositories into two homes? | ||
|
|
||
| We believe that the `executablebooks/` repositories naturally fall into two technical directions: one based on `docutils` and `sphinx` (with heavy overlap with the broader developer documentation community), and one based on Javascript (with heavy overlap with scientific computing and authoring workflows). | ||
|
|
||
| The technical direction and user-focus of each is distinct enough that it is natural to split them into two projects. This will allow each organization to define their own set of target users and strategies to serve them. | ||
|
|
||
| Note that, initially, the Steering Council of `executablebooks/` and that of the `jupyter-book` organization will be the same. This will allow us to coordinate the direction of projects in each organization for the immediate future, and minimize the friction associated with having two organizational homes. Over time, we intend for the strategy and governance of each organization to begin to evolve independent of one another. |
There was a problem hiding this comment.
cc @ellisonbg from your question here jupyter/governance#229 (comment)
|
Since the vote here is unanimous for the SSC, and is unanimous over at jupyter/governance#229 for the EC, I think the motion passes, and Jupyter Book is now our newest subproject. I merged jupyter/governance#229, but I'll leave it up to someone in the SSC to merge this PR. Congratulations! |
|
Wow, so exciting! Thanks everybody 🙂 it has been a long road back home for the jupyter book project! |
|
Congrats @choldgraf @rowanc1 and everyone involved. |
This JEP proposes incorporating Jupyter Book as a Jupyter sub-project.
See the pre-proposal issue below for conversation around this:
jupyter-bookas a Jupyter sub-project #122Voting from @jupyter/software-steering-council