Consider an alternative to Slack

[jbottum]

Per this slack thread, slack deletes threads after a certain period of time. Some of this information is valuable.

should we consider an alternative? Do we have members who can provide a plan?

https://kubeflow.slack.com/archives/C7REE0ETX/p1678279529394549

[metafeather]

Thanks for looking into this, it's definitely an area that getting some wider discussion for open source projects, for example: https://news.ycombinator.com/item?id=35050858

[StefanoFioravanzo]

I have seen other communities using GitHub discussion forums pretty successfully. GitHub Discussions help keep info organized since they force you to start a new "thread" for each question/topic. It acts like a forum.

Every repo can set up a specific forum for repo-specific topics. And we can have a community forum in the community repo, or an ad-hoc repo. I like how the executable book community does it, using the meta repo: https://github.com/executablebooks/meta/discussions

This is something that, if we want, we can experiment with cost-free.

[terrytangyuan]

Once the project is donated to CNCF, we can use the channels where the messages will be reserved. https://slack.cncf.io/

[akgraner]

Thanks @terrytangyuan for pointing that out - after a quick search of the sandbox projects on the CNCF workspace, sandbox projects get those resources as well. So do we want to come up with a new process then have to move to the CNCF workspace or see how we can move to the CNCF space sooner? This might be another point of interest to move to Sandbox first just to get into the CNCF, then continue working on the Incubation stage. Just a thought.

[StefanoFioravanzo]

I see the two as being complimentary. Moving some slack convos to the CNCF slack would be helpful and necessary since an RCS system is always beneficial for 1:1 messaging, announcement channels, or broad convos in general.

GitHub forums or similar systems can help bring more structure to newcomers and technical and development assistance discussions.

[terrytangyuan]

For instant messages, I'd recommend sticking with the current Slack workspace until we move to CNCF to avoid additional work and confusion (imagine that we asked community to switch to Discord and then switch to CNCF Slack workspace). I recommend trying out GitHub Discussions for Q&As since it's proven to be very helpful to the Argo community: https://github.com/argoproj/argo-workflows/discussions

[theadactyl]

Hi all, We can't move any channels over to CNCF while we are still under review and have not yet been accepted. I'd advocate for using non-ephemeral channels for important conversations (ie issues, PRs, mailing lists), even in the case that we have a chat solution that stores messaging. Burying decisionmaking/design discussion in synchronous channels makes it hard for those who are new to the community or have less time to keep up to get involved in important discussions.

Re: GitHub Discussions -- I havent had a great experience with these, unless managed at the organizational level, and especially if there are actual mailing lists the community is split between. Discussions can become very fragmented if used at repo level across multiple repos.

[thesuperzapper]

My 2 cents are that we should be clear about what each communication tool is for, I think Slack has its place within our toolkit, but we need to be careful to not use it for the wrong things.

For example, we might decide to split our tools up like this:

• GitHub Issues & PRs:
  • Persistent: yes
  • Searchable: yes
  • Topics: actual work items
• Mailing List (Kubeflow-discuss):
  • Persistent: yes
  • Searchable: yes
  • Topics: community-wide announcements; things not related to specific work items
• Slack (perhaps Discord in future):
  • Persistent: no
  • Searchable: not-really
  • Topics: real-time messaging between users (both in channels and direct messages); video calls/huddles

Also, given how large and complex Kubeflow is, it might make sense to maintain a separate Slack to the CNCF one (but still have a channel in the CNCF one), similar to how Kuberntes maintains a non-CNCF Slack server.

[theadactyl]

Also, given how large and complex Kubeflow is, it might make sense to maintain a separate Slack to the CNCF one (but still have a channel in the CNCF one), similar to how Kuberntes maintains a non-CNCF Slack server.

Strongly agree. We can always request a slack channel there that has a pinned redirect to our full server. Migrating to one channel would flatten our channel architecture and likely decrease overall engagement in Slack.

[terrytangyuan]

I shared some experience for the Argo project of migrating to CNCF Slack channel here cncf/toc#1139 (comment)