Improve the high-level descriptions around the 2i2c Hub service #314
Labels
Enhancement
An improvement to something or creating something new.
Comments
yuvipanda
added a commit
to yuvipanda/2i2c-org.github.io
that referenced
this issue
Mar 21, 2021
2i2c-org/infrastructure#314 talks about the need to be very explicit in what we call the service we provide. The word 'hub' is very overloaded. 2i2c managed infrastructure has an important property that our naming should reflect. It isn't a *new thing* we are developing, but a deployment of an upstream, purely open source product. This means our users can always: 1. Take their infrastructure from 2i2c, and run it themselves with help from the community. 2. Work with us to *train* their own staff to run their JupyterHub, so they can participate fully in running the infrastructure. This gives them organizational control over what is built, and they can walk away easier if needed. 3. Any improvements we make in terms of features built or operations smoothed will be made in upstream repositories, and I think directly using the word JupyterHub is a good way to communicate this. Alternative suggestions: 1. just 'JupyterHub' 2. 2i2c JupyterHub 3. JupyterHub managed by 2i2c I prefer (2) if needed. Question is, how does this related to the Jupyter Trademark policy (https://jupyter.org/governance/trademarks.html)? Particularly: > Any commercial use of the Jupyter trademarks in product or company > names must be approved first by Project Jupyter. Some uses, like calling > a company “The Jupyter Company,” or a product “Jupyter Hosting” or > “Jupyter Cloud” will be refused. This is because they are overly broad, > or confusing as to whether Jupyter is open source or commercial, or > whether your product or organization is affiliated with or sponsored by > Project Jupyter. (from https://jupyter.org/governance/trademarks.html#uses-that-always-require-approval) So no matter what, I think this needs to go to the Jupyter steering council. I personally believe that '2i2c managed JupyterHub' is fine, but that's not for me to decide.
|
I opened 2i2c-org/2i2c-org.github.io#42 to discuss nomenclature of what we offer. |
yuvipanda
added a commit
to yuvipanda/2i2c-org.github.io
that referenced
this issue
Mar 21, 2021
2i2c-org/infrastructure#314 talks about the need to be very explicit in what we call the service we provide. The word 'hub' is very overloaded. 2i2c managed infrastructure has an important property that our naming should reflect. It isn't a *new thing* we are developing, but a deployment of an upstream, purely open source product. This means our users can always: 1. Take their infrastructure from 2i2c, and run it themselves with help from the community. 2. Work with us to *train* their own staff to run their JupyterHub, so they can participate fully in running the infrastructure. This gives them organizational control over what is built, and they can walk away easier if needed. 3. Any improvements we make in terms of features built or operations smoothed will be made in upstream repositories, and I think directly using the word JupyterHub is a good way to communicate this. Alternative suggestions: 1. just 'JupyterHub' 2. 2i2c JupyterHub 3. JupyterHub managed by 2i2c I prefer (2) if needed. Question is, how does this related to the Jupyter Trademark policy (https://jupyter.org/governance/trademarks.html)? Particularly: > Any commercial use of the Jupyter trademarks in product or company > names must be approved first by Project Jupyter. Some uses, like calling > a company “The Jupyter Company,” or a product “Jupyter Hosting” or > “Jupyter Cloud” will be refused. This is because they are overly broad, > or confusing as to whether Jupyter is open source or commercial, or > whether your product or organization is affiliated with or sponsored by > Project Jupyter. (from https://jupyter.org/governance/trademarks.html#uses-that-always-require-approval) So no matter what, I think this needs to go to the Jupyter steering council. I personally believe that '2i2c managed JupyterHub' is fine, but that's not for me to decide.
I wrote about this a little bit in our page on documentation structure. I see the following structure:
How does that sound? |
choldgraf
added a commit
to 2i2c-org/2i2c-org.github.io
that referenced
this issue
Mar 25, 2021
* Call them 2i2c managed JupyterHubs rather than hubs 2i2c-org/infrastructure#314 talks about the need to be very explicit in what we call the service we provide. The word 'hub' is very overloaded. 2i2c managed infrastructure has an important property that our naming should reflect. It isn't a *new thing* we are developing, but a deployment of an upstream, purely open source product. This means our users can always: 1. Take their infrastructure from 2i2c, and run it themselves with help from the community. 2. Work with us to *train* their own staff to run their JupyterHub, so they can participate fully in running the infrastructure. This gives them organizational control over what is built, and they can walk away easier if needed. 3. Any improvements we make in terms of features built or operations smoothed will be made in upstream repositories, and I think directly using the word JupyterHub is a good way to communicate this. Alternative suggestions: 1. just 'JupyterHub' 2. 2i2c JupyterHub 3. JupyterHub managed by 2i2c I prefer (2) if needed. Question is, how does this related to the Jupyter Trademark policy (https://jupyter.org/governance/trademarks.html)? Particularly: > Any commercial use of the Jupyter trademarks in product or company > names must be approved first by Project Jupyter. Some uses, like calling > a company “The Jupyter Company,” or a product “Jupyter Hosting” or > “Jupyter Cloud” will be refused. This is because they are overly broad, > or confusing as to whether Jupyter is open source or commercial, or > whether your product or organization is affiliated with or sponsored by > Project Jupyter. (from https://jupyter.org/governance/trademarks.html#uses-that-always-require-approval) So no matter what, I think this needs to go to the Jupyter steering council. I personally believe that '2i2c managed JupyterHub' is fine, but that's not for me to decide. * Reword the 'features' page - Remove 'distributing content', add 'authentication' instead - Trim content size * Re-title infra intro section * Shorten menu item name * Consistency fix * Minor grammatical fix Co-authored-by: Chris Holdgraf <[email protected]>
choldgraf
added
Enhancement
5 tasks
|
I think there's other useful tickets tracking this more specifically. |
brwsioeb
added a commit
to brwsioeb/2i2c-org.github.io
that referenced
this issue
Aug 14, 2024
* Call them 2i2c managed JupyterHubs rather than hubs 2i2c-org/infrastructure#314 talks about the need to be very explicit in what we call the service we provide. The word 'hub' is very overloaded. 2i2c managed infrastructure has an important property that our naming should reflect. It isn't a *new thing* we are developing, but a deployment of an upstream, purely open source product. This means our users can always: 1. Take their infrastructure from 2i2c, and run it themselves with help from the community. 2. Work with us to *train* their own staff to run their JupyterHub, so they can participate fully in running the infrastructure. This gives them organizational control over what is built, and they can walk away easier if needed. 3. Any improvements we make in terms of features built or operations smoothed will be made in upstream repositories, and I think directly using the word JupyterHub is a good way to communicate this. Alternative suggestions: 1. just 'JupyterHub' 2. 2i2c JupyterHub 3. JupyterHub managed by 2i2c I prefer (2) if needed. Question is, how does this related to the Jupyter Trademark policy (https://jupyter.org/governance/trademarks.html)? Particularly: > Any commercial use of the Jupyter trademarks in product or company > names must be approved first by Project Jupyter. Some uses, like calling > a company “The Jupyter Company,” or a product “Jupyter Hosting” or > “Jupyter Cloud” will be refused. This is because they are overly broad, > or confusing as to whether Jupyter is open source or commercial, or > whether your product or organization is affiliated with or sponsored by > Project Jupyter. (from https://jupyter.org/governance/trademarks.html#uses-that-always-require-approval) So no matter what, I think this needs to go to the Jupyter steering council. I personally believe that '2i2c managed JupyterHub' is fine, but that's not for me to decide. * Reword the 'features' page - Remove 'distributing content', add 'authentication' instead - Trim content size * Re-title infra intro section * Shorten menu item name * Consistency fix * Minor grammatical fix Co-authored-by: Chris Holdgraf <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
There are two major places where we introduce and discuss the 2i2c Hub Service pilot:
We should take a pass at both of them to make sure that we are discussing and highlighting aspects of our Hub Service that we wish. For example, here are a few things that I think we should improve:
Expected timeline
We should make iterative improvements to the documentation over the next several months, but should plan on a "deep dive" on the docs after we've had a moment for others to use the docs, run through a few customers, etc.
Steps to complete this goal
The main thing we should do to complete this goal is have a deep dive on the docs as a group of one or more people, and make updates until we are satisfied with the "next iteration" of describing the hub services. We should also run the docs by a few others to get their feedback.
The text was updated successfully, but these errors were encountered: