Should Chapel's community chat solution move from Gitter to Slack?

[bradcray]

[HPE devs: Note that I've made this a public issue since it affects users; if you
want to discuss things that might be sensitive in the public, let's kick off a
private issue for that part of the conversation]

As most of us on the team use Slack in our day-to-day lives, we're finding we
enjoy it much more than Gitter. To that end, we've been discussing whether
we should pull the plug on our Gitter-based support in favor of a Slack channel.

Here are some of the tradeoffs as I see it:

• Slack generally has a more modern and capable UI
• Gitter supports Chapel syntax highlighting [this no longer seems to be true with
  Gitter's move to Element] and Slack does not at this time,
  nor a way to extend its highlighting to include new languages. I've put in a
  feature request for such an issue and got a prompt and encouraging response,
  but it's not clear whether anything more has ever come of it.
• Gitter is arguably designed for good integration with GitHub (e.g., #​1234 points
  to the appropriate git issue) [this no longer seems to be true with Gitter's move to
  Element], but Slack's GitHub integration may negate this advantage
• with Slack, there may be questions about how far we'd get with a free instance,
  whether we'd want to pay for an instance, or whether we'd want to tuck it into
  some other organizations Slack instance

Note that I think we would not want to keep both options for more than a transition
period because of already having too many community interaction channels to
monitor and juggle (Discourse, SO, email, Gitter).

I think next steps here are:

• identify a champion to look into moving to Slack, understand the tradeoffs
  better, and see if they can effectively sell the team on it or not
• determine what our hosting strategy would be
• poll the community to see what the reaction is like and weigh that against our
  own ability to monitor either technology

[king-11]

• Slack has webhook integration for github and other tools too not sure if gitter has it
• I think I have seen bots in slack too which are quite appealing for multiple use cases
• separation of concerns using multiple channels
• [paid] option to start a call

The only downfall would be no as such default integration with GitHub and having to pay for it otherwise you start losing conversations.

[lucaferranti]

my two cents:

I think gitter is good for a small(ish) group of people discussing one common theme. E.g. gitter works nice as a core-devs room. However, as the community grows, I think gitter does not scale that well and apps like slack / zulip / discord are better. The reason for this is that when the ecosystem grows, it's becomes almost inevitable to organize discussions in different channels as they do not fit one room anymore. For example, one channel for compiler related discussions, one channel for CHIUW, one for machine learning in chapel, one for optimization in chapel, one for chapel in teaching, (a channel for memes :) ), etc. etc.

As a competitor to slack, I would also like to suggest zulip, zulip has all the advantages of slack, namely:

• multiple channels
• github integration
• possibility to bridge with other communication forums such as gitter, slack, discourse (to be fair, also slack has this feature, which I think was not mentioned above)
• markdown formatting
• allows syntax highlight for many programming languages (chapel seems to be there too)
• supports LaTeX!!
• fully open-source, can also be self-hosted
• The main complain of people in slack is the limited memory and that messages disappear after a while, in zulip the message history stays
• organize discussions in threads. This is actually what makes zulip unique. Basically in zulip every message is in a "named thread", that is when I send a new message in a channel I also give a name to the thread (called topic in zulip jargon). Then peole can answer in the channel to that topic. Messages in a channel can be browsed in "stream mode" à la slack, or filtered by topics. This allows more granularity than just channels.

[DanilaFe]

One advantage of Gitter over Slack that I wanted us to be aware of: Gitter conversations are indexed by search engines, and are thus searchable from Google. I have previously found answers on Google by reading a discussion that occurred on some repository's Gitter. I don't know for sure if that's possible with slack, but I doubt it.

[ronawho]

The Chapel syntax highlighting, topics within a stream (think better nested threads within a slack channel), and support for better message history (especially if we can get sponsored as an open source project) make zulip a really attractive option to me. I've generally really liked slack, but have been annoyed by the recent free-tier switch from 10,000 message history to 90 day message history and do find that topics can get lost in a busy channel. I think it'd be worth having a few core team members trial zulip to get some real world experience and report back (and I'd be happy to kick that off.)

I will note that at first glance I find the zulip UI to be really busy and not as sleek as slack, but I'm not sure if that's just because I'm so used to slack at this point.

[bradcray]

With this week's migration of gitter to element, we're no longer getting Chapel syntax highlighting nor auto-linking of GitHub issue/PR numbers, which were two of the big advantages of sticking with gitter over moving to slack.

[DanilaFe]

One advantage of Gitter over Slack that I wanted us to be aware of: Gitter conversations are indexed by search engines, and are thus searchable from Google. I have previously found answers on Google by reading a discussion that occurred on some repository's Gitter. I don't know for sure if that's possible with slack, but I doubt it.

Since Gitter's move to Element, I am actually not sure this is still true. Googling, I haven't been able to find any page from Gitter that was publicly indexed. So there goes another advantage of Gitter.

[lucaferranti]

In zulip you can configure this pretty nicely. You ca make some channels public and they are then findable via google but also make other channels not visible to non-registered people