Hello all,
based on the discussions in the Jupyter Server Workshop last week, should the Enterprise Gateway category be renamed and extended to Jupyter Server? I don’t think there’s much point in having separate categories for Jupyter Server and Enterprise Gateway. In particular because we hope that Jupyter Server will make the Enterprise Gateway redundant 
cheers,
Roland
I really like the idea of having a space to specifically talk about jupyter server protocols and the ecosystem of tools around the jupyter server.
@lresende what do you think? You’ve done a lot of work engaging in the Discourse here, is this a reasonable step?
Although the traffic in this category is limited, Enterprise Gateway will have two major releases under its belt shortly. Yes, with the move to Jupyter Server, most of what EG provides will probably go away but, given there are extant releases, I think it makes sense to retain the EG category. On that note, I’d be more inclined to rename it Gateway Projects, or something of that ilk, and open it up for any discussions regarding Kernel Gateway as well (which, itself has 2 major releases). I’d be okay with making that change at any time - assuming others agree.
That said, I definitely believe we need a Jupyter Server category - one way or another.
I think most people won’t make the connection between the Gateway projects and the Jupyter Server at this point in time. It will be important that we clearly communicate their relationship as we push the Jupyter Server forward. Part of the problem is that most people don’t know what Jupyter Server is. This is something we will hopefully overcome as the project develops.
I propose we create a separate Jupyter Server category. Once the Gateways adopt the Jupyter Server, we can maybe merge these two categories?
One option would be to follow what we do in JupyterHub, which is to use the parent category as the most generic jupyter tool that is relevant, and then use sub-categories for more specific implementations of the project. E.g., Zero to JupyterHub for K8S, or The Littlest JupyterHub.
Would the relationship between the enterprise gateway and the jupyter server be similar? I feel like “Jupyter Server” is a pretty generic category, while “enterprise gateway” is a more specific thing, but I may be understanding the technology incorrectly
So to be clear, what I’m proposing would be:
etc
Although they are absolutely “server” based, it remains to be seen whether the gateway projects, Kernel or Enterprise, will ever use Jupyter Server. I suppose one could argue that Kernel Gateway’s HTTP Personality has the “best shot” at becoming an ExtensionApp. (In fact, I think it would make a great POC datapoint for JS.) I could also envision there being enterprise-level extensions (most likely surrounding HA and, possibly, multi-tenancy) at some point, although I don’t think “gateway” would necessarily be appropriate.
Based on Zach and Chris’s responses, I think we’re converging on the following…
@choldgraf - A good candidate sub-category for JS would be Kernel Providers. This is probably where most of EG’s functionality will move. Not sure we need to create that right away, but I think its a good example of a sub-category relative to JS.
I didn’t realize that there could be sub-categories, so I’m wondering if we could have Gateway Projects - with Kernel Gateway and Enterprise Gateway as sub-categories?
I’m happy to do whatever y’all think is best for this sub-community 
For creating new categories, I’ll need brief descriptions (one or two sentences) that describe what they’re about and potentially point people in the right direction if they want more info. Similar to About the JupyterHub category
here’s what it sounds like we could do:
Do folks think this is a good plan?
If people agree, then once I get the brief descriptions for these I’ll create the categories
I agree with this approach, although I’d like buy-in from (minimally) @rolweber and @lresende regarding the reorganization/introduction of the various gateway projects. So, assuming we would be moving forward, here would be my proposals for the various descriptions…
(I reluctantly used JupyterHub’s “A place to discuss” preamble. These are nothing more than seeding suggestions.)
Jupyter Server: A place to discuss Jupyter Server, the next-generation backend for Jupyter-based applications.
Gateway Projects: A place to discuss the gateway projects Jupyter Kernel Gateway, Jupyter Enterprise Gateway and NB2KG.
We’ll want a couple “When to use” topics right off the bat here.
@choldgraf - Can topics from a sub-category be pinned in the parent category? For example, each “when to use” would be useful in the sub-categories as well - so I’m thinking they should reside there and let the parent reference them (pinned as well).
Kernel Gateway: A place to discuss Jupyter Kernel Gateway, a web-server that headless access to Jupyter kernels.
Enterprise Gateway: A place to discuss Jupyter Enterprise Gateway, which extends Kernel Gateway to provide functionality for distributing Jupyter kernels across managed compute clusters and other enterprise-level functionality.
NB2KG: A place to discuss the NB2KG (Notebook 2 Kernel Gateway) project - a Notebook server extension that proxies kernel-related requests to Jupyter Kernel or Enterprise Gateway on behalf of the Jupyter Notebook or Lab web applications.
I’m fine with keeping Jupyter Server and Gateway Projects as separate categories. But I have doubts about creating a full new hierarchy of categories, including one for Kernel Gateway.
From mailing lists and other discussion forums, I’m used to the approach that new “places for discussion” are created when there is sufficient public interest. Have there been discussions about Kernel Gateway here on discourse? Enough to make a separate category worthwhile? Having two major releases doesn’t mean much if nobody comes here with questions or suggestions.
That’s why my initial suggestion was to re-use the EG category for Jupyter Server: Have a common place for discussions around the server side - headless kernels in whatever flavor - and then wait for people to actually post there. I’d say the time to create sub-categories is when the parent category gets too much traffic about a specific area of interest. “Too much” meaning that other areas of interest are drowned by the noise from the one.
Defining categories alone won’t create interest in discussions. And a category that barely gets any posts is not exactly good advertising. From this angle, I’d rather not create a category for KG now. Announcing a new release of KG in a category shared with EG, and/or with Jupyter Server, will still give it sufficient visibility.
cheers,
_ Roland
I agree that the gateway projects are on the Island of Misfit Toys, so to speak. There has been very little traffic but I think one of the primary issues with the Jupyter project set is folks don’t know various things even exist. That’s why we (EG) have tried to promote the project as much as possible and, I believe, those efforts are paying off.
I feel that the gateway projects should be separated from Jupyter Server - mostly because these Discourse categories tend to be git repository or organization based. If the plan is that the Jupyter Server category is more about Jupyter server-based projects, with “Server” being one of them, then perhaps dropping Jupyter from the category title and going with Server or Server Projects is a better way to go with sub-categories like Jupyter Server, Kernel Providers, Gateway Projects, etc. underneath.
Since it sounds like category organization is fairly pliable, how about this as a starting point:
Create a “server oriented” project. I’m okay calling it Jupyter Server out of the gate, but I think @Zsailer, @choldgraf, and the primary stakeholders should decide that organization. Whatever name is chosen, I would encourage a notion that sub-categories will be needed down the road.
We rename Enterprise Gateway to Gateway Projects (assuming @lresende’s buy in) and not create any sub-categories. The updated description should sufficienty describe the category’s purpose.
As the evolution of the Jupyter Server project transpires, we can revisit whether it makes sense to move Gateway Projects to a sub-category of whatever the “Server” category is named.
I experimented a bit, and I think that you cannot pin a sub-category item in the parent category (e.g., see https://discourse.jupyter.org/c/site-feedback). We’d need to keep the pinning within the sub-category level, or create a pinned topic in the parent category that pointed to the sub-categories.
re: high-level categories etc, I don’t think we necessarily need / want a “one repository to one category” mapping. E.g., for “JupyterHub”, the parent category is a catch-all term for any jupyterhub-related stuff, and sub-categories are for more repo-specific things (e.g., The Littlest JupyterHub or Z2JH). For JupyterLab there is a 1-repo to 1-category mapping, but that’s I think because JupyterLab is a much more complex/multi-faceted project than many of the other Jupyter tools. I actually wonder if the parent category should be something like “User interfaces” and JupyterLab would be one sub-category of this, but I digress
I think we do want to be selective about which parent categories are there. In my mind the question is “is this category a major, core component of the Jupyter ecosystem, and does it have several projects/issues that could be sub-categorized under it?” It seems like “Jupyter Server” topics would fit that category, but I don’t think I have the right technical perspective to make that call.
Maybe @minrk or @carreau has thoughts on the jupyter server categorization thread, since they’ve been involved for much longer than I!
I like the following
This would allow each initiative to be visible without overloading the category tree. If more dedicated subcategories as “Kernel Providers” are needed, they could be added later on.
JupyterHub, BinderHub are in fact also servers, so the question is “should they stay top level or become Server subcategories”
I think we few people who want to push Jupyter Server should not try to re-organize existing, much more active areas of this Forum. Let them stay top level, that’s where the users expect to find them.
That’s also a good reason for not claiming a very generic term like “Server” as the name for a new category.
I’m gonna let you all figure out the right structure for this part of the Discourse - I agree we shouldn’t change any of the other high-level Discourse topics (right now, anyway) with the exception of the “Enterprise Kernel Gateways” topic in case that gets folded into a broader topic.
Once there’s a consensus around “High-level topic -> A few more specific sub-topics” then I’m happy to re-work that section of the Discourse for you all. Does that work?
I think “Server”—or maybe “Server-side components” to be more specific?
I think the main reason “Jupyter Server” doesn’t work as the top category is because jupyter_server is an actual repo name. It’s ambiguous whether we mean Jupyter Server in the general sense or specifically the jupyter_server package. Synthesizing some of the suggestions here, I like:
IMO ‘Server’ or ‘Server-side components’ seem excessively broad. For example, the following things have the word ‘server’ in them:
There’s also the common phrase ‘my server is not working’ that we hear extremely often in the JupyterHub world, and it meaning so many things…
I am also not sure ‘Telemetry’ fits into this (since it has client side components as well), and if it does, the category is extremely broad 
Perhaps tags can be better use here if needed? Although IME the only way to figure this out is to create something overly broad (I propose jupyter_server) and wait to see what kinda stuff people post there. Can’t do this without that…
on that point - it’s worth noting that we do have the ability to re-configure, move topics, rename / split them, etc. Especially since the community forum is relatively young, I think it’s OK to “try stuff out” and iterate
One thought is we could call this “Jupyter Servers” or “Jupyter Server Tools” instead of just “jupyter_server” to try and distinguish between the two.
definitely a huge lack of awareness. I myself am getting around to sifting through old discussions in hopes of serendipitously coming across useful and relevant things like this thread.
I like where your head is at with the categorization
As someone who explains Jupyter to a lot of people… the word “server” is so grossly overloaded. 
notebook server, jupyter server, running on other servers, which can be virtual or physical “servers”…
it’s nuts. I think this category/renaming is an important discussion to have
