I see on https://meta.wikimedia.org/wiki/Discourse#Mattermost that there was a MatterMost on http://mattermost.wmflabs.org/ , but it 502 Gateway error now.

but it doesnt even have integrations with other Phabricator components. It is suitable for adhoc discussions, but is not designed for a team 'room'.

Can you please file tasks about these issues in either our tracker or ultimately the upstream tracker?

https://xkcd.com/927/ covers any potential reluctance I feel. :)
I'm missing a better definition of the problem to solve in this task.

What exactly makes "a team room" a team room?
Why is IRC not a mobile friendly tool (I have an IRC client on my mobile phone)?
What does "not ideal for adhoc but timely mentoring" actually mean?
Which exact issues (and links to bug reports about them) make you avoid (or even block you from) using Conpherence?

https://meta.wikimedia.org/wiki/User:GWicke/Matrix.org is what I'm using now :)

in general I also find that in our community a lot of people have a very strong emotional attachment to IRC, and talking about replacements gets really charged pretty quickly. I hope that doesn't happen here.

Only thing I want to respond to is @Aklapper's

Why is IRC not a mobile friendly tool (I have an IRC client on my mobile phone)?

IRC is a stateful connection oriented protocol - so you have to have an open connection to the server at all times. And multiple devices have no inherent (as in, pure IRC) way of maintaining state between each other. So you have the following options:

1. Have IRC only on your PC
2. Have IRC only on your mobile phone
3. Learn how Linux works, get a VPS somewhere, setup a bouncer (or weechat or equivalent), then connect multiple clients to this (this still doesn't easily sync read status across)
4. Learn how Linux works, get a VPS somewhere, install screen/tmux + weechat/irssi on it, then ssh into this text mode interface from multiple clients.
5. Pay IRCCloud 5$ a month (or keep getting disconnected every few hours)

3/4 are easy if you already have the necessary skills, but otherwise limits people who can participate fully to only those who have the necessary linuxing skills.

I do understand that IRC isn't going to go away anytime soon, which is why I've been using (and recommending) the bridging approach taken by the opensource openprotocol oriented matrix.org. https://meta.wikimedia.org/wiki/User:GWicke/Matrix.org. It fixes a a large amount of the IRC protocol issues in a modern, intermittently-connected multi-device world while keeping the good bits of it (reasonably simple protocol, fully open, federated). It also has a nice web client, with weechat support for people who prefer text mode clients. The bridging also means people who want to can continue using IRC without that being a bottleneck for others' UX.

I am not advocating that IRC should be replaced. It is great for many purposes (I said that in the opening sentence), especially when lots of custom IRC bots are created as Wikimedia have build over many years.

@Aklapper , it is very hard for me to take your questions seriously. It sounds like you haven't used Slack or alternatives as part of a development project. It is rapidly becoming the norm. Forcing the use of IRC for day to day communications of a mentored project puts a unnecessary burden on mentor and student.
Unless WMF mandates the communication channels to be used, or provides a good alternative, Outreachy/GSOC project mentoring will move to other non-Wikimedia hosted/approved solutions.

Regarding Conpherence vs Slack / alternatives, the amount of features missing is extremely large. It would literally take me literally a month to raise bugs for the missing features. Some of the most obvious ones are at https://secure.phabricator.com/project/view/608/ .
The serious mobile problems wouldnt be as difficult to raise bugs about, but that is because the feature set of Conpherence is still quite small. Add more features and the existing design doesnt work; which is why most tools of this kind offer an app which has a very different layout. Every time I use Conpherence on mobile (and I endured it for a very active GSOC project), I hit significant roadblocks. Also, I do find it painful to raise bugs about Phabricator; the OSS developers in that project are among the rudest I have ever encountered. https://secure.phabricator.com/T11764 ; https://secure.phabricator.com/T3025 / https://secure.phabricator.com/T11260 / https://secure.phabricator.com/T11141 ; https://secure.phabricator.com/T5375 ; https://secure.phabricator.com/T6051 / https://secure.phabricator.com/T10073 ; https://secure.phabricator.com/T10791 ; https://secure.phabricator.com/T5181 . (It probably doesnt help that I usually need to use Phacility's instance of Phabricator on mobile when I am trying to raise the bug experienced on Wikimedia Phabricator on mobile.)

In T150732#2796188, @yuvipanda wrote:

https://meta.wikimedia.org/wiki/User:GWicke/Matrix.org is what I'm using now :)

Trying this out now. It is a overly complex process to set up, but I managed to connect OK. It is way behind Zulip in many ways, but at least it solves some of the problems with IRC on low bandwidth/connectivity mobile.

PS: this is not an endorsement to any product (I don't have an opinion here), but I just want to note that @sumanah (former Wikimedia Engineering Community Manager, GSoC org admin and more) is these days an Outreachy mentor for Zulip.

Exactly. This would really add to the fact that org-admins can automatically be involved in the progress of every project as well. I really like something wikimedia centric to be there for participants of GSoC/Outreachy programs to communicate. Currently we have individual projects communicating through different communication medium, and in the end, in case of a dispute, the org admins are left with no know-how about the project progress and etc. The mentors we have around is exceptional, but this would be a great addition for them as well, as all the communications are kept public, and at a common place.

Cant wait for this one to shape up!

I am moving this task to Developer-Advocacy (Jan-Mar-2017) because we need to decide something in that timeframe if we want to affect the next GSoC/Outreachy round in any way.

Still, there is nothing stopping this discussion (apart from time available, of course).

Also related: T127904: Have fallback communication channel when freenode has problems

Thank you @jayvdb for initiating this discussion and to others for contributing!

As, an owner of this task now, as a first step, I plan to identify, research and document other open-source team communication and collaboration tools and also document a comparison between Zulip and Mattermost. I've proposed two subtasks for the same for Google Code-in, and I plan to be a mentor for them. I will use this thread, to share the progress and seek your input before jumping onto any conclusion :)

Hopefully, we'll come up with some solution before the beginning of next round of GSOC.

Next steps on this: analyze results from https://meta.wikimedia.org/wiki/Research_on_open_source_team_communication_tools and https://meta.wikimedia.org/wiki/Zulip_vs._Mattermost_comparison, and set up an instance of the most useful tool with help from Labs.

We need a decision about this ASAP, so mentors and interns can start creating their project channels accordingly as soon as the GSoC and Outreachy results are announced.

Yes! The idea here is that when we know who are the final mentors for GSOC/Outreachy, in a week or so from now, we will reach out to them and ask them to pick a tool of their choice or from the list: https://meta.wikimedia.org/wiki/Research_on_open_source_team_communication_tools. If the tool needs to be hosted on Labs, we'll create Phabricator tickets for the same.

I have a suggestion: How about having all mandatory weekly meetings in somewhere public like #wikimedia-devrel ? I think this would improve on the quality of the communications too (from what I would hear from past mentors).

Update: With help from Sumana and her team, we now have a SaaS version of Zulip setup here: https://wikimedia.zulipchat.com/. I've informed GSOC/Outreachy mentors about the same in our group chat, expressed my desire of sticking to one medium and explore Zulip more for a reason, but also mentioned they are free to pick other tool and let me know about it soon, so that I can do a setup for them before the announcement of final results.

@01tonythomas Thanks for your suggestion! I will definitely take this into consideration.

My personal impression, after spending a fair amount of time with people writing microtask in the last month:

• any system that fragments the mentor/helper community is not going to work well. I am not always around (in fact I am not around most of the time) so they can get faster answers from someone who is not a mentor (and most questions are very basic); sometimes I'm not even the best person to ask. IRC is what's overwhelmingly used to get quick answers and there are dozens if not hundreds of volunteers already providing advice there (many of them with workflows that are not easily migrated to other systems, even if they were insterested in moving - notification bots, personal highlight scripts etc). Anything that's not interoperable with IRC is just going to be another extra tool to learn.
• Conpherence is somewhat of an exception because you sort of have to learn it anyway (well, Phabricator; but if you can already use Phabricator, there is not much else to learn to be able to use Conpherence). Plus it's integrated and can handle task number, file uploads etc and supports private rooms. Unfortunately it is not very good: there are no notifications (even after T765 gets fixed, notifications would rely on my work browser being open), no way to invite someone to a chat, no way to get notified on keywords, no search, poor @ usability... I am using it now as the least broken of the available alternatives but it's not great.
• IRC is of course very hard to use for newbies; enough has been said about that already.

So my ¢2 is that the only realistic way forward is something that is fully interoperable with IRC but has decent notification / rich content characteristics. AIUI there are two such options, Mattermost and Matrix.

StackOverflow's writeup about their mentorship research (based on their homegrown chat system) has some interesting (although not really actionable) insights.

IRC is of course very hard to use for newbies; enough has been said about that already.

In response that this, I used to agree but don't anymore. If you are installing IRC on your own computer, reserving a nickname, and trying to set up a bouncer (and all of the rest of the crazy stuff you need to do) it is quite challenging.

However if you are using a web client you can log into specific channels in seconds and it works easily just like any other chat program. We had a link set up for people to do this on the Vienna hackathon wiki-page and it seemed to work without complaint. https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2017/Participants#Step_2:_Connect_.26_Setup

Maybe we can encourage people to use web clients until they get to one of our events and then we can have a few volunteers who can help people install and set up IRC for good on their laptops. Some WMF folks helped me get everything set up back in 2011 and although I might not be able to recreate it all - its still working.

I think we should use IRC and I think we should just start a campaign to remove its negative reputation in our non-technical community because there are work-arounds.

Just my two cents, Im open to trying things (like Telegram at hackathons) but I don't want to fragment our technical community event more and as @Tgr says many people are already happily using IRC and many of those people wont be willing to move their work elsewhere.

Also - one other final comment.
In the Mozilla Open Leadership program that I am taking part in I am needing to get on different tools I have not used before. GitHub and Gitter (chat program) for example.
I think another way to frame this is to say that getting on IRC and getting familiar with it with the help of your mentors and program leads is actually a net-positive instead of net-negative.
If you want to be a developer in the open source community you probably should know how to use IRC... and we at WMF are offering training and support to get people going.
So just a bit of different framing could help. Don't say "we know it sucks and its going to be hard, but please use IRC because thats how we do things." Say "IRC Is a big part of open source developer culture, we can help you work through the set-up process"

In T150732#3673332, @Rfarrand wrote:

However if you are using a web client you can log into specific channels in seconds and it works easily just like any other chat program.

It's easy to do, it just won't be very useful.

Some years ago I added a bunch of IRC buttons to various hu.wikipeda pages (help, village pump etc) - one click and you were logged in to the huwiki channel with your wiki username. Many nontechical editors used it without a problem and as long as there was coordination to have everyone at the same time there it worked quite well - we had large IRC consultations and whatnot. It broke down quickly when it had to be used in not-quite-real-time.

There are a couple features which can be set up for IRC but not easily, which are important to providing a support channel: being online 24/7 (so you can see late replies), alert on pings (ideally converted to an email or mobile notification or something similar if you are not otherwise reachable), being able to connect nicks to wiki/Phab users (both ways). There is no reason a good web client (with some kind of server component) couldn't do these, I just haven't seen one that could. (Matrix does the first two, but the UI is still beta level.)

Although now that I'm looking around a bit KiwiIRC doesn't look bad. It's opensource (so it can be self-hosted if we want to), has notifications, i18n (not a huge range of languages though), an okay UI, and can work with bouncers. Probably worth a closer look.

@Tgr We have a beta version of Zulip which lives here https://wikimedia.zulipchat.com/, and currently, the registration is by invitation only.

We used Zulip during the GSoC’17/ Outreachy Round 14 with a goal of helping students and mentors be in close communication with each other. So based on the lessons learned in T170356: Evaluation of Zulip as a mentoring tool for Wikimedia outreach programs , one thing that I would be interested in doing different would be to:
introduce Zulip when the application period opens to interested students and mentors, like how Sage Ross does for WikiEd, add interested candidates on Slack.

For the current round of Outreachy, the plan is to introduce Zulip to mentors and students after the results are announced, as we are almost there. IMO, before we have many users on the platform who could help reach a conclusion and convince that we should continue to use the tool, we don't do any technology integration at this point.

I can send you an invite now to join the platform so that you could look into it.

Agree that Conpherence is buggy and that's why I like that Zulip allows us to have organized conversations in a threaded style that Phabricator couldn’t support. Also, group chats, private messages, etc.

Agree that IRC is hard for newbies but should be encouraged, still what a group communication tool like Slack, Zulip could offer, IRC couldn’t. IMO, even though we adopt a group communication tool, we still emphasize what students can leverage IRC for.

As Wikimedia's Zulip instance lives here https://wikimedia.zulipchat.com/ and we are going to continue to use it the next rounds of GSoC / Outreachy as discussed in Developer Relations meeting recently, I am closing this task for now. We will reopen this task when the need arises.

If anyone likes to use the tool, contact me, and I will send you an invitation to join the platform.