/assign @andreyvelich @terrytangyuan

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: terrytangyuan, thesuperzapper

The full list of commands accepted by this bot can be found here.

The pull request process is described here

@thesuperzapper There are not internal Slack channels.
#wg-automl and #wg-training are the updated channels where we ask our users to join.
#kubeflow-katib and #kubeflow-training-operator are the legacy channels.

@thesuperzapper Are you going to submit PR to update it back ?

@andreyvelich , that is not correct, when we made those channels we were clear that the users should discuss in the #kubeflow-xxxx channels, and the working group members should discuss in #wg-xxxx.

It's also a lot less confusing, because users don't think about the working groups they think about the app they're using.

Furthermore, if you compare the member counts of each of these channels, the #kubeflow-xxxx ones have at least 2x as many members, so I would highly recommend you continue using those.

@thesuperzapper We've been promoting wg-training and wg-automl channels for our users for the last 3 years.
And we have 281 and 277 members in these channels. Many users actively post their questions in these channels.
For WG discussion we have separate closed channels where our working groups leads are invited.

Other channels (kubeflow-katib and kubeflow-training-operator are the legacy channels, they were created before ~5 years ago, and that is why they have more people there).
Also, our Slack channel for users in the WG Charter here: https://github.com/kubeflow/community/tree/master/wg-automl#contact

@kubeflow/wg-training-leads @tenzen-y Please comment on this thread.

@andreyvelich firstly, the reason that channel is listed in your charter is because it's where you're meant to discuss working group matters .

You're not really allowed to have private channels, as the working groups are meant to operate in the open, where possible.

I would suggest that you either make your main channel open or you can just start using the official channel. (After you make your private channels open , we could rename the existing #wg-xxxx channels to #kubeflow-xxxx, if you would like, but that seems unnecessary given your private channels probably have less members).

You're not really allowed to have private channels, as the working groups are meant to operate in the open, where possible.

Why this statement is true ? I don't think we discussed it before.

(After you make your private channels open , we could rename the existing #wg-xxxx channels to #kubeflow-xxxx, if you would like, but that seems unnecessary given your private channels probably have less members).

I don't understand why we can't keep channels as wg-training, etc. ?

For example, for Manifests we have wg-manifests and for Notebooks we have wg-notebooks channel.
We should be consistent across different Kubeflow components to not confuse users.

cc @juliusvonkohout @kimwnasptd

The main channels for users to ask questions about Notebooks and Pipelines are

• #kubeflow-pipelines (2999 members)
• #kubeflow-notebooks (1289 members)

The #wg-notebooks channel is used by the working group to discuss working group matters.

Also, I'm not sure that the pipelines working group actually uses slack for this purpose so they don't have a channel as far as I can see.

The reason it's good to keep these separate is because we want people asking questions but we also don't want them interrupting our work.

And also they're going to search for channels based on the thing that they're using, rather than the working group which owns them.

I think, the main reason is why these channels have more users because they were created earlier (5 years ago) than WGs were established (3 years ago).
For example, Notebooks working group maintain 9 components. Do we need 9 Slack channels for users ?
Decreasing number of channels will be better I think, since users don't need to know about all existing Kubeflow Slack channels.

I am happy to discuss it during our Kubeflow Community Call to provide consistent across Kubeflow components.
cc @jbottum @james-jwu @zijianjoy