Why ExecutableBooks is not within the Jupyter governance?

[echarles]

Quick note to discuss about the link/affiliation of ExecutableBooks with Jupyer. Based on the usage and reach of the ExecutableBooks deliverables, I was under the assumption the EB was another pillar of the Jupyter ecosystem, just like Hub, Lab,...

It does not seem to be the case, see https://jupyter.org/governance/list_of_subprojects.html#official-subprojects-with-ssc-representation which currently lists.

• JupyterLab
• JupyterHub and Binder
• Voilà
• Jupyter Server
• Jupyter Widgets
• Jupyter Notebook
• Jupyter Kernels
• Jupyter Foundations
• Jupyter Standards
• Jupyter Security
• Jupyter Accessibility

[welcome[bot]]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[choldgraf]

Thanks for opening this - I'll provide some historical background and then an idea of where we're at right now.

Originally, the Jupyter Book project was created underneath the jupyter/ github organization. This was an action that I took without consultation, largely because I needed a place to put it that wasn't my personal account so we could use it in the Berkeley Data 8 class. I developed that repository largely independently over about a year or two.

When the Principle Investigators of the Executable Books Project got our Sloan Foundation grant, we decided to create a dedicated GitHub organization to hold the assets we created as we worked on the grant deliverables. We moved the jupyter-book repository there, in order to make it easier for the grant team to iterate quickly on the codebase, and because we had never gone through a formal process to define Jupyter Book as an official Jupyter project anyway (which in my opinion is needed before committing Jupyter to stewardship of this now fairly complex ecosystem).

Our goals during this grant were to build a foundation of open source tools to meet the grant's deliverables, and at the end of the grant, determine a future home for those repositories/brand assets/etc.

About a year ago we kicked off a process to discuss what it would look like to transition the project away from "a single grant-funded team led by three Principle Investigators" to "a multi-stakeholder open source community". Much of this is encoded in the following two places:

• This community strategy issue: [Proposal] Community Strategy for this organization #493
• This policy proposal: Community Strategy hackmd

To your question: I agree that the Jupyter Project would be a natural home for some or all of the assets in Executable Books. I proposed this in the appendix of the document above here:

• Proposal to incorporate as a Jupyter sub-project

Where we are now

We kicked off this process about a year ago, have now finished the deliverables on the grant, and the PIs have been having a bunch of conversations with various stakeholders to figure out the right path forward. One example of this is the issue that @rowanc1 recently opened: #838.

We have also been awaiting Jupyter's upcoming Governance refactor to be finalized so that we could utilize this process to make a formal proposal. It seems like there is informal agreement from some key stakeholders in Jupyter (cc @fperez) as well as from the Principle Investigators of the EBP grant (cc @jstac and @gregcaporaso) that Jupyter would be a good home for the Executable Books project. However, I think it is important that we formalize this decision from the Jupyter community via their governance processes.

So in the coming months, our plan is to:

1. Define a formal governance structure of this project, and a process to make and encode decisions. (for example, we have one proposal here that is based on Python PEPs)
2. Decide on whether all or some of the assets created by the grant should live in Jupyter or should be split out (e.g. there is one proposal to do this with markdown-it-py in Proposal: Move markdown-it-py out of EBP #841)
3. Using the process described in 1, Make a proposal within EBP to approve moving some/all of its assets to Jupyter.
4. Make a formal proposal within Jupyter's governance model to approve this move.

I suspect that this will play out over a couple of months, but those are the major pieces I anticipate.

Let me know if you have any questions about this!

[echarles]

Thank you @choldgraf for the detailed history. I think having a separated EB GitHub org has allowed to play around and experiment with functionalities and creating/archiving various repositories.

This is not really a question you need to answer today as I am sure the current discussion will percolate and natural decisions will be taken, but when I read you ...should live in Jupyter or should be split out... I wonder:

1. If a repo aims to live in Jupyter, there are quite a few orgs as candidate.
2. When you say split out are you meaning going to yet-another org, or just staying in the EB org?

[choldgraf]

That is a great question :-) I don't think we're sure yet of the specific breakdown, but here are some thoughts:

If a repo aims to live in Jupyter, there are quite a few orgs as candidate.

Good point - I suspect that, given the complexity of the assets created in the Executable Books Project, it would likely need to have its own dedicated GitHub organization rather than exist underneath a pre-existing organization. So perhaps executablebooks/ would stay the same, but would simply exist underneath Jupyter's governance, license, and Code of Conduct.

When you say split out are you meaning going to yet-another org, or just staying in the EB org?

I'm suggesting that some subsets of the ExecutableBooks stack might make sense in a different space than Jupyter if it means they could be more accessible or would get more contributions from a different stakeholder group. An example is the really "low level" markdown parsing tools that were created as a part of this grant (e.g. markdown-it-py). Does Jupyter want to be responsible for maintaining a low-level markdown parser in Python? Does it make more sense to exist in its own separate GitHub organization to attract a different kind of contributor? I am not sure, but there might be strategic reasons to decide to split things up into self-contained organizations. That's the kinda stuff I meant.