The community has been in discussions since October 2018 about moving the live chat community to Discord from Slack since several communities of comparable size to Mautic have had their instances restricted or found the feature set lacking as they scaled (React, Grav, Sia) (see discussion here on Mautic’s Slack instance – search for Discord to find other related discussions).
The Core and website project teams have used Discord effectively since December 2018 and we believe it will be a more stable live chat platform for the community going forward.
This transition requires some effort to fully move across to the new platform, which we believe needs to happen imminently as we are approaching the ‘danger zone’ where Slack may begin restricting new invitations.
It does not seem this was a democratic desiccation, it might be worth considering Rocket.chat whom unlike slack or discord is FOSS and more suited / mature as a tool.
It scales almost limitless.
Communities using it include Ubuntu, Drupal and many more.
@floris the conversations were happening at a point when I wasn’t actively involved in the threads, so I can’t comment on whether it was a democratic decision or not - although I’ve linked to the threads I could find.
There has already been quite a bit of work happening over on Discord for some time (e.g. in the core & website channels) and there are 110 people over there already without a structured migration happening. We have the open source plan - see https://discordapp.com/open-source for more info and other Open Source projects who use it.
If it’s seen as something that the community feel needs to be debated as to what specific platform to use rather than going with Discord as suggested, then we will need to have that discussion soon!
I use Rocket.chat every day for my day job, and unfortunately I find it quite immature and buggy. Also it is not decentralized, and would require its own hosting. However, I agree that a FOSS tool would be a more appropriate choice than Slack or Discord. https://matrix.org/ is a great option for many reasons. I think it will eventually replace IRC.
I guess my query is, do we actually need a live chat if we have forums that work effectively? What is the value, if we have Jitsi for community calls? It’s one more place for people to get lost with their requests for support, one more place to monitor. Just thinking out loud (perhaps a discussion for the forums!)
@rcheesley IMHO live chat is a hugely valuable tool in FOSS collaboration and I would be strongly against abandoning it. It fills an important gap between fully synchronous communication like Jitsi and fully asynchronous like email / forums.
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’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
@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.
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
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.
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
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.
