A more Open-Source Slack-like alternative is Mattermost which is a self-hosted, FOSS Chat service.

RedHat OpenShift.io team has been using this on their end and its really good

@Marviiin could do you think there would be any interest in better Discourse integration for Riot.im? It looks like the ability to post a transcript from Riot.im to Discourse would be helpful: https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522

CKoerner_WMF added a comment.

I'm curious to hear thoughts on how this might relate to existing
efforts, particularly the Discourse pilot. Real-time, Q&A, and forum
communication softwares all are very over-lapping in their features.

There is overlap, but forum software, especially Q&A software, is
lacking when it comes to the possibility of instantaneous feedback and
real time interaction. It is also targeted towards Q&A, not unstructured
social interactions.

Think of it this way: WMF is putting a Discourse server into production,
but, by doing that, do they say "well, there is overlap between this and
in-person conferences, so we'll drop the conferences"?

Of course not.

IRC, which is widely used by the WMF, already provides the real-time
communication capability we hope to get from a Slack-alternative, but it
lacks a searchable archive that is integrated into the chat experience
for someone who is just joining the chat.

Finally, an argument could be made that everything Discourse does could
be done on Phabricator. A similar argument would be to say that
everything Phabricator does could be done on a wiki.

Or, reductio ad absurdum, everything you do on a Wiki could be done with
paper and ink.

If we look at @CCicalese_WMF's bulleted list, Discourse probably could
fulfill all those requirements. I imagine this is because she wrote it
with Slack in mind and didn't think it was necessary to state the need
for "real time, unstructured, online interactions."

If we look at @CCicalese_WMF's bulleted list, Discourse probably could
fulfill all those requirements. I imagine this is because she wrote it
with Slack in mind and didn't think it was necessary to state the need
for "real time, unstructured, online interactions."

Good point. It is now a bullet.

So, on the Matrix side we would love a bridge to Discourse. The Discourse folks have already written a very basic bridge bot (https://meta.discourse.org/t/set-up-matrix-riot-im-notifications-using-the-discourse-chat-integration-plugin/66944), and there is also a wider discussion about using their bridging plugin system versus Matrix’s own bridging APIs over at https://meta.discourse.org/t/common-event-system-for-chatrooms-a-specification/59245/8.

The main conclusion is that whilst Matrix’s bridging semantics are incredibly powerful (cf https://matrix.org/blog/2017/03/11/how-do-i-bridge-thee-let-me-count-the-ways/), the fact we don’t have threading yet (although we desperately want it) makes for a big impedance mismatch with Discourse. So, if threading is a top priority right now, i’d go with Discourse. But if chatroom semantics are more desirable, Matrix is (hopefully) a no-brainer.

@Marviiin, you're perspective here is invaluable.

In T184606#3897319, @Marviiin wrote:

The main conclusion is that whilst Matrix’s bridging semantics are incredibly powerful (cf https://matrix.org/blog/2017/03/11/how-do-i-bridge-thee-let-me-count-the-ways/), the fact we don’t have threading yet (although we desperately want it) makes for a big impedance mismatch with Discourse. So, if threading is a top priority right now, i’d go with Discourse. But if chatroom semantics are more desirable, Matrix is (hopefully) a no-brainer.

I don't think this is really an either/or situation. I think both/and (which assumes integration between the two) is what we're looking at. It looks like we're going to have Discourse. (I was happy with Flow, but, then, I was happy with LQT, too. All that is beside the point right now.)

I would say that as long as we can provide an IRC bridge for our "installed base" to whatever chat solution we have, then we have a good baseline. If we can work together with people like @Marviiin, then we can adopt a solution that aims for better future integration.

Finally, I wonder is there a Matrix/Freenode shared chat channel anywhere? Since our IRC contact points are currently on Freenode, it would be interesting to see if adding what adding Matrix would look like.

Finally, I wonder is there a Matrix/Freenode shared chat channel anywhere? Since our IRC contact points are currently on Freenode, it would be interesting to see if adding what adding Matrix would look like.

Answering my own q: https://matrix.org/blog/2015/06/22/the-matrix-org-irc-bridge-now-bridges-all-of-freenode/

In T184606#3897319, @Marviiin wrote:

the fact we don’t have threading yet (although we desperately want it) makes for a big impedance mismatch with Discourse.

If I understand you correctly, not really, because Discourse doesn't support threading. They are quite adamant about flat topics. :)

For a related discussion, see https://meta.discourse.org/t/slack-threads-and-chat-integration-plugin-transcripts/71909

Then again, is threading a hard requirement for the needs of this group? If Slack is the main reference, it wasn't threading what made it so successful. :)

hm, fair enough. i guess you would still have an impedance mismatch due to every new discourse topic really needing its own thread in Matrix, as creating a new room for each topic would surely get unwieldy quite rapidly.

I'm glad we're having this discussion about integration.

It sounds like @Qgil and @Marviiin are talking about integration in the sense that every interaction on the chat system is duplicated on Discourse. I don't think any of us want that. It would quickly get too noisy and become useless.

Instead, it would good if we could have a way to have a specific portion of a conversation in chat posted to Discourse where it could be editted and summarized for easy reference later.

Or, maybe I've misunderstood something.

(Note, also, that I don't really care about threading.)

Agreed that duplication of everything between a Q&A system and a persistent chat system is NOT what is desired. Both types of communication have their benefits and complement each other. As Mark said, the only type of integration that would be nice between the two would be to be able to preserve a segment of discussion in the persistent chat system as a FAQ in the Q&A system. But, I see that as a nice-to-have feature, not a requirement.

Also, about threading, in all honesty, I seldom use that feature in Slack, currently. However, there are less then 40 people participating in my most heavily used Slack team, with less than 10 people being active contributors. My thought is that with increased participation, threading might become more of a necessity. One of the things that makes active IRC channels difficult to read is the interleaving of messages from different conversations. I would think the same would be true of an active Slack channel without threading.

There is currently a well-attended Slack team for Enterprise MediaWiki developers (enterprisemw.slack.com). It provides an excellent venue for communication and relationship building. There are several Wikimedia Foundation staff who participate in the Slack team, but there would be broader Foundation participation if FOSS software were used. -> there would be broader Foundation participation if it wasn't an invite-only channel that you can only learn about by accident. Not to denigrate the idea of a FOSS chat forum, but it's far from the biggest barrier limiting participation.

Agreed that duplication of everything between a Q&A system and a persistent chat system is NOT what is desired.

Of course, Q&A goes to one place and chat to another, but... why do they need to be in separate websites? You could have them both in Discourse, but not mixed.

Please read the first post at https://meta.discourse.org/t/babble-a-chat-plugin/31753 and check the screenshots. You could have as many different chats as you wish. They could be public or private, being associated either with a public category (that could be hidden from the homepage and silenced to not generate notifications by default) or with a private group.

Having Q&A and the social chat both in one place, using one username, one search engine... I think the advantages are interesting enough to consider this option?

Matrix/Riot has insane amounts of promise. They are basically redesigning IRC for the modern world, in a fully backwards-compatible manner, with everything from presistency to rich text to permissions and state-of-the-art end-to-end group chat encryption to video chat; they are true a community-based FOSS project, and moving fast. I would love to see the Foundation being strategic in act and not just speech for once, and invest into them.

As for using them right now, I'm less sure. They have improved a lot since last I looked at them a few months ago (you don't need the user manual to find out how to join a channel anymore), but the UX is still far from polished.

(Then again it can't be worse than IRC, and currently we are using that for developer support, so...)

Babble looks like a hobby project. That's not necessarily a bad thing but I'm skeptical about it scaling, being secure etc. A standalone, somewhat popular opensource project like Matrix or Mattermost is a much safer bet.

Just an update. In short, @Tgr has convinced me that it is better to bet on Matrix.org for real-time communication. We have this task here, but there are other related discussions in other corners of Wikimedia that could converge in Matrix.org based solutiions at their own pace.

I agree that this is a sound approach and, in comparison, I think that having a good Discourse integration right now plays a secondary role.

Matrix just got a $5M investment and their top priority is improving usability so sounds like an even better bet now.

Awesome news!

If we think it fits what we want to do well enough, I'd suggest just going ahead. At some level it comes down to personal taste and we're never going to all prefer the same solution.

Agreed.

T186061: Evaluate Matrix / Element as the recommended chat system for Wikimedia

In T184606#3932519, @Tgr wrote:

Matrix just got a $5M investment and their top priority is improving usability so sounds like an even better bet now.

Or a worse bet, if it makes them scramble to monetize the product down the road e.g. by making it unfree (à la Transifex).

I've specified one of the requirements with an example of integration i.e. sync with IRC channels (like the teleirc solution which AFAIK Fedora channels use for external communication venues).

Stupid question: was Telegram not mentioned because of the server code?

See also T150732: Provide a group chat system for mentoring and m:Research on open source team communication tools.

In T184606#3933575, @Nemo_bis wrote:

Stupid question: was Telegram not mentioned because of the server code?

If you mean for this task specifically, mostly because it does not have decent IRC integration as far as I know. If you mean more generally, not sure, but yeah I'd guess the proprietary server is the reason.

Or a worse bet, if it makes them scramble to monetize the product down the road e.g. by making it unfree (à la Transifex).

There is categorically no way that Matrix will end up unfree - it's an open protocol, after all. The investment is in New Vector, which is the company currently employing the core Matrix team. The plan for monetising is to provide paid hosting for those who want it (both homeservers and services like bots/bridges/integrations/widgets). We haven't gone this far building Matrix as a libre ecosystem to somehow screw it up at the last minute (i hope!) :)

Several Riot.im rooms have now been set up by the MediaWiki Stakeholders' Group, including a channel that bridges to MediaWiki-General on IRC. The are listed at https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group#Communication.

Task completed or is there anything left to do?

In T184606#3933600, @Tgr wrote:

If you mean for this task specifically, mostly because it does not have decent IRC integration as far as I know.

Which integrations had been considered? Fedora channels have a good integration, as far as I can see, possibly using teleirc.

Seems like zhwiki is using teleirc, would be interesting to know how it works out for them.

@Qgil, the Riot.im rooms are set up and we have some initial participation, but I would like to ensure that some bugs that have been identified are addressed and increase participation before closing this task. I would also like to focus on the "companion to Q&A system" bit in the task title by addressing how the Riot rooms and Discourse could complement each other for a richer solution.

@Marviiin perhaps you could join us at https://riot.im/app/#/room/#mwstake-matrix:matrix.org to discuss some Riot.im questions/potential bugs that we have encountered?

@Johan , thanks for a status update here.

In T184606#4104787, @CCicalese_WMF wrote:

the Riot.im rooms are set up and we have some initial participation, but I would like to ensure that some bugs that have been identified are addressed and increase participation before closing this task. I would also like to focus on the "companion to Q&A system" bit in the task title by addressing how the Riot rooms and Discourse could complement each other for a richer solution.

@CCicalese_WMF: Is there a list of these "some bugs" somewhere? Asking as I'm afraid that without clear criteria this task might remain open forever.

The bugs I was referring to were all fixed. There are still some minor annoyances for people transitioning from slack (e.g. the inability to edit previous messages, no way to "react" to posts, etc.), but the Riot UI has improved considerably. The MediaWiki Stakeholders' Group has now had about a half dozen active rooms on Riot for over a year, and it has proved to be a very effective communication mechanism for the group both in rooms as well as one-on-one chats. There is still room for improvement, but no showstoppers.

The engineering community manager of Mozilla (who are looking for an IRC replacement) posted their set of requirement, which seem well thought out:

• We are not rolling our own. Whether we host it ourselves or pay for a service, we’re getting something off the shelf that best meets our needs.
• It needs to be accessible to the greater Mozilla community.
• We are evaluating products, not protocols.
• We aren’t picking an outlier; whatever stack we choose needs to be a modern, proven service that seems to have a solid provenance and a good life ahead of it. We’re not moving from one idiosyncratic outlier stack to another idiosyncratic outlier stack.
• While we’re investigating options for semi-anonymous or pseudonymous connections, we will require authentication, because:
• The Mozilla Community Participation Guidelines will apply, and they’ll be enforced.
• Must offer a solid mobile experience.
• Must support thousands of simultaneous users across the service.
• Must support easy sharing of hyperlinks and graphics as well as text.
• Must have persistent scrollback. Users reconnecting to a channel or joining the channel for the first time must be able to read up to acquire context of the current conversation in the backscroll.
• Programmatic access is a hard requirement. The service must support a mature, reasonably stable and feature-rich API.
• As mentioned, people participating via accessible technologies including screen readers or high-contrast display modes must be able to participate as first-class citizens of the service and the project.
• New users must be able to join the service without manual intervention from a Mozilla employee.
• Whether or not we are self-hosting, the service must allow Mozilla to specify a data retention and security policy that meets our institutional standards.
• The service must have a customizable first-contact experience to inform new participants about Mozilla’s CPG and privacy notice.
• The service must have effective administrative tooling including user and channel management, alerting and banning.
• The service must support delegated authentication.
• The service must pass an evaluation by our legal, trust and security teams. This is obviously also non-negotiable.

Platform Engineering (and maybe @Tgr?): Does this task have some value on its own and a "driver", or is this de-facto a duplicate of T186061: Evaluate Matrix / Element as the recommended chat system for Wikimedia?

Adding CPT to get a reply to last comment

Conceptually it makes sense to have an umbrella task for evaluating various chat clients. Personally I don't have the bandwidth to work on anything other than Matrix, though. I know some evaluation happened (Zulip, to a lesser extent Mattermost; also AIUI WMDE did their own evaluation) so maybe the relevant information could be collected here.

Thanks for the quick answer! For Zulip and Mattermost we had T154001: Do a research on the communication tools Zulip and Mattermost, and document the pros and cons of using them.