I think you said: "Stop talking about which tool is better, and just continue talking on IRC, it's good enough."
I responded: "Yes, stop talking about which tool is better, continue talking, on IRC, and on Hangouts and on Skype, etc. (as we already do) and on Slack."
Is that a fair paraphrase?
Thinking a bit further ahead, let's say for argument's sake we agree to move forward with a new chat platform. At what point do we change our Plone.org/support page (and everything else) that points people to IRC as the real time channel for help and community? It seems to me we would ideally agree wholeheartedly on one particular such platform then move everyone as quickly as possible to it so that people looking for real time chat (and help) can find an actively used platform. That is why there is concern about adding "just one more" platform to the mix; this one is strategic from a community wide perspective. It isn't just about small teams who are always free to do whatever they wish without effect on the wider community.
Here's slackin deployed on the free tier at Heroku, sending invites to sprinting.slack.com , another team I was toying with earlier: http://sprinting-slack-signup.herokuapp.com/
It's on the free tier, so: Sleeps after 30 mins of inactivity; Must sleep 6 hours in a 24 hour period. If it's sleeping, it takes ~10 seconds to wake up.
@tkimnguyen you can generate a token for the Plone team at Using the Slack Web API | Slack
Yes, but I don't think we need to do it pre-emptively. Maybe let people try out the slack channel for a while before revisiting putting it on the support page?
One disadvantage of IRC is that when people ask a question but don't stay connected (and you don't know their email address) it's not possible to respond to their question. This is frustrating for those who want to help and, of course, for the ones seeking help. It makes Plone seem less "professional". We should maybe think of a way to ask newbies to stay connected long enough to get an answer or point them to irccloud.com or similar service.
Yes, indeed. There's a Slack add-on that looks like it can be used provide to functionality similar to intercom.io: https://improvi.github.io/slack-chat/
By the way, I've imported the Plone Slack chat to a Plomino instance. It's not the prettiest, but I think it demonstrates that a public searchable archive is eminently practical. At the moment I'm setting up a Heroku Plone instance to demo the archive.
If you need async communication asking at community.plone.org is a good idea.
Forget Slack!
I just looked at Gitter and it seems to be much better suited for what we as a community want than Slack:
and it has an API https://developer.gitter.im/docs/welcome
and https://sidecar.gitter.im/ would be perfectly simple integration for the new plone.org
try it,
FYI
Also see: http://blog.gitter.im/2014/05/12/open-source-communication-with-gitter/
Btw it natively supports IRC, which enables Your Favorite Client Even On Mobile and also our existing bots infrastructure: https://irc.gitter.im/
Proof-of-concept import of Slack export archive is now at http://pacific-inlet-6447.herokuapp.com/Plone/demo-slack-import, please have a look.
Slack checks all the boxes you mentioned, except the one with the [?] (where it also has a [?]).
So is Slack, but doesn't need a github account -- needs only an email address.
Please see http://pacific-inlet-6447.herokuapp.com/Plone/demo-slack-import/ for a quick hack, which can easily be improved.
Slack scales, the relevant scaling issue is human: Dunbar's number - Wikipedia
Huge teams communicate less effectively. The "scaling" issue that is repeatedly brought up with Slack is the number of people that can be signed up to a single team, which apparently becomes problematic around 5000. The strength of Slack is to make teams who work closely together more effective, e.g. Plone core devs, the participants of a sprint, conference attendees, Plomino devs, TTW enthusiasts, ZODB tuning/replication gurus, etc.
I know programmers know only three numbers (0, 1 and infinity), but a conversation doesn't have to accommodate infinite participants to be worthwhile. It can't. Discounting a chat tool because it doesn't allow infinite signups to a single team is not realistic.
Slack isn't the right tool for all kinds of communication, but it doesn't have to be, for it to be very useful.
Slack natively supports IRC and XMPP, I've enabled both gateways for the sprinting team, which you can sign up for at http://sprinting-slack-signup.herokuapp.com/ -- once you're in, visit Slack to find your connection details.
Note that "natively supports" is a bit of a red herring -- IRC vs Slack vs Gitter is apples to oranges to bananas. They have different affordances and strengths (and weaknesses).
There's also https://ekmartin.com/2015/slack-irc/ for a different style of integration, more loosely coupled.
Well, lets see whats get accepted and used, its both a trial at the moment. For me personally gitter won, because its overall easier to use and feels to me more open.
Absolutely. 
@tkimnguyen in the interest of getting used, could signups to http://slack.plone.com be opened up please? (I.e. could we get a token from Using the Slack Web API | Slack for slackin?)
Also, could the IRC/XMPP gateways be enabled, for those who would like to use it with their existing clients?
This is using currently using double the storage allowed by the Heroku free tier (22,000 rows, vs 10,000 allowed), so I'll take it down soon. I may replace it with a static HTML version.
(The storage usage fits with the Heroku buildpack docs, which say "the 10k limit is reached after creating about 200 content items" --- the archive is a bit over 500 messages, and this version of Plomino still represents messages as Archetypes content. The next version of Plomino uses storage more efficiently.)
I've got to say that it looks to me as if this decision is very close to made.
Jean has made some excellent points, and Slack is clearly a good tool. But from what I'm seeing of the discussion, Gitter has clearly got most of the energy.
So, let me ask: are there any show stoppers for Gitter? I'm nervous about being so tightly tied to github that it isn't possible to be part of the community without a github account. But I admit that the ease of use of gitter via github account is a positive.
I don't see how you can reach this conclusion so quickly. It seems to me it's being made on the basis of one day of vigorous discussion that happened to take place on gitter, that might as well have taken place on Slack, had it been open for signup.
What decision is being made? To close off signups to one particular Slack team, for murky reasons? The only standing objection I see is that having a Slack team would somehow split the community. My responses to this are that:
Both Slack and gitter bridge to IRC, Slack also bridges to XMPP. With a tool like https://ekmartin.com/2015/slack-irc/ a Slack channel can be bridged to a gitter room and/or freenode channel, if it's really a concern to address everyone at once.
In IRC you state:
10:35 PM
MatthewWilkesbchhun: I don't see the advantage, myself. Sure, it's got a pretty UI, but is that worth walling ourselves up in a commercial service?
10:37 PMSteveMMatthewWilkes: You’ve hit on the most troubling aspect of this.
This goes for gitter as well as Slack, I believe, and certainly it's something to be wary of. I think our conversations have always been more walled-up in IRC than in Slack, because in IRC (if it's logged) we have the good old Unix soup of strings, while in Slack every message is rich JSON. But this is a choice we often make: using github, OS X, iOS, Android, AWS --- we weigh the costs and benefits. As a project, we don't want to spend effort on running servers, but we need version control, chat, mail servers, so we use github, gitter/Slack, mailchimp. We know the trade-offs and make sure to avoid lock-in. We're quite capable of doing this.
I don't think there are show-stoppers for gitter, it's just not as good as Slack, and I can't see the point of taking a stand against a very finely crafted tool, that's very open to different clients/integrations/export. Based on all the examples I name above, I don't see that being able to chat in Slack in addition makes anything worse; but there are many upsides, as you acknowledge. People who like Slack and who look for the Plone Slack team, will logically look for plone.slack.com first.
When I look at the gitter room, I see the same wall of undifferentiated text as the IRC channel. Comfortable and familiar to IRC users, but missing all the opportunities for improvement that Slack brings. Obviously I don't expect anyone to take my word for this --- people should make up their own minds ... by using the tool.
I believe I'm done with this discussion now.
As other people gain experience with Slack, and contrast it with IRC/Gitter's papercuts, please weigh in and ask for signups to be opened.
How do you work out that the decsion is close to being made?? I see only a
few voices and no length of trials. I would say that since the choice isnt
obvious then we should wait. Otherwise pick the most popular which is
slack. Picking the underdog is what we normally do and it always bites us
badly.
My suggestion that the decision is "close to being made" was really an attempt to drive towards a decision and was based on the balance of opinions I'd seen here and in the various chats.
I certainly agree with the criticisms of IRC. If our goal is to be open to newbies, I think we're failing with IRC. It's a distributed, open system, but also one that seems to pose great problems for new folks -- whose experience of the Internet is the web or apps. Registering a nick and password is (IMHO) a much bigger barrier to discussion than we see with either gitter or slack (that is, slack with an auto invite mechanism).
Slack is great. Some of our teams are already using it for private conversation, and with great results. I don't see anyone knocking slack of suggesting we forbid its use. I see people concerned that slack is not really intended to be an open-community discussion mechanism, and that you have to employ unsupported hacks (no team.invite function in the api).
Gitter, perhaps not as great. Except that its connection to github makes it a nearly immediately useful community discussion tool with no hacks. Yes, you need a github account. But even with an auto-invite mechanism, slack is requiring a slack account. I think there's more total friction for newbies with slack.
The docs, framework, security and board teams may use whatever tool works best for them. But for a discussion mechanism that we can list on our support page, we need the lowest possible "join and use" friction.
Steve
I thought that slack would be an instant hit, and I'm a bit sad that it hasn't taken as naturally as I assumed it would. I adopted it quite recently, and my reasons for ignoring it all along have been mentioned multiple times above (primarily this "feeling of not-openness").
I've got over it, and the pros totally obliterate the cons so far.
I was also really surprised at how relieved some non-developer people are, to be free of IRC. 
I understand that the Plone peeps are super-cautious, and that there must be one clear winner in the chat-system-showdown before anything can really change. I just hope that if Slack loses the popularity contest, it does so to a worthy apponent!