Dissolve Jupyter Enterprise Subproject and relocate its repositories

[kevin-bates]

Votes

@afshin

• YES
• NO

@blink1073

• YES
• NO

@Carreau

• YES
• NO

@damianavila

• YES
• NO

@ellisonbg

• YES
• NO

@fperez

• YES
• NO

@ivanov

• YES
• NO

@jasongrout

• YES
• NO

@jhamrick

• YES
• NO

@minrk

• YES
• NO

@mpacer

• YES
• NO

@parente

• YES
• NO

@rgbkrk

• YES
• NO

@Ruv7

• YES
• NO

@SylvainCorlay

• YES
• NO

@takluyver

• YES
• NO

@willingc

• YES
• NO

Contents of the PR

As noted in issue #109, there is concern that the Jupyter Enterprise Subproject may not have adequate backing/participation relative to the new model and a majority of its repositories are subsets of other organizations (from a skillset perspective). This pull request redistributes its four repositories into other subprojects that better reflect the repository's relationship to the hosting organization and, ultimately, provide better representation for the work within the repository.

Although the distributions of the gateway repositories to the Jupyter Server organization make sense because these are arguably direct subsets of Jupyter Server, the redistribution of docker-stacks to Jupyter Foundations and nbviewer to the non-SCC represented group (a more succinct term for this set of repositories would be helpful) is more subjective.

I felt docker-stacks is a true foundation repository as it is leveraged in any number of ways by many different organizations. The choice of adding nbviewer to the set of non-SCC represented repositories was more based on the fact that it hasn't had a significant commit in the last 16 months and is less active than many repositories. It too could be included in Jupyter Foundations but I felt pairing it with nbdime and nbgrader was also justified.

@ellisonbg asked that I ping stakeholders of these four repositories for comment. As I am unfamiliar with docker-stacks and nbviewer activities, I'm basing my ping-points based on what I can glean from commit histories. Please ping others as you see fit - thank you.

Enterprise Gateway: myself, @lresende
Kernel Gateway: myself, @parente
Docker Stacks: @mathbunnyru, @romainx, @parente
nbviewer: @minrk, @krinsman

[ellisonbg]

Also pinging @Zsailer on the Jupyter Server side.

[Zsailer]

This sounds completely reasonable to me. I'm in favor of moving both Gateways underneath the Jupyter Server Github organization/decision-making body.

[mathbunnyru]

Also pinging @consideRatio on the docker-stacks side.

[consideRatio]

While I consider all of the suggestions in as reasonable, I especially appreciate considering docker-stacks as a jupyter-foundations project - it makes perfect sense to me.

[mathbunnyru]

LGTM as well 👍
It's nice to be a maintainer of one of Jupyter Foundations' subproject 😃

[ellisonbg]

Looks there there is support of those most affected by this change, let's wait a few more days and the move this to voting by the Steering Council.

[lresende]

The initial goal to have a "Jupyter Enterprise" org was to give a representation to the folks working on related use cases that don't necessarily apply to regular scientists that are ok working from their laptop. Without representation, things like this can happen and the interested parties will have very little to say, particularly when "enterprise scenarios" is not the highest priority for most of the community (e.g. just a small set of people think about remote kernels and some other aspects that only apply to more complex enterprise scenarios when proposing new solutions or enhancements).

As for location, I am very flexible. I personally don't like having multiple github orgs per project, it's very hard to maintain in terms of security and other "standards" and I would really prefer to have one org and have all projects grouped by prefix, that would enable consistency and ease of maintenance (e.g. github groups to identify committers, people with a binding vote, etc). Having said that, we have seen a proliferation of single org per project recently that having "Jupyter Enterprise" org or not should not really affect community aspects of it.

[kevin-bates]

The initial goal to have a "Jupyter Enterprise" org was to give a representation to the folks working on related use cases that don't necessarily apply to regular scientists that are ok working from their laptop.

I certainly hope (and expect) the Jupyter Server subproject to "represent" enterprises. By having the gateways within the server organization, we have more liberty to organize pieces to better serve our users, enterprise or otherwise.

[ellisonbg]

Can someone move this to the voting phase and add the template for steering council members to vote?

…

On Fri, Jul 30, 2021 at 11:06 AM Kevin Bates ***@***.***> wrote: The initial goal to have a "Jupyter Enterprise" org was to give a representation to the folks working on related use cases that don't necessarily apply to regular scientists that are ok working from their laptop. I certainly hope (and expect) the Jupyter Server subproject to "represent" enterprises. By having the gateways within the server organization, we have more liberty to organize pieces to better serve our users, enterprise or otherwise. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#110 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUGZ4DFHWZLSSTEOES3T2LS2LANCNFSM5BFE52MA> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform ***@***.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[kevin-bates]

Thanks @ellisonbg. If this is just a matter of moving out of draft and adding the named checkboxes for the Steering Council, I'm happy to do that.

[Zsailer]

Yeah, @kevin-bates go ahead update the top comment with the voting checkboxes. That will ping everyone on the SC. Thank you!

[jasongrout]

FYI, we now have 12 positive votes and no negative votes, so we've cleared the 2/3 threshold. Voting has been opened for more than a month, so per the governance decision criteria, this is approved and can be merged.