Category for Kernel Gateway


I was talking with Luciano today and he asked about creating a category here for the Kernel Gateway. Are folks ok with my doing that? Can I add him as a moderator for the category?



For now we’ve exhausted the number of moderators we can have :frowning: In practice admin’ing mostly means sysadmin stuff, so far there has never been a need to use any of the moderation powers towards users.

I have no strong opinion on adding a category or not.



Luciano proposed the category name “Enterprise Gateway”.



I am not keen on being a moderator. I mainly want to leverage discourse to remediate some of the gitter pain points already expressed here for the Jupyter Enterprise Gateway project.

1 Like


A kernel gateway category would be fine with me. Let’s see if someone else has an opinion on this. Otherwise I’ll create it.

We also seem to have settled on having Q&A as a general point of arrival/landing page (discussion in Direct questions about jupyter/docker-stacks to Discourse?). I like the idea of assuming that most people will post there first and then things get moved as it becomes clearer where they belong.



@lresende do you think a category for “Enterprise Gateway” would cover both the kernel gateway and the enterprise gateway?



@ellisonbg Yes, “Enterprise Gateway” should cover both



FWIW, there’s a convo happening in Direct questions about jupyter/docker-stacks to Discourse? about a general Q&A category for questions that span multiple Jupyter technologies or don’t fit into any particular topic. The question of “then what remains in project specific areas?” came up and was discussed along the way.

A category per project for project-specific conversations makes sense to me alongside the general Q&A category.

UPDATE: Wrong link paste. Enjoy the twitter video if you clicked it before I could fix it. :slight_smile:



I’m fine with having Kernel Gateway as another item in the channel list :+1:



There is now

1 Like


Let’s initially try to keep the number of channels low. We found in Python that too many categories was a bit confusing. Instead, perhaps let’s use the channel description to list both projects.



That’s useful feedback! Do you know if anybody in Python world has blogged or written up their experiences with the Discourse there? I agree it’d be good to leverage the experience of other open communities in helping guide our own community forum.

One thought: we could keep the high-level categories split up more by “use case” instead of by technology (e.g. technical-ish ones like “cloud deployments”, “user interfaces”, or more user-centric ones like “education”, “reproducibility”). Then within those high-level channels, we could list product-specific sub-channels.

I’m trying to think of the mindset of someone when they arrive at the Jupyter Discourse. Do they think “I have a question about JupyterHub?” or do they think “I need help hosting a shared data analytics environment in the cloud, and maybe Jupyter can help me?”



I think they will arrive thinking “I’ve got a question about $stuff and its Jupyter” when it turns out their question is actually about Rmarkdown. Basically, I think when we are new to a project/area and something isn’t working we know nothing. That is why I think in a lot of forums (of years gone by) the “random” category grows to be the biggest one. I think that is fine and expect this to happen here as well.

1 Like


Yeah, this is definitely a challenge to not overdo the number of categories. Too many, and no one can figure out where to post/look. Too few, and people turn to other comm channels that are more focused (private emails, gitter, etc.) because it feels like you are having personal conversation in the middle of a stadium.

At the same time, Jupyter is a very complex ecosystem than python with >100 repos, multiple orgs, and multiple micro-teams/communities. Given that, I think a key question for us to ask is “where are the conversations on topic X happening now?” and “would creating a category on discourse improve transparency, inclusion, etc. compared to the status quo”