Alternatives to IRC

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.

1 Like

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.

1 Like

Forget Slack!
I just looked at Gitter and it seems to be much better suited for what we as a community want than Slack:

  • is simple to use: TTW and apps https://gitter.im/apps
  • open for everyone: needs just a github account - public room at https://gitter.im/plone/public
  • [?] it accepted by the circle of people giving advices.
  • archived
  • scales up to many users
  • no need to host by ourselves

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

2 Likes

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/

1 Like

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. :smiley:

@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:

    • IRC has always split the community (into (old-school) techies and non-techies), and somehow this never used to be an objection to its use.
    • I've had more discussions with Plone devs via Skype than via IRC, because working closely with someone to figure something out or to get some work done is a non-starter in a shared IRC channel, and even Skype chat is 100% better than plain IRC.
      • I've always felt such Skype chats is a regrettable memory hole, as I've felt the lost histories of sprints strewn across untracked etherpads, hangouts, unlogged IRC, etc is a pity. Slack is a massive upgrade to the chat experience, and the conversation archive remains available, so I was excited to introduce it.
    • It's a concern where to send newbies for "live" support:
      • Sending them to IRC has always been a terrible solution.
      • Merely having a Slack team doesn't imply that we have to start sending newbies there.
      • Sending newbies straight to the community live chat for support is not something that mature organizations do, in this day and age. That is why companies like Zendesk, UserVoice, and intercom.io exist. They make it possible to craft the support/onboarding channel for newbies. Whether that ends up in a gitter room or a Slack channel is a different part of the discussion, and should not be the determining factor in choosing a channel for community discussion.
      • Somehow it's fine to pick communication channels like gitter, Google docs, hangouts, Skype, etc without community consultation, but this particular Slack team needs to be closed. It's not a problem for discussion to happen in all these opaque places in addition to the public IRC chat, but somehow it's a problem if discussions happen in one additional Slack team (open signups, archive available).
  • 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 MatthewWilkes bchhun: 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 PM SteveM MatthewWilkes: 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

1 Like

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. :confused:

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!