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

New governance model: Jupyter Enterprise subproject #109

Open
kevin-bates opened this issue Jul 28, 2021 · 1 comment
Open

New governance model: Jupyter Enterprise subproject #109

kevin-bates opened this issue Jul 28, 2021 · 1 comment

Comments

@kevin-bates
Copy link
Member

Hello. Thank you all for the great work being done toward solidifying the governance model - this will be a tremendous benefit to the health of the community. I realize I should have raised this prior to the model's merge, but felt the other discussions were more important and, honestly, wasn't sure if it was my place to chime in.

I'm concerned that the Jupyter Enterprise subproject's "foundation" will be tenuous from the start and will struggle to meet the participation needs of the model. It also feels a bit like an Island of misfit toys in that the only project specifically targetting enterprises is Enterprise Gateway.

Although I can't speak to docker-stacks or nbviewer, I can safely say both Kernel and Enterprise Gateway are (today) maintained by a couple of maintainers with Kernel Gateway's traffic quite sparse and EG's not far behind. Since these two projects are direct subsets of Jupyter Server (JKG is currently based on notebook, but is identical to server) and require the same technical expertise residing within the Jupyter Server organization, they strike me as better-suited to the Jupyter Server subproject.

Assuming we did relocate the gateway's into Jupyter Server, that would leave docker-stacks and nbviewer as the only projects in Jupyter Enterprise, both of which are widely used outside of enterprises. Seems they could be logically included in Jupyter Foundations, a different sub-project, or in the set of projects w/o SCC representation.

I just feel like the current incantation of Jupyter Enterprise is fragile from a participation/community presence perspective and felt this should be raised before actual representation is established.

Thanks again for all you're doing to improve the community!

@ellisonbg
Copy link
Contributor

Kevin, great points here. As we have talked about this, one of the principles has been that the folks most involved in the subprojects/repos should drive this. Thus, if there is consensus among the involved parties, I think that makes sense. Do you want to open a PR to the doc that describes the new subprojects with these changes and ping the relevant stakeholders for input?

Another point that probably deserves clarification. While each decision making body has a minimum participation requires (as a % of the annual votes), we realize that some decision making bodies will be smaller and less active than others. I wouldn't be surprised if some of the smaller subprojects only have a few people on their decision making body and only take a few votes (if any) each year.

But overall, the refactoring of subprojects you are proposing makes sense to me.

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

2 participants