Mautic Community Forums

Moving Live Chat systems

So maybe a good way forward might be to have a thread on the forums in which we can have a timeboxed discussion (maybe over a week or something like that) on what the key features are relating to a live chat facility, come up with a shortlist, and then make a decision as a community at the end of that time period. Does that sound like a good step forward?

I agree with @aspiers Some conversations are better held on forums (async), like support requests.
However, some conversations are more fluid and real-time nature. On top of being useful for collaboration, it can also be warm(-er than forums) and more welcoming place to “drop” newcomers in, so they can get guidance. If they ask for support, we just redirect them to the right forum (if mautibot could do that it would be fantastic!)

If it’s not a hurdle for you, why not enable both and let users decide where they want to start each conversation?

I guess we then need to be clear what we point at the forums when they arrive in chat, which they will, and what we use the chat facility for.

I’m not sure we need to be explicit about when to use the forums vs. the chat. When people want semi-synchronous comms they’ll use chat, and when they want more considered asynchronous discussion spanning longer time intervals, they’ll use the forums. This will happen naturally like it does anywhere else. Both are perfectly valid and needed forms of communication, and they can complement each other nicely.

The discussion about what live chat solution to use is probably going to be more difficult to resolve. I think Ruth’s suggestion of starting a discussion thread is a good one, but there will be no single tool which everyone is in favour of, so yes it needs to be timeboxed otherwise the bikeshedding would last forever. FWIW I’m a strong believer that Free Software Needs Free Tools, and just like the Bitkeeper example in that talk, this was demonstrated perfectly by Slack’s decision which forced Reactiflux to move elsewhere. History keeps repeating itself: if you use proprietary tools, you put yourself at the mercy of the companies controlling those tools. But now I’m getting into a discussion which should be saved for the forum thread so I’ll stop here :wink:

@aspiers Sure, but we’ve not had forums in so long, people come to Slack for everything. It’s more sensible to use the forums if it’s easily searched for previous questions etc.

Hi folks,

So, taking a step back on this issue, I put out a query in various community management/developer relation circles to see if anyone knew exactly what the determining factors were for getting sanctions imposed, and was pointed at a few very large communities using Slack - example https://invite.slack.golangbridge.org/. 44,420 registered users :exclamation:

This morning, I sent Slack support a message asking directly about this ‘upper limit’ and whether it applies to communities who are on the complimentary Open Source plan.

The response is as follows:

Hi Ruth,

Thanks for reaching out today. While I cannot share specific information about other workspaces, the publicized reports we’ve seen of Free Plan workspaces experiencing issues with an “upper limit” were not using Slack the way it was intended, and found difficulty using the product in a way that supported how they wanted it to work, rather than what it was designed for.

For our customers using Slack as a collaboration tool for work or projects, the product can comfortably support an unlimited number of users.

If you have any additional questions, I am happy to answer them.

I have asked for clarification on what is classed as “not using Slack the way it was intended” and will report back.

While I do agree that Slack has some shortcomings, I think at this point if we don’t have to move platforms, it would be one less thing to cause problems and difficulties with the community at a time where we need to focus on bringing people together and avoiding disruption and confusion.

Feel free to discuss and give your thoughts/opinions!

Just to remove any ideas that this was not democratic. It was democratic, there was an open vote. There was even the ability to state your preference if you couldn’t make the call, so your vote would be counted.

The deal with Slack is that moderation on Slack absolutely sucks. There is no proper role system. It was ultimately designed for teams, not large communities. This is also what they mean with “the way it was intended”. At TYPO3 we got the same message from them. Slack is not a good solution to our needs, and I really dislike using it just “because we always have”.

My experience with Rocket.chat is limited. We tried it, it was rather problematic. We ran into issues along the way, plus the fact that you have to entirely maintain the instance yourself. I’m not sure why someone would do that when there are free alternatives available that entirely eliminate this work and responsibility. I also highly disagree that this tool is somehow more mature, far from it in fact.

Discord is also not perfect, but it is free and they are actively embracing OSS communities (see their website) and have already given the Mautic server all kinds of extra perks that are normally only reserved for partners or paying users. Besides that, Discord actually has an intuitive bot API which is far, far superior to what Slack offers.

If we decide to stay with Slack, we will need to add more people to the admin group who can properly moderate the thing. AFAIK only David can now actually do stuff like delete messages.

My 2 cents.

@Woeler afaik, there is no generell decision at all, right? Democratic was just the try-out move of the core team to Discord.

In my opinion, all alternatives to Slack have serious downsides too, and we surely have much more important issues at hand than moving from one chat to another.
I would plead to
a) stick with Slack for now
b) add more mods, see @woeler
c) come up a best practice guideline on what should be in the forums, what in chat

So this was the response from Slack:

Hi Ruth,

Thanks for the follow up. As your workspace is technically on a paid plan (although at no cost as it is a comped workspace), many of the restrictions applying to very large, Free Plan community workspaces will not apply.

However, examples of behavior outside of intended use include:

    • Activating and deactivating large (several thousand) groups of members in a short time frame (i.e. trying to create something similar to the “guest account” feature on paid plans using the Free Plan)*
    • Hosting (or attempting to host) large, real-time classes that regularly exceed the 10k messaging limit for free workspaces, or attempting to use the call feature to send out large groups of calls at one time skirt around call member limits*
    • Attempting to disseminate documents, files, etc that far exceed the storage limits on the Free Plan by uploading, downloading, and deleting large amounts of files in a short time span*

Generally, these issues are felt by organizations that are attempting to host groups of people best supported by our Enterprise Grid plan on the Free Plan. Our paid plans regularly support organizations of up to 500k.

So from what I can see, we are in no immediate danger of having the instance turned off, however as @woeler mentions there are some shortcomings in Slack.

In the short term, I’ll see what I can do re. adding more moderators on Slack.

@aspiers guess your instance used for your company was not updated for a long time, plese join https://drupalchat.eu/register/beta and re evaluate your findings.

@floris It was updated to the latest version recently. There are still significant bugs with notifications, for example.

Update on this - we are staying on Slack at the moment, and if we feel there are features Slack is missing please share them and we’ll look into this as a community discussion on the forums and review possible options. Ruth will prepare a communication to this effect and will inform those on Discord.

So should we shut down Discord to avoid any confusion ?

@npracht I will prepare some comms around this decision which will include informing those on Discord and deciding how we proceed.

There is a Discourse chat plugin which I added to my instance. Works OK.

1 Like

We have got the Discourse to Slack integration working already, if that’s what you’re referring to. It pushes all public messages into the forum channel on Slack for those who like to get a notification that way.

I’ve drafted the article as outlined above and shared it on Slack in #community for feedback before I post it up.

Maybe the same one, but I’m using it without any connections to other chat clients so it is standalone.

Thanks for sharing! Yes, that’s the integration we have got set up currently to push public forum activity into Slack. It works really nicely!

1 Like