Page MenuHomePhabricator

Evaluate and set up a test instance of FOSS persistent chat software as a companion to Q&A system for communication with third-party developers
Open, MediumPublic

Description

What is the problem?

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 are limitations to IRC that prevent enthusiastic adoption by some of the third-party community.

Note that this task can be thought of as a companion to T181377: Set up test instances for popular Q&A software. Q&A and persistent chat software serve complementary purposes.

How does success of this task look like? How do we know when we are done?

Success would be identifying appropriate software and standing up and advertising an instance of it.

Software Requirements:

  • real time, unstructured, online interactions
  • FOSS
  • persistence (logging of conversation history)
  • search of past conversations
  • ability to create multiple channels
  • threaded conversations
  • user mentions with notifications
  • visually appealing user interface
  • web client and preferably mobile clients
  • visual indication of agreement/disagreement (reactions/emoji)
  • bonus for any level of integration with the Q&A platforms (e.g. sync with an IRC channel)

Is there any goal, program, project, team related with this request?

Q3 Technology Goals, Program 4, Outcome 3, Objective 1

What is your expected timeline from start to end? Is there a hard deadline?

Anticipated task completion is the end of Q4.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

https://discourse-mediawiki.wmflabs.org

Personally, I'm a big fan of solutions that are searchable (and indexable!) without joining, persistent for the group in memory (unlike say IRC), and organized by topic or a folksonomy (user generated tags).

Qgil added a subscriber: Qgil.Jan 12 2018, 11:05 AM

It would be great if MediaWiki third party developers would find their home with the rest of MediaWiki developers. As @CKoerner_WMF explains, there is a pilot that we have just released this week at https://discourse-mediawiki.wmflabs.org. You can learn more about this project at https://www.mediawiki.org/wiki/Discourse.

Let's talk about features.

Discourse supports user groups and private messages to groups out of the box. An array of configurable notifications are available that will let you know when you have new posts via the web UI, browser notification or email notification. I *think* this feature includes automatic browser refresh when new messages arrive, so you see them if you happen to have the tab open (this is the behavior with regular posts, I just haven't tested in private group messages -- it's easy to test).

I would recommend you to try this first, and see whether if fits your needs or not, and if not what features you are missing. We can start this test right away at https://discourse-mediawiki.wmflabs.org, just ask.

If this is not enough, then there is at least one chat plugin for Discourse that you could try, Babble . There is a demo site at https://discourse-babble.com/. If you try that plugin and it serves you well, we could discuss its installation in our Discourse instance.

If none of this works... there would be still another way to have a bridge between this Discourse instance and whatever service you choose, see Discourse's official Chatroom Integration plugin.

Also, no matter what, there has been some prior research that it might be useful to consider to solve this problem, even if it was done before Discourse landed in our toolbox:

I know, it's a jungle out there. 😆 I hope to have helped a bit at least being aware of explored possibilities.

So I assume what we're looking for is a "venue for communication and relationship building", as @CCicalese_WMF wrote in the task description, and one of the important aspects of IRC and Slack is the social function they have in connecting folks to foster community, which both helps people to work together and to keep wanting to come back. I assume this is important in this case too?

Yes, exactly: the key aspect of this requested capability would be that "venue for communication and relationship building". I see this as a necessary companion to Q&A software. Both pieces are an integral part of a complete solution. Typically with a Q&A system, people visit, get what they want, and leave. Discourse is definitely designed to build a community around the questions and answers, but that it not the same as having a place for people to visit, chat, and discover tangential connections that can result in unanticipated opportunities. It is the structured nature of Q&A that helps people quickly zero in on a solution to a particular problem. It is the unstructured nature of chat that allows creativity to blossom and long term bonds to be forged. Both are necessary. An ideal solution to this task would definitely integrate with and extend Discourse (or, in the small chance that Discourse does not end up being the Q&A system of choice, whatever Q&A system is deployed as a production solution).

Making sure we don't reinvent the wheel:

@srishakatux did some evaluation of Zulip, which is open source, a while ago – see T170356. I don't know how well it fits the listed requirements. Srishti, could you comment?

@yuvipanda looked into Mattermost a while back. Comment here: T162960#3188321

Johan added a comment.Jan 12 2018, 2:31 PM

Another option would be RocketChat but like RiotIM, it currently lacks threading. I'm running RocketChat for non-Wikimedia reasons and am fairly happy with it, but given that that's a server for nine persons on a Raspberry Pi in my kitchen I'm not sure how well that evaluation scales for our purposes.

sr229 added a subscriber: sr229.EditedJan 12 2018, 2:38 PM

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.

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/

Qgil added a comment.Jan 12 2018, 10:21 PM

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.

greg added a subscriber: greg.Jan 16 2018, 5:12 PM
Tgr added a subscriber: Tgr.Jan 20 2018, 3:16 AM

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.

Qgil added a comment.Jan 20 2018, 10:17 PM

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?

Tgr added a comment.Jan 21 2018, 3:56 AM

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.

Qgil added a comment.Jan 26 2018, 2:44 PM

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.

Tgr added a comment.Jan 30 2018, 9:42 PM

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

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.

Nemo_bis updated the task description. (Show Details)Jan 31 2018, 7:50 AM

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?

Tgr added a comment.Jan 31 2018, 8:42 AM

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

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!) :)

jrbs added a subscriber: jrbs.Feb 1 2018, 6:36 PM
Johan raised the priority of this task from Medium to Needs Triage.Feb 19 2018, 2:04 PM

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.

Qgil added a comment.Apr 4 2018, 12:42 PM

Task completed or is there anything left to do?

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.

Tgr added a comment.Apr 4 2018, 2:28 PM

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.

CCicalese_WMF triaged this task as Medium priority.Apr 4 2018, 2:35 PM

@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 removed Johan as the assignee of this task.Jul 18 2018, 8:44 AM
Johan removed a project: User-Johan.

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.

Tgr added a comment.May 5 2019, 9:01 AM

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.

Core Platform Team (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 / Riot.im?

Tgr added a comment.Aug 23 2019, 10:39 AM

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.