Problem/Motivation
At core conversation session by @kgoel at DrupalCon LA , 2015 on "Pain points of learning and contributing in the Drupal community" , several people mentioned that they don't like IRC and they don't get on IRC.
During core mentoring at PHPWorld and people from other Open Source community said that they don't use IRC and its 1990's chat client which is way too old to use in the Drupal community and why Drupal still lives on IRC.
Problems with chat, regardless of technology used
- Too much overhead to add new channels for ongoing projects.
- Many channels don’t have ownership or moderation
- No integration with our projects. Channels are made independently from the project
- Cognitive load each time you return to a channel to see what's changed
- Chat isn't necessarily the most effective way of communicating (versus issue queues, audio/video or face to face)
- It risks being a significant time sink / distraction
- Drupal is a global project and some contributors will always be in a difficult timezone compared to others
- People's ability to participate in chat is affected by whether English is their first language
Concerns people have voiced about IRC
- There is no scroll back/history/asynchronous conversation native to the platform (requires a proxy such as bip or znc or using a 3rd party service like IRCCloud). Issue applies to channels and private conversations.
- Few high quality apps, especially for mobile devices (IRCCloud app is not entirely free)
- The lack of a “user is typing” indicator slows down conversations (counter-argument: indicators not always reliable, may become a distraction / put people off writing a reply of their own)
- Many contributors haven't used irc before, and new tools can be a struggle for even technical users (counter-argument: IRC webapps make IRC easier to use, but it is still more of a challenge than modern alternatives.)
- Although possible, it is difficult to create hooks into third party services.
- Usage is dropping on IT circles for maybe a decade now (IRC protocol is on decline)
- Doesn't do voice, video calls or conferences
- Lack of modernization for sharing files (Services like Dropbox, Google Drive are not preferable because it fragments the community and if any of these services die, the files are gone forever. The files are not either instantaneously available in the client)
- Can't show media, like photos, maps, etc. (Support of media is dependent on IRC client)
- Can't share stuff permanently. (ie, can't host shared media forever)
- Doesn't support login by email address or phone or external credentials
- Can't login from multiple clients and share username without magic like nickname aliases
Proposed resolution
Requirements for chat system:
- Open source
- Backscroll/offline History
- User typing indicator
- RTC (audio/video)
- Bot integration
- Mobile support
- Future integration with d.o/projects
Possible solutions:
1. Create/switch to Matrix
Matrix is an open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers.
- Pros
- Open standard/API
- WebRTC compliant/superset
- Various ways to connect or integrate
- Has all the current "features" of IRC + more
- Integrates with existing IRC servers + channels to facilitate migration or keep usability parity (i.e. support stubborn people who still want to only use IRC).
- Standardizes user identifiers/authentication (e.g. @username:drupal.org) which would allow for easier discoverability and the ability to initiate chats with other users.
- Allows for future d.o integration (i.e. web based RTC) and possible per project/issue chat "rooms"
- No need for "user creation" as this could be tied directly into simply using their current d.o account/authentication.
- Read their FAQ for more info.
- Cons
- Not "IRC"
- Newer technology?
- Requires a little bit of setup to create our own "homeserver", but this is rather trivial and well documented. A "homeserver" really only helps to facilitate the storage of data, provide authentication and RTC discoverability; most of which is automatically handled. It's really just a matter of setting up the proper config.
2. Keep existing IRC
- Pros
- We currently use it
- Open standard/protocol
- Multiple GUI applications
- Many other FOSS projects use IRC, so contributors to those projects can easily join the Drupal channels
- Optional user creation, no register user required for use
- Cons
- Old - lacks modern features needed
- No API/automated integration (bots must be manually constructed and hosted somewhere)
- No history/offline history built-in
- GUI applications - inconsistent implementations (i.e. what "features" are provided)
- Optional user creation, required if you want to keep a "consistent" user identifier
3. Do #1 and #2.
Other solutions mentioned - Free/paid services:
- Matrix.org is another Open Source chat service, locally hosted slack clone / free SASS. Currently has dozens of FOSS servers, clients (most popular client is Riot.im) and integrations, including IRC, GitHub, and much more!
- Gitter.im Github/Gitlab integration makes this a place for FOSS chat. Has been bought by GitLab and will turn FOSS during summer, to allow people to use it as a locally hosted slack clone. Free service.
Slack.com, SAAS. Meets most of the features requirements listed, but does not meet goals related to FOSS/privacy philosophy. May require paid service.Hipchat.com, SASS. It meets most of the features requirements listed. 3rd party integration, but does not meet goals related to FOSS/privacy philosophy. May require paid service.- Telegram.me is a WhatsApp clone, with Open Source clients and a proprietary server. Supports channels, groups and private conversations and has many bridges/bots, including for IRC. Since recently, also supports voice calls. Still, it's less feature full than the others. Completely free service.
Other solutions mentioned - Self hosted software:
- Matrix.org is another Open Source chat service, locally hosted slack clone / free SASS. Currently has dozens of FOSS servers, clients (most popular client is Riot.im) and integrations, including IRC, GitHub, and much more!
- Rocket.Chat is another chat service, locally hosted slack clone, the most popular of the FOSS kind for big companies and organizations.
- Mattermost is another Open Source chat service, locally hosted slack clone.
- Gitter.im Github/Gitlab integration makes this a place for FOSS chat. Has been bought by GitLab and will turn FOSS during summer, to allow people to use it as a locally hosted slack clone.
- Zulip is another Open Source chat service, locally hosted slack clone.
- Lets chat, F/OSS. Node+Mongo, meets many of the requirements listed, but not as integrated or used as slack. Also needs to be hosted locally.
Other solutions mentioned - IRC magic:
- Waartaa is an open-source solution with a responsive web interface based on the MeteorJS library for browser-to-server communication and syncing. It connects to IRC on the back-end, giving users the choice of using the web interface or a traditional IRC client
- Convos works on top of IRC. F/OSS, has backlog, desktop notifications, content previews.
- IRCCloud Has a desktop, android and ios app, has all the features above and there are several people using it already.
The why and why not Slack.com
- Pros
- Some developers already have Slack app running
- Has many of the above requirements
- @todo
- Cons
- Closed source/proprietary
- In it for the money: https://slack.com/pricing
- "Free" plan is intended for small to medium sized business/teams (Drupal is anything but)
- Requires users to register
- Architecturally has several types of limitations since their service is based on "small to medium" sized teams: https://medium.freecodecamp.com/so-yeah-we-tried-slack-and-we-deeply-reg...
- Prohibitively expensive to get backsroll
- Does not have all of the above requirements
- Does not and will not support Open Source Communities
- Allows users to easily impersonate other users on d.o [comment#233]
- @todo
Remaining tasks
- Evaluate Riot.im EULA & Privacy Policy as possible matirx service provider.
- Get DA to evaluate Riot.im.
- Have users use example riot/matrix IRC bridge
- https://riot.im/app/#/room/#freenode_#drupal:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-contribute:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-support:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-infrastructure:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-commerce:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-media:matrix.org
- https://riot.im/app/#/room/#freenode_#drupaldevdays:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-belgium:matrix.org
- https://riot.im/app/#/room/#freenode_#drupalcampbe:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-portugal:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-nl:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-search:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-vm:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-drupalorg:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-aegir:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-migrate:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-in:matrix.org
- https://riot.im/app/#/room/#freenode_#drupal-console:matrix.org <-- Gitter bridge
- Finish Slack bridging with riot
- If Riot is not a long term option, create a strategy for implementing matrix in house.
Poll / survey kindly created by @pwaterz:
https://www.surveymonkey.com/r/XKZPYBC
See results at:
https://www.surveymonkey.com/results/SM-6R9V6KKK8/
Comment | File | Size | Author |
---|---|---|---|
#340 | Screen Shot 2017-09-01 at 2.38.02 PM.png | 80.3 KB | frob |
#340 | Screen Shot 2017-09-01 at 2.36.24 PM.png | 203.05 KB | frob |
#322 | Selection_715.png | 34.17 KB | freelock |
#300 | Selection_381.png | 43.43 KB | freelock |
#251 | Screen Shot 2017-08-16 at 8.47.47 AM.png | 368.91 KB | frob |
Comments
Comment #2
kgoel CreditAttribution: kgoel at Forum One commentedComment #3
kgoel CreditAttribution: kgoel at Forum One commentedComment #4
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedPersonally I really do not want to see this happen. Thank you for the well-thought summary as it already has many of my objections covered. I'd add that IRC being an open protocol with huge amount of open source support means it's extremely flexible.
Making chat participation easy can be achieved building on top of IRC. It's possible to set up all kinds of web-accessible interfaces and even gateway bots between different services so I'd argue things can be improved without a migration to something else.
There are also ways in which these tools like Slack/Hipchat raise the barrier of entry rather than lower it. Most of them, like Slack, require registration. Everyone stays on their own little island that you have to separately register to. With IRC there is no registration and with so many open source projects on Freenode you may well already be set up to just join another channel.
I wasn't convinced by the arguments put forth by the WordPress team at all. The only one that I do think is a good point is about the maintenance overhead.
Regarding the WordPress participation: I think it's too early to assess the impact fully. The claims I've seen about increased participation were also made a pretty short time after the move so I'd like to know what's the latest on that.
Comment #5
YesCT CreditAttribution: YesCT commenteda little bit more issue summary detail. more to be added later tonight.
Comment #6
jaredsmith CreditAttribution: jaredsmith at Bluehost commentedComment #7
ricardoamaro CreditAttribution: ricardoamaro as a volunteer commentedComment #8
YesCT CreditAttribution: YesCT commentedadding some stats, and things to keep in mind about stats.
Comment #9
japerryComment #10
japerryComment #11
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedComment #12
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedThe only source I've been able to find that has claims about WordPress seeing any sort of increase in participation after switching to Slack are these tweets.
Later on in the thread it's said that it's just a guess, but maybe we could get some actual numbers as they were offered.
Comment #13
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedComment #14
mfer CreditAttribution: mfer commentedOne thing to consider for the tools is that with IRC you can have channels open for numerous projects while tools suck as Slack are focused on a single project. This affects cross project interaction.
Comment #15
Crell CreditAttribution: Crell at Palantir.net commentedI find Slack useful for in-group communication. Private groups, company internals, etc.
For a public group that we want to make easy to wander through, IRC all the way.
Comment #16
davidhernandezI mostly agree with Crell. I'm not a slack user, so I'm taking a look now. It appears to be invite only. How would we handle that?
Would we make one slack team and then mimic the same channels in it that we have in IRC?
Comment #17
japerryEven though I think slack solves most of the issues, personally I don't think we should be specifically using slack. The invite only thing is, well, uninviting. However, there are some open source solutions which we could investigate. (Like lets chat) What would be really cool is having chat tied to the drupal.org account.
Hipchat is another option mentioned, and if Drupal infrastructure is moving towards crowd, we could use that and get user integration for free. While in principle I like the idea of an entirely F/OSS option, it also requires our own infrastructure, which has its own costs. Using something like Hipchat (especially if its free for us) would keep in line with our chat budget, which I think is currently $0 ;)
Comment #18
davidhernandezDoes anyone know who controls drupal.slack.com or drupal.hipchat.com?
I created drupalcore.slack.com and drupalcore.hipchat.com. Feel free to try to join them and play around.
Comment #19
joshuamiI'm checking into who created drupal.slack.com. It was not Association staff, but I have reached out to Slack to see if we can transfer that ownership.
I'll do the same for HipChat. Even if we do not go that route, it would be nice if we understood how those channels were being used.
Comment #20
davidhernandezOne thing we noticed is that slack requires an invite and displays your email address to everyone. So if you want to join it will display it to others. I haven't seen a setting to hide them. We assume there is a better way to handle that since wordpress has direct integration.
Also, Cottser was very upset that his username had to be all lowercase. :P but I imagine spaces would be a problem too.
Comment #21
Tezcatlipoca CreditAttribution: Tezcatlipoca commentedHi guys... this is a thoughtful discussion. I can see you all are putting a sufficient amount of consideration into the concept of moving on from IRC. Being rigorous is important. But I have to tell you: I think it's a no-brainer. And more I think every day we practice relatively insufficient communications, we fall behind emerging web technologies and also put our community at risk to poaching by other evolving communities and technologies (and let's be honest the only thing that makes us truly special and relevant is the community we have here and through it the work we all put in).
I have a few things to say on this subject. Slack in a uniquely innovative piece of software (to my mind) that satisfies the goals of text-centric communication in a number of elegant ways. And say you don't always want to limit it to text--no one will argue that text is always best method of comm: integration of Google Hangouts for instance, allows for a quick and easy switch to more personal communications--considered all together it's the type of communications system we were promised in sci-fi.
Beyond that it's many other integrations official and community contributed make it ideally suited for so many of the things we do here. We could let each other know what we are currently working on. We could integrate our issue creation and tracking. Github integration could allow us to work and talk together seamlessly--offering an unprecedented ease that would allow us to jump over all the cruft and time sinks and just get more done together! And we wouldn't have to give up the freedom of our self-hosted git repo. Say we just allow pulls and merges to a mirror on github--perhaps the existing one that exists for other reasons (an example demonstrating that people will not sit idly by and allow modern conveniences that make life easier to go unutilized). Then we just merge in the changes. This is typical of the kind of trade-off (or lack of that we would be making in going to Slack).
IRC is a clunky 27-year old protocol having changed little in that time with a stagnating software ecosystem; it can really evolve no further to utilize it on that foundation. #drupal and the sister channels are really great. Now, I hate IRC and describe it overall as "a generally bad place where dreams go and die." That's clear hyperbole, but we all know it's less than ideal and its faults restrict both the people that use it and the communication that goes on there. The reason #drupal is great is for the same reason Drupal is great. We happen to have very many good and invested people. And they are for the most part just bearing IRC, tolerating it. Just because that's how it works, because that is how it has worked.
We have a chance to really grow as a community in quickly moving to a modern communications platform. Slack is fun! My experience is people love to use it--all kinds of different kind of people. It would open us up to a whole new world. None of that can be said with IRC. But with slack, again we don't have to give up the passable solution that's now in use. "slack-irc" a community contributed module/integration could allow us to communicate between the two, the existing IRC channels and the new Slack. And more if people are attached to their clients or dislike Slack as software, Slack provides easy and free access to the Slack and channels through the existing IRC client of choice.
I understand there is a concern that Slack is not open source or decentralized. That is significant. But it is very open in many other ways--in addition to being free. It is highly configurable with a strong API that allows us to build into it nearly any functionality we could want. Even just in the core it's built from the ground up to allow configuration and programmatic improvement allowing us to tailor it to our needs and goals. If you haven't give Slack a fair shot, just try it, because I can talk all day but none of this and much more I am leaving for lengths sake won't be apparent until you've done so. Which is a great segue...
Comment #22
Tezcatlipoca CreditAttribution: Tezcatlipoca commentedThis is how I came to find this discussion: I've recently become involved in a number of webdev slacks that are quickly changing a lot in how I work and spend my time. Naturally I sought to find a Drupal specific Slack--official or unofficial. I could not find it. I was so very surprised.
This afternoon, I decided "no longer." I created one called "DruPals" a light-hearted and quickly made up name for something I hoped would be similarly lighthearted community around the Drupal that I love. A few hours and one Drupal site later. I have created the Slack and a site to facilitate and automate invites/registration.
http://drupals.badgerfort.com/
I went to the IRC channels to recruit people late on a Friday evening (not the best time to do so) and I was directed here to read this conversation and make these posts.
So to keep this from getting any longer. I very much hope you'll join me. This doesn't ever have to move further toward the goal of being an official solution. I would be happy if simply I had some Drupal folks to talk to in a fun environment like Slack. But also, if you want to try on Slack as a possible solution to move to, here is an opportunity. Thanks for reading. Hope to hear back from you... maybe in the Slack!
Comment #23
davidhernandezOne point in favor of Slack is it has built-in IRC integration, which I enabled on drupalcore.slack.com. So far Cottser is the only one who tried to connect over IRC, but it did seem to work. I also added josuami as an owner so he can investigate integrations and other such things. The immediate concerns that are all show stoppers are the invite-only aspect and email addresses being visible to other users. (both may have solutions through drupal.org integration.)
The other thing that would greatly concern me about trying to use Slack for our community is scalability. Just looking at the interface, I see how this can work well for a team, but I don't see how it doesn't become unmanageable with hundreds/thousands of team members.
Comment #24
joshuamiHi all, I had a conversation with Slack support today. They are excited to help us in whatever level of demo or integration is appropriate. To that end, the drupalcore.slack.com account has been changed over to drupal.slack.com so that we at least hold the namespace.
I've also talked with Slack about what scalability and privacy would look like. They do have some sort of public rooms and or community teams planned in their roadmap, but they are still working through those requirements. If we want to provide them with requirements that would make sense for the Drupal community, I'm happy to act as a conduit.
While I'm not convinced just yet that we *should* move to Slack for the community, I do think it provides a lot of great functionality.
I have been quite impressed with its use by Drupal Association staff for internal collaboration and for external collaboration with the community members that are part of the DrupalCon planning. They have been using Slack for planning the DrupalCon programs starting with LA. Drupal Association staff have been using slack since November. Given that we have a good mix of technical and nontechnical employees, Slack has been incredibly easy to implement within our organization. (Far easier than setting non-technical users up with IRC for instance.) That same ease of implementing Slack is not likely to be the case for a community roll out. I share David's concerns about scaling that administrative interface to hundreds of users.
Does anyone have a good sense of how many unique Drupal IRC users exist? I'm curious just for the sake of knowing how big we need to think in considering alternatives to IRC.
In the meantime, at least we own the drupal.slack.com namespace for testing possible integrations.
Comment #25
MixologicHere's another open source slack clone:
http://www.mattermost.org/
Comment #26
kattekrab CreditAttribution: kattekrab at Creative Contingencies commented@joshuami
This might be something we could ask the freenode ops to find out for us?
The biggest channels, #Drupal, #Drupal-Support and #Drupal-Contrib - but there are hundreds of smaller channels, and I know many people aren't on the big channels for various reasons.
Comment #27
japerryTelegraph.org is another suggested chat medium.
Gitter works from github.
Comment #28
geerlingguy CreditAttribution: geerlingguy commentedOne good point of reference—a reason why you can pry IRC from my cold, dead hands—LimeChat (on 8 different IRC channels with two networks, been running for a few hours today) is using about 30 MB RAM. Slack, with about 10 channels across two 'teams', is using 490 MB RAM.
Lightweight, many of these other solutions are not... that's one major concern as I look at my Dock and now see Adium, LimeChat, Skype, Slack, and HipChat clients all required for different projects. I hate the idea of requiring terabytes of wasted RAM across the Drupal community just so we can get a few more likely-inactive-users signed up for official chat channels.
The sell has to be a lot more compelling than inflating numbers of logged-in users. #ansible generally has 1,000+ users in the room, but only a couple hundred have ever posted much, and far fewer actually use the room for more than 'StackOverflow Instant Q&A' (more like the #drupal-support channel than #drupal or #drupal-contribute, both of which are more community-oriented).
Comment #29
star-szrSlack is one alternative that we've been testing off and on it has an IRC gateway.
Comment #30
geerlingguy CreditAttribution: geerlingguy commented@Cottser - If the IRC gateway is enabled (and works well under load), then that would negate some of my earlier arguments, since I (and others) could continue using IRC clients with Slack.
Comment #31
star-szrIt's enabled, I tested it, not sure on the load part.
Comment #32
cferthorneyAs a potential work around for the whole invite system that Slack integrates, the Laravel people have created an auto invite system of sorts over at larachat.co, it would suggest that some sort of integration can be rigged together even if someone within the community had to write something from scratch from an integration side of things? (I've not even begun to look at that so don't even know what is or isn't possible with their API's)
Kind regards
Dave
Comment #33
realityloopComment #34
realityloopComment #35
lsmith77 CreditAttribution: lsmith77 commentedwhat about talking to irccloud.com about a special deal for drupal related channels to be part of the free package?
Comment #36
fuzzy76 CreditAttribution: fuzzy76 commentedWhile I personally love Slack, I really don't feel comfortable with Drupal going all in for it as a recommended communication channel. Do we want to become dependent on a proprietary commercial system?
Comment #37
PolHi,
I'm also willing to test slack, could you invite me please ?
Here's my email address: pol.dellaiera@gmail.com
Thanks a lot !
Comment #38
kgoel CreditAttribution: kgoel at Forum One commentedI have added "Technical Working Group" tag so someone from the group or group can evaluate if it's possible to replace IRC or not.
Comment #39
PolComment #40
rteijeiro CreditAttribution: rteijeiro at Tieto commentedI think it's a terrible mistake to switch from IRC to a non-FLOSS solution just to "make chatting easier"?. I don't think we are going to solve a problem (if there is a problem) just switching or adding more tools to our daily basis.
I think it's just about culture. There are people that like synchronous communication like chats and there are other people that like asynchronous communications like email.
That's all.
I think we don't need more tools.
Comment #41
fuzzy76 CreditAttribution: fuzzy76 commentedFWIW, I think Mattermost and "Lets chat" looks like better candidates. Most of the advantages of Slack, running on an open implementation.
Comment #42
chx CreditAttribution: chx commentedSuppose They Gave A War and Nobody Came.
Sure, somebody (who?) claims X is the new schnizzit and then the community shrugs and continues to use IRC. As mentioned on Drupal SE meta "Drupal communities are a bit balkanized, so often top-tier Drupal contributors are most active in their own local channel, or the project specific channel which interests them most—the maintainers of Drupal Commerce hang out in #drupal-commerce for instance" so you'd need to fight that down one by one. Good luck.
This issue should be won't fixed as it's impossible.
Comment #43
wizonesolutionsPerhaps Sameroom is worth checking out? https://sameroom.io/open-a-tube
You can open "tubes" to bridge chat platforms. So, in theory, people who like IRC wouldn't have to switch. Haven't tried that combo, but might be worth testing?
Comment #44
wizonesolutionsRe. @davidhernandez's concern about email, WordPress has set up a USERNAME@chat.wordpress.org cloaked email. That's similar to what we did for Git. So many our auto-inviter can do something similar. This would require setting up an email relay, but if WordPress can handle that, we probably can do. They should probably be distinct from the Git addresses and ONLY work for people who've actually signed up for Slack. And, like WordPress's, it would only actually accept email from Slack's servers (so no one can use them to email people against their will).
Seems like a good solution to that issue. Maybe we can ask them how they did it.
Comment #45
chx CreditAttribution: chx commented> This might be something we could ask the freenode ops to find out for us?
I can try asking freenode staff to query how many users are on #drupal* but it might not be something they can (easily) do. Note this is not something the Drupal group contacts can do -- we have very few powers the users don't. Mostly just enough to kick and keep trolls out.
Comment #46
kgoel CreditAttribution: kgoel at Forum One commentedI have removed "request to join Drupal Slack channel" from the issue summary because it doesn't say contact who. I have received requests for joining slack and I don't have any control over that and I don't know who is moderator/admin for that. Users are mistaking me as moderator since I created this issue. I don't want to be rude to them by not replying and I can't reply to all the emails :)
Comment #47
basic CreditAttribution: basic at Drupal Association commentedAnother option, just to throw it out there: https://telegram.org/blog/channels
Telegram has channels now, and clients on almost every platform.
Comment #48
heddnhttps://zulip.org is open source and has clients for many platforms.
Comment #49
Crell CreditAttribution: Crell as a volunteer commentedlsmith's suggestion of contacting irccloud.com seems like the best one yet; still IRC under the hood, but a nice client since that seems to be the biggest gripe people have with IRC. (Other than it not being hipster enough, which I ignore as a criteria.) That's nice and low-effort. Anyone want to give that a shot?
Comment #50
Pol+1 crell. I discovered irccloud last week (@drupol on irc).
I bought the subscription right away.
The android client is very good too.
Cant live without it now.
Comment #51
PolThat said, Telegram and channels are super good too.
Comment #52
fuzzy76 CreditAttribution: fuzzy76 commentedAtleast half of the concerns in the issue summary are still valid on irccloud though.
Comment #53
realityloop@heddn I tried Zulip today on one of my servers, the desktop client on OSX at least has no way to connect to a private server, also the UX is very confusing (I'd almost say worse than IRC).
It also allows anyone to create private streams which I don't think is a good idea personally.
Comment #54
tim.plunkettAn article on the React community moving away from Slack: https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to...
Comment #55
tim.plunkettOoh, even better, they posted the research they used to make the decision: http://www.jordanhawker.com/posts/131477030371
Comment #56
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedThe concern listed in the summary about IRC lacking scrollback/history doesn't seem like a very strong argument when it's a feature that's easy to have even without bouncers. It would even already be possible via druplicon but has not been enabled for the drupal contribution channels by choice.
Based on the Reactiflux and freeCodeCamp experiences described in the link in #55 Slack seems like it's probably a non-starter...
Solutions that don't get rid of IRC but help with the concerns about the barrier of entry seem like the best to me. Working towards just getting a better Freenode webchat would be ideal in that all the open source projects on the network would benefit but that's probably a pretty challenging way to do this.
Comment #57
elwayman02 CreditAttribution: elwayman02 as a volunteer commentedTim, I'm happy to answer questions about the research I did...thanks for linking it here! I'm pretty happy with Discord right now...the onboarding experience is great and barrier to entry is low.
Comment #58
webchickAlso there's like barbarians and shit:
I played around with this for a bit and it's very interesting. The fact that you can jump to voice at any time IMO is hugely beneficial, esp. for gnarly technical discussions and/or highly aggressive convos that are going off the rails.
One immediate question I'd have, knowing about various incidents involving gamers on Twitter, is how private is a given Discord server? Are we going to get numbskulls barging in and using l33t sp34k and threatening to beat up women? (IRC is definitely not immune from this problem at all but for whatever reason—probably a crap ton of work on Freenode's side—we've been really lucky with this.) Another one would be, are we impacted if one Halo clan and another Halo clan decide to smack each other around? (We have gone down too when neighbours have been DDOSed on Freenode, OSL, etc. in the past.)
Comment #59
markie CreditAttribution: markie at Mediacurrent commentedFWIW: Here's the link to the WP intro page. https://make.wordpress.org/chat/.
Comment #60
wizonesolutionsI predict WordPress is going to hit the same limitation as React did pretty soon.
Discord's probably worth looking at. It's not Slack, but IRC isn't Slack either. The throwaway joins are a pretty cool feature. Much less of a barrier than Slack.
Does Discord keep email addresses private? That would mean we wouldn't have to run a purpose-built relay to mask them like WordPress does for Slack.
Comment #61
realityloop@wizonesolutions
Yes with Discord email is hidden, even to the server owner..
Comment #62
marcvangendI just came across this post https://drewdevault.com/2015/11/01/Please-stop-using-slack.html which lists a couple of reasons why you should not use Slack for FOSS projects, and names irccloud as the best alternative.
Comment #63
Derimagia CreditAttribution: Derimagia at Mindgrub Technologies commentedAnother benefit of slack is that they bought Screenhero a few months back and are working to integrate it in. I think this would be a big plus for cooperation.
https://slack.com/screenhero
http://blog.screenhero.com/post/109337923751/screenhero-joins-slack
Edit: I didn't see the article about React moving away from slack. That's a real shame. My point is moot.
Comment #64
japerryIRCcloud costs money. Its a non-starter for 'removing the barriers' to entry. Contributors shouldn't (and won't) be expected to pay money just to communicate.
Comment #65
heddnIRC Cloud has a free option. And for most people, that is fine. They don't need to stay online 24/7. Which, from what I can tell, is the only benefit from paying 5/month.
Comment #66
star-szrBut then we lose the asynchronous benefit right?
Comment #67
fuzzy76 CreditAttribution: fuzzy76 commented@heddn That solution won't satisfy even half of the concerns mentioned in the issue summary.
Comment #68
heddnHere's the thing, IRC Cloud by itself isn't the solution. I think that IRC is the solution. Because it is open source and has multiple clients. Not all of which are terrible. If the barrier to entry into IRC is its complexities, solutions are being developed to overcome it. IRC Cloud is the best example I know of. If you want a proprietary solution i.e. Slack, then you can, if you want connect it to IRC. Flexibility for our diverse community is critical. The biggest knock against IRC has been its high entry-bar. And for the past 7 months, we've not found any better solution than IRC.
So, if the entry-bar is lowered via solutions like IRC Cloud, what are feasible/reasonable solutions?
I'm not convinced we have consensus yet, or ever will have consensus. So, unless we want this issue to just be a breeding ground for rants, I'm going to take the tentative step and mark this RTBC. IRC works. It isn't ideal. But another solution doesn't exist. We can (and probably will) revisit this decision again in another 6 or 18 months. But until then, let's move on with other things.
Or maybe I'm wrong and I haven't summarized the rhetoric. Maybe there is a solution that has surfaced above or will surface by someone else in the next few days. In that case, feel free to move this back to "needs review".
Comment #69
star-szrI don't think this is accurate:
Slack provides an IRC gateway but I don't think you can connect Slack to Freenode. But maybe I misinterpreted this :)
Comment #70
fuzzy76 CreditAttribution: fuzzy76 commented@heddn This issue is still about the concerns people have voiced with IRC, as listed in the summary on top. Adding IRC Cloud on top as a "preferred" client still won't change the list of issues much (15% of them maybe).
And @cottser is right, Slack can't connect to IRC but IRC-clients can connect to Slack. Most of the third-party solutions suggested here (including Slack) has a lot of features that IRC-servers doesn't support.
Comment #72
ztl8702 CreditAttribution: ztl8702 commented@cottser You can "connect" Slack to Freenode by using a bot to forward messages between those two systems.
Comment #73
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedWanted to expand on some of the concerns I see with moving to one of the mentioned services. The Hacker news discussion of the article that @marcvangend mentioned in #62 has more on some of these.
Concerns with choosing one of these services
Here are some concerns I'd like to raise about going with any system that is hosted, closed source and a walled garden - be it Slack, Discord or something else. These services are completely under the control of the company that provides them. An example of this biting someone that just happened is that while Slack does list unlimited team size as a feature, it turned out there actually were limits for the Reactiflux community at least. The Bitkeeper episode in the history of Linux kernel development is another cautionary tale of what can happen when you don't consider these risks.
These companies can pivot, they can go out of business or they can come up with disruptive ways to monetize their product only after building a gigantic userbase. Possibly even worse, they can also fail to do so (see PlugDJ). Discord for example is a free-for-all service that seems to only have very vague idea of how they're ever going to make money. It would be wise to assume the pricing won't stay fixed and something like Slack deciding to charge everyone per-user would be problematic for Drupal to put it mildly.
Things like IRC/XMPP bridges can also go away later on in the life of these products. Once again the examples are many but just a few are Twitter getting rid of RSS, Tapatalk closing their API and Google Talk disabling federation with other Jabber servers.
The services often lack any support for Linux (let alone BSD). I think in an open source community some thought should be given to that. It's likely that more people than on average are on those platforms. Things like IRC bridges and web interfaces become the only option then and the user experience they offer is often second class. The option to use a pastebin looks very nice compared to the prospect of not seeing the pasted code in a clean way over a the bridge.
Issues with Slack
Besides the huge issue that Slack apparently doesn't support communities of this size as Reactiflux found out the hard way, I've seen some other limitations being mentioned for it:
Issues with Discord
It doesn't sound like they have a real plan for how they'll make money yet and their target audience is gamers, not software developers. This could mean they end up prioritizing features that are of no use to Drupal or even doing something that doesn't work for Drupal at all.
Some features they're lacking:
Would switching from IRC actually hurt participation?
The Freenode network has 90,000-100,000 active users. Most of these are very likely to be interested in open source software. Making it harder to join for this substantial pool of people with relevant interests sounds like raising the barriers of contributing instead of lowering them. They are now just a /join away but won't probably start using 3 different services if WP is on Slack, Drupal is on Discord and PHP stays on IRC.
Comment #74
fuzzy76 CreditAttribution: fuzzy76 commentedI totally agree with the concerns about commercial services. We should not be tied to the survival of companies with changing priorities and business plans.
But this is not an issue with the self-hosted open-source solutions. After a brief research round, the only one of them that seem to support an open protocol for third party clients is Let's chat which has XMPP support. That would let people use any client that support XMPP (quite a few IRC clients do), and bitlbee if people really want a bridge.
I also wanted to add that lack of Linux support is a pretty moot argument for something that's primarily a webchat. If your browser can run it, you are supported. The apps aren't much more than a webview any way.
Comment #75
marcvangendThanks Antti.
+1 for mentioning that moving away from IRC may raise the barrier for people from other FOSS communities who are already on IRC. I'm adding a list of arguments in favour of IRC to the issue summary, feel free to expand it.
Comment #76
realityloop@fuzzy76 Main potential issue I see with Let's Chat is that they say its for "Small Teams", it seems like mattermost may be the best long term option, but it's still not perfect.
Comment #77
mlhess CreditAttribution: mlhess as a volunteer commentedThis comment is in full HTML and has some IRC cloud embeds in it.
I talked to irccloud folks today. They are willing to work something out for us.
By default, they have buttons that we could add to our IRC page.
They have an inline javascript embed, which I have not put here, but we could use if we wanted to as well.
That will require a email and email confirmation before allowing a user in. However, they are open to doing an SSO with Drupal.
So the workflow would be something like
Non logged in users:
1) go to the IRC page on d.o see warning message that D.O will share your email address with IRC cloud
2) see listing of all channels
3) choose which ones you want to join
4) on IRC cloud, provide email address
5) check your email account and confirm.
6) Your on IRC in those channels
Authenticated users
1) Go to IRC page on D.O
2) See listing of all channels
3) choose the ones you want to join
4) You're on IRC in those channels
Comment #78
fuzzy76 CreditAttribution: fuzzy76 commentedThat fixes 6 out of 16 problems listed in the issue. What about the rest?
If we do decide there is no better option than staying on IRC for now, I guess the IRCCloud integration is better than nothing. But we still need to acknowledge that it means leaving the rest of the problems hanging around.
Comment #79
mlhess CreditAttribution: mlhess as a volunteer commentedIt is REALLY easy to add an IRC channel.
This would be true in any service. It takes people to own a channel.
This would be resolved by irccloud.
What does this mean?
I think this is solved.
Many of the other items up there are not solved by any solution but rather work on top of a solution. I am also not saying that IRC cloud should or is the solution, but it solves many of the issues above, and could be implemented without many changes or much work.
Maybe that we need a solution for folks getting help that includes realtime, forums, and communities.
Comment #80
joelpittetRemoving 'IRC is old', it's not a valid reason for anything. Also may be a benefit because it is also fairly stable, tried tested and true;)
Comment #81
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI don't know if anybody cares but I won't use software that's a) run as SASS by a potentially unreliable 3rd party or b) not Open Source within the context of communication of an Open Source project. That feels just wrong to me.
IRC just works fine for me.
But then: the only channel I really use nowadays is #drupal-security. Assuming that stays on IRC, the rest can move to #drupal-hipster elsewhere.
Comment #82
heddnre #81: that's fine. Using something like irccloud gives folks like you that flexibility. But it is still IRC, so it also gives folks who want to use Adium, LimeChat, HexChat, Pidgen, etc their choice of options too. But the positive to using irccloud is that for folks who do not have your qualms and just want to connect to the larger community, we can lower the entry bar. It would give another entry into our community. And more entries is usually a good thing.
Comment #83
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI don't share the belief that lowering the barrier to entry is a good idea.
irccloud.com probably is one of those "potentially unreliable 3rd party providers".
You of course are free to use it.
Comment #84
joelpittet@killes@www.drop.org I tried to join #drupal-hipster yesterday, I was the only one there... I'm guess it worked? :P
Comment #85
gregglesI've update the issue summary a bit.
I restated a few things and separated out some items that seem like general problems that are not specific to irc.
I removed "irc is difficult to use, for example". That seems vague and redundant with some of the others and rather subjective. I find irc quite easy to use compared to slack, especially for the number of rooms that I join. When I've tried slack and had more than ~5 conversations open it became hard for me to understand which conversations had unread messages.
I added a note asking for other examples of third-party integrations that are useful other than "/hangout" ? The ability to quickly generate a hangout url feels like a pretty weak feature of these kinds of tools.
I reordered the list to group together similar issues. A lot of these feel like the same problem said in a different way which makes irc seem worse than it is. I didn't delete all of the duplicates just yet, but I think a few more could be deleted/consolidated.
I also added to the subjective part about proposed solutions to indicate that while some of the SAAS solutions like Slack solve many of the feature-requirements they do not solve some of the privacy requirements and philosophy goals. http://www.theverge.com/2014/11/24/7255199/slack-alters-privacy-policy-t... is an example of a privacy concern related to slack, for example. I'm not sure that specific change would be relevant for our organization, but the fact that they can make that kind of change in the manner a typical corporation does (without user feedback until after that event) makes me rather wary.
I think that irccloud is pretty awesome for some use cases (I've used it a bit and didn't pay for it).
I use a mix of hipchat, slack, and irc for work. I do not think that a solution like hipchat or slack would be a good solution for the Drupal project in general. They are focused on solving different problems for different communities. irc, and freenode specifically, is directly focused on serving communities like ours so they are more likely to have philosophies and ideals that match ours.
Comment #86
fuzzy76 CreditAttribution: fuzzy76 commentedFirst of all, I just need to congratulate @joelpittet for being able to say that he hang out in #drupal-hipster before it was cool. :)
On a more productive note, there is also http://shout-irc.com/ which is a sort of "open source, selfhosted IRCCloud". I have no idea if it is scalable enough for Drupal to host it, but it seemed relevant here. It does have multiple user support.
Comment #87
japerryAdded Zulip, another self-hosted option. Also added that the DA, in our discussions so far, has been to not want to host chat internally.
Comment #88
gregglesI'm not sure what "self hosted" means in this context. Is our current irc self-hosted? Can you expand on that a bit?
Comment #89
fuzzy76 CreditAttribution: fuzzy76 commentedI guess you asked jasperry, but I think both he and I mean chat clients that uses a backend running on d.o infrastructure in order to provide a persistent connection and a unified user experience. In that regard, the current IRC is not "hosted" at all (it leaves the client and connection maintenance up to each user, which I guess is part of the problem).
Comment #90
gregglesSo maybe another way to say that is that it shouldn't increase the burden on the Drupal project (DA, infra team, etc.)?
Comment #91
fuzzy76 CreditAttribution: fuzzy76 commentedIn that case, a lot of the proposed solutions are off the table. As far as I can tell our main choices would then be:
Comment #92
kattekrab CreditAttribution: kattekrab at Creative Contingencies commentedpersonally... I kind of don't understand why folk find IRC so much harder to use than Slack. But I'm willing to accept that's my shortcoming.
What I do find odd - is that there doesn't seem to be an IRC client that has stepped up to the challenge posed by Slack. Or have I just not looked hard enough? I think Slack is definitely innovating in the real time chat space. It's slick and user friendly, and has some nice features not found in IRC.
But I share all the concerns raised about it being non-foss and in-appropriate for an open source project.
@greggles - awesome work on synthesising and refining. Thank you!
Comment #93
gregglesThanks Kattekrab :)
As promised in #85 I went through again and consolidated items that were redundant.
Comment #94
basic CreditAttribution: basic at Drupal Association commentedI'm writing this with my own personal biases in mind:
My irc/znc bouncer box died over the weekend and prompted me to set up irccloud in the interim so I could get back to #drupal-infrastructure and my other IRC channels. After using it for the last few days, I don't think I will be switching back to znc any time soon.
@kattekrab -- irccloud is nearly there, the only thing missing is an officially supported desktop application. There is an unofficial electron app that is decent enough.
The irccloud interface is nice, and implements many of the "hip" features (inline images, :emoticons:, automatic pastebin, etc.), and usability improvements (async communication, web/ios/android/(unofficial desktop) apps, etc.). It also changes nothing about the underlying irc channels and configuration for those already happy with znc/irssi/textual/etc.
Third party services integration is something we rely on heavily in #drupal-infrastructure and is solved by running irc bots. Druplicon, drupalmon, jenkins, manatee, etc. There likely exists an irc bot for the integration(s) we are lacking.
The only remaining issues (#77 addressed my primary concern) with using irccloud as the solution are the lack of "user is typing..." functionality, and lack of built in search functionality. That said, with all of the discussion and potential solutions discussed this far, it seems like irccloud provides the most benefits while leaving the legacy intact.
Comment #95
heddn+1 #94. That's what I've found since my computer died and I had to quickly replace it with another. IRC Cloud was just easy. And it still gives us IRC; so folks that want to use their client choice can. That is the beauty of IRC. It meets the most people where they are at currently, while still giving folks the chance to get some of the benefits of other softwares. I'm specifically thinking of all those capabilities you outlined in #94 that are similar to Slack. In the open world of FOSS, you are going to find it hard to find something so liberating as IRC. And the comments that it is so it is "old school" and "too hard" and "it is blocked at my place of work", do have options. And IRC Cloud isn't the only option. It is just the one I'm most familiar.
So, enough of that. What is next for this issue? Looking over the issue summary again, what are the outstanding items and next steps?
I'd propose as a next step that we just stick with IRC, because nothing better has offered itself up to us. I suggested that also in #68, so I'll let someone else take the bold step and decide where we go from here.
Comment #96
theamoeba CreditAttribution: theamoeba commentedComment #97
Gabriel Engel CreditAttribution: Gabriel Engel commentedHi there, I am Gabriel Engel, the founder of Rocket.Chat
We'd love to to host a Rocket.Chat server for you for free.
I believe this would be the best possible option here. You'd support another free open source project and remain free to export your data move anywhere, either to host
Rocket.Chat yourself where ever you like, or move to another solution completely.
If you like to give it a goal with our cloud, please just complete the form at https://rocket.chat/deploy
You will have your server running in a few seconds, and you can get the links to our iOS, Android, OS X, Linux and Windows clients from our website. They are all open source projects too.
Please ping me if you have any questions!
Comment #98
realityloopI know that Gitlab's roadmap is to deprecate mattermost in favor of Rocket Chat
Comment #99
greggles@Gabriel Engel - thanks for the offer. One thing that I wonder about is https://www.quora.com/unanswered/How-does-Rocket-chat-make-money Can the Drupal community rely that Rocket.Chat will still exist? It would also be good to know how Rocket.Chat might handle some of our existing needs like being able to have private rooms and moderate (i.e. kick) people.
Comment #100
fuzzy76 CreditAttribution: fuzzy76 commentedJust want to mention that https://matrix.org/ seems to be a really promising open protocol / network which solves a lot of problems in one go (HTTP-based, federated and allows bridging to other protocols - Freenode is already available there). I don't really think it's mature enough for Drupal to consider yet, but personally I'm putting it on the top of my list of technologies to try out.
Comment #101
heddnI'm going to mark this RTBC and suggest that the next steps are:
Comment #102
heddnI've opened #2706381: Add handbook page for suggested IRC clients
Comment #103
Marko B CreditAttribution: Marko B commentedLets not play this game again and again. Like drupal 7 and drupal 8 and then we moved to full OOP anyway, just waist of time and resources slowing us down.
Do you need more data then this? https://www.google.hr/trends/explore#q=irc
Do you want to attract new people, young people who never heard of IRC and will run away from it when they see it, finding drupal just old tech.
We will again be late because some people don't want to change and we will be on loss because of it.
Comment #104
mr.ashishjain CreditAttribution: mr.ashishjain at AddWeb Solution Pvt. Ltd. commentedWhat a fantastic conversation I came across while trying to get my hands on IRC [after procrastinating it for almost a year]. Thats the beauty of community, its exactly like "Democracy" where everybody is heard and interests are protected/respected.
I must admit oldage tech IRC is a push away for new joinees. Laravel using Slack too. That shows the evolving tech world is embracing new technological advancements on how they communicate rather than sticking to the age old tech. If we've options, why not?
We use Slack in our organization, but talking about the community, I think we do not need a commercial entity here, but open source, so 2 options seem best to me: Mattersmost and Letschat.
How about starting a voting?
Comment #105
larowlanFYI some arguments against slack and other walled gardens - for posterity sake:
https://medium.freecodecamp.com/so-yeah-we-tried-slack-and-we-deeply-reg...
http://sircmpwn.github.io/2015/11/01/Please-stop-using-slack.html
Comment #106
kevinquillen CreditAttribution: kevinquillen at Velir commentedSlack is the new hot, but there is no guarantee it will still be running 3-5 years from now. IRC will likely always be around.
Also, consider from that article:
"A few weeks ago, Reactiflux reached 7,500 members on Slack. Shortly after, Slack decided we were too big and disabled invites. There was no way for new users to join. Many of us were sad and upset. We loved Slack. Our community was built around it."
So yeah, there is no guarantee some suit at Slack wouldn't ever be like "hey, there's 45,000+++ Drupal users in the community channels! Cut it off and make them pay $7 a month per person".
Ryver, Mattermost and other Slack clones will have a life half as long as Slack.
Despite my hangups with IRC, its the best fit for anyone, anywhere, on any machine. Doesn't look as nice as the other options, but it doesn't need to, either.
Comment #107
mpdonadioThis is likely something that we will never have true consensus on, but I am with the crowd that despite its shortcomings, IRC is ubiquitous and works well for the community.
Perhaps, the best followup to this is an issue to explore if there are additions to Druplicon (http://druplicon.info/ and https://www.drupal.org/project/bot) that could improve the IRC experience for people?
Comment #108
andypost+1 to stay on IRC
Comment #109
japerryJoomla switched to 'Glip', another tool that is slack-ish:
https://www.joomla.org/announcements/general-news/5588-joomla-and-glip-e...
https://glip.com/joomla
Comment #110
japerrySimilar to the github, forums, or other services, slack is already becoming pervasive within the drupal community. ( http://drupalslack.herokuapp.com/ )
Let me elaborate a little on the 'self-hosted' problem: Chat is not an easy infrastructure item, especially when it comes to scale (over 100 simultaneous users). We've been lucky in that freenode hosts our IRC channels, meaning the Association doesn't have to spend any money on chat.
If its a requirement that we cannot self-host chat, it means we're relying on a third party to not only be able to host us now, but also scale as we grow adoption of the platform. My main worry with slack is that its been proven not to scale, with many large communities regretting the decision to switch.
However, open source may not be the solution here either. Can Rocket chat serve 30,000 users? If we're using a SaaS solution, the open vs closed debate is less important IMHO.
Comment #111
kevinquillen CreditAttribution: kevinquillen at Velir commentedWas pretty dead when I was in earlier in the week; and as you said, Slack does not scale.
What is the main motivation to making the community shift chat protocol/platform? User engagement won't be solved by the software. Is the perception that IRC is scary or hard to use? I'm playing devils advocate.
Comment #112
Crell CreditAttribution: Crell at Platform.sh commentedKevin: Honestly I think it's mostly "IRC is scary and hard to use". "Newbies don't know what IRC is, they use WhatsApp". Or whatever. Secondarily, it doesn't have emoji. (Whether that's a bug or a feature is rather subjective; I consider it a feature.)
Personally I see no significant issue with IRC that isn't solved by
1) sticking an IRC web client on a web page somewhere
2) Pointing people at IRCCloud
(At least none that don't exist in any semi-real-time text medium by definition.)
Honestly, we don't even have to tell people that they're using IRC. They're using "Drupal chat", at http://www.drupal.org/chat. Which just so happens to be one of a hundred web clients for IRC that is setup to talk to Freenode. (Or something similarly smoothed over.) Yeah, telling people to go get mIRC or Colloquy isn't nice, but that's not an issue of IRC itself.
Comment #113
Gábor HojtsyI am a happy customer of irccloud. The reason I started paying after years using IRC with various clients is my internet was bad for a while. It kept throwing me off the channels and it was very hard to hold a conversation. I needed a bot for me so I can read things from the time I was offline. Instead of spending time on trying to set it up myself (which we cannot ask people to do), I started paying for my own good (which we cannot ask people to do either). It was an extra benefit that irccloud comes with a mobile client as well that works relatively well. One definitely great thing about chats other than IRC is that you have a scrollback by default and your presence is much less connection-bound.
Comment #114
Pol+1 to stay on IRC but as Crell said, pointing people to IRCCloud or something user friendly would be great.
Comment #115
fuzzy76 CreditAttribution: fuzzy76 commentedhttp://webchat.freenode.net even has a nice embed option (even though it lacks the persistent connections of IRCCloud).
Comment #116
dqdLet me keep out the IRC pro/con part because, IMHO, I think it is too early to let this pro/con decide here on a much broader asked question to discuss, in a long term. This awesome article and carefully written questionaire is about thinking outside the box, so to simply vote for staying with IRC is contra productive. First, we should take a deeper look into ALL alternatives. Don't get me wrong, I am an officially IRC and terminal chat (irssi) advocate for the most and if it finally comes to the conclusion that IRC is still THE SHIT, I am the first applauding. But that should not be the point here yet, first things first. Not without discussing all opportunities and newer developments carefully. What if we look around and find a combination of both? Who knows? Today all is possible. When SASS came nobody thought of LESS and when LESS was there, nobody thought of that SASS would come back so fast. Today is different then the time when IRC was born. If it would be possible to combine mattermost users and IRC users in the same channel, e.g., well ... I would immediately sign it!
BTW: for the Slack vs mattermost supporters, here is an interesting read: http://www.mattermost.org/what-slack-might-learn-from-its-open-source-al...
And BTW (2): What did I sad some lines above about IRC combined in ... Mattermost v1.1: Now connects to IRC, as well as your in-house applications
Apart from that I certainly would underline the last paragraph from here #107 which isn't against a combination of anything ...
Last but not least: It is actually no *decision* needed, it is just a question of how to improve the experience without leaving IRC, since there are already options to get best of both worlds.
Comment #117
fuzzy76 CreditAttribution: fuzzy76 commentedSorry to say, but bridging through a single bot connected to IRC is close to useless for doing actual discussions across networks. The absolute minimum for a bridge should be that everyone sees all users as a user, not seeing half the channel hidden behind a bot. If not, you're ruining nick lists, presence notifications, autocompletion, private messages etc.
Matrix already bridges the entire Freenode network with real clients, and is actually the only one I've seen that accomplishes this. I guess this is because their bridge is linked into the Freenode network the same way a regular IRC server is.
I use this daily. There is also an option for doing it the other way around, allowing IRC clients to connect to a Matrix server using PTO.im.
Comment #118
freelock+1 for Matrix.org -- it's an excellent system, far more open than Slack, can be set up with guest access and public history, is already bridged to Freenode (I'm in #drupal and #drupal-migrate right now via Matrix), the bridge shows actual users on both sides, it meets/exceeds all the other desired improvements over IRC. There are great mobile clients and a fast-growing ecosystem.
We also use it heavily as the backbone for DevOps on our Drupal sites. It can be entirely self-hosted, people from multiple servers can interact seamlessly across any number of rooms, etc.
To check it out, you can join the #drupal Freenode room by going here: https://vector.im/beta/#/room/#freenode_#drupal:matrix.org, and creating an account (Freenode-bridged rooms are not configured to allow guest access or history by default).
Best thing about this is that people can continue using IRC if they prefer, and won't miss out!
Comment #119
dqdWell, maybe you both misread my post, but that was actually exactly what I was after by mentioning other options. Maybe you misunderstood that I had no preference here persé, but simply took some fast picked examples out of the web only to point to the same issue behind like you: that both combined is possible and no decision against IRC is needed. But maybe you both are referring to other posts before me, then please use #Nr. references to declare that. Otherwise the reader assumes you reply to your predecessor in the queue.
Comment #120
YesCT CreditAttribution: YesCT commentedComment #121
lpalgarvio CreditAttribution: lpalgarvio commentedTelegram - https://telegram.org/
Centralized, clients opensource, server closed
Can create channels and groups, with join link and supports bots.
Has webclient and mobile apps.
Bridge IRC to Telegram:
https://github.com/FruitieX/teleirc
https://github.com/RITlug/teleirc
Mattermost also supports bots, has mobile apps, server and webclient, integrates with Redmine, Kanboard, Jenkins, GitLab, GitHub (service) and more.
Bridge IRC to Mattermost:
https://www.mattermost.org/mattermost-v1-1-open-source-slack-compatible-...
Rocket also supports bots, has mobile apps, server and webclient, integrates with GitLab, GitHub (service), Telegram and more.
Bridge IRC to Rocket?:
https://github.com/RocketChat/Rocket.Chat.Federation
Comment #122
lpalgarvio CreditAttribution: lpalgarvio commentedHey,
For our Portuguese Community ("Drupal Portugal"), we are currently using with great success a bridge between IRC and Telegram with the opensource project FruitieX/teleirc deployed in a VM.
We have a bot and a channel on IRC and on Telegram.
Online for about 10 days now.
IRC: #drupal-pt
Telegram: https://telegram.me/drupalportugal
The bot is named Druplbot and can map as many IRC channels <-> Telegram groups as needed.
https://github.com/FruitieX/teleirc
We are looking into additional synchronizations to Hangouts and/or other protocols and considering additional tools.
Comment #123
lpalgarvio CreditAttribution: lpalgarvio commentedComment #124
lpalgarvio CreditAttribution: lpalgarvio commentedSlack doesn't seem to support per Channel admins.
With that in mind, I think you can cross out entirely the Slack solution as communities need some independence.
Comment #125
freelock-1 for Slack... a closed-source SaaS is not a good fit for an open source project.
There's not really any decision needed to use Matrix -- I'm using it now, in several #drupal rooms. They just launched the main web app under a shiny new brand -- http://riot.im, and it has most of what Slack does, but is already integrated to any Freenode IRC room you want to join.
While the bridge is hosted, the code running the integration is fully open source and published on github, and anyone can run their own copy of the bridge. I run my own Matrix server, and in other chat rooms where a substantial number of participants had switched over to Matrix, we were largely unaffected by the recent Freenode DDoS netsplit issues...
Compared to Slack, aside from the ability to easily self-host and federate transparently, there is no limit to the history that may be kept (Slack has a 10,000 message limit before you have to upgrade to a paid plan), we can open rooms to guest access, and the bridge is far more transparent/less intrusive on the IRC side. The main current downsides is lack of IRC presence (this is available if you run your own bridge, but caused too big a performance hit on Matrix.org so it's disabled -- the issue is that on the Matrix side you can't see whether an IRC user is in the room or not), and a few missing shiny widgets that Slack has (such as reactions, and more bot integrations already written).
See https://riot.im/app/?#/room/#freenode_#drupal:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-migrate:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-commerce:matrix.org for some examples (you do need to log into Matrix somewhere to be able to join Freenode-bridged rooms).
Plus decent Android/IOS clients... And a Weechat plugin if shell apps are your thing. Not to mention, the web app has shiny new e2e encryption now getting a security audit...
I encourage everyone to try out riot.im -- it makes IRC modern, useful, and fun again, and it doesn't move the conversation into a closed silo.
Comment #126
freelockP.S. Oh yes, Riot.im does have emoji...
But using them breaks Druplicon!
Comment #127
willwh CreditAttribution: willwh at North Studio commentedThanks freelock, I hadn't seen riot.im before :)
I've been using this for a while as my self-hosted IRC: https://github.com/thelounge/lounge, although I couldn't live without database logging, so I made a PR; https://github.com/thelounge/lounge/pull/506. I really can't say good bye to IRC completely, it has been a part of my life for such a long time!
Comment #128
freelockwillwh: I just checked out the Lounge demo, and I think you'd really like Matrix/Riot... the web client has a similar layout, but adds rich text/markdown, drag-and-drop images, a files tab, automatic pastebin across the IRC bridge, searchable history, all of your visible history available on any device, and even voice/video calling. All without disrupting the existing IRC channel. And you can join any channel on Freenode, Mozilla, OFTC, Snoonet, with more networks getting bridged regularly...
Comment #129
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedAnother feature that Slack is missing which might be important to some people when we're talking about freely accessible chat channels is being able to ignore users.
Unfortunately there seems to be some fragmentation occurring now even with no decision made to officially move as some Drupal Slack teams have popped up:
https://www.drupal.org/node/2798167
Comment #130
NWOM CreditAttribution: NWOM commented+1 for Discord. Even though this thread has concluded with IRC being the chosen option to stick with, I hope that the decision is re-evaluated due to the fact that it will inevitably cause fragmentation.
Programs like Discord and Slack provide much more than IRC offers these days. It also allows potential collaboration, and even job opportunities.
The best example is #drupal-support. A person that has a drupal site would be able click an invite link, have it open in his browser, ask his support question, and then get invited to a call to discuss his problem. It would also allow a tighter integration of different rooms (drupal support, drupal development, etc).
I hope the decision is re-evaluated, at least as far as #drupal-support is concerned.
Comment #131
kevinquillen CreditAttribution: kevinquillen at Velir commentedSlack can and will change its business model to suit its needs eventually. I wouldn't expect the free tier to be so lax on "unlimited users" forever. That's my opinion on jumping to a platform no one can control. The pricing models are not cheap either. The issue is if you offloaded the entire community to Slack, and 2-3 years later Slack yanks the free tier or restricts it further, or even, Slack closes up shop. Now everyone is orphaned and has to migrate back to IRC.
Comment #132
webchickWell... then we get superior communication channels for 2-3 years, until which time we move to the same platform that everyone else adopts as the alternative. Oh well. :)
Comment #133
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedIt seems like Slack is not a great option unless some kind of special treatment is arranged anyway. As previously mentioned here, even right now the free tier of Slack has some serious limitations when considering it for a community the size of Drupal such as the 10,000 message limit for history. You might even get kicked out if they deem your usage too heavy duty as happened to the Reactiflux people for example. I understand their plans for nonprofits also have some issues even for communities much smaller than Drupal's.
Comment #134
kevinquillen CreditAttribution: kevinquillen at Velir commentedYep, that's what I was alluding to. "Unlimited free users" isn't really unlimited, just look at Reactiflux.
https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to...
Comment #135
klukacin CreditAttribution: klukacin at Websolutions Agency commentedI've just checked all above and more chat-like solutions found currently on web. One of priorities I have in my company is use open source where possible use saas open source solutions if available and that's because our main priority is Drupal development and if I lose resources to maintain my own servers for anything that's not Drupal and even more for anything that's not in like PHP world it's just waste of resources for me. And also we like and use feature/customisation right tools like JIRA (I still havent found alternative for that where I don't have to compromise and have all needed features).
Also I do like altruism like telegram has or, hm, if I remember correctly google has/had also ... but I had to dismiss google photos as they changed important feature like the way share works. So sometimes I have to use proprietary hardware and software (did you know there is almost no open source CPUs! that we can build community upon).
So I vote for rocket.chat!
One feature in development we need to add or support is IRC connector, but that shouldn't be a problem if community decides to go this route. Also testing/beta are advisable ;)
Comment #136
freelock@klukacin all your reasons apply to Matrix/Riot, as well. But the best part is, there's no migration work necessary, you can just go to https://matrix.to/#/#freenode_#drupal:matrix.org, use the Riot link, create an account and log in, and you're in #drupal. You can also join any other existing IRC chat on Freenode this way.
- open source server (Synapse)
- open source client (Riot Web, Riot Android, Riot IOS, Weechat, nachat, Quaternion, others)
- they offer saas hosting for us (free accounts on matrix.org server)
- looks like it has most (very) advanced apps for all platforms (markdown support, drag-and-drop file transfer, inline images, animated gifs, end-to-end encryption available, emoji picker, rich text editor, built-in duck-duck-go searching, unlimited history, history search, notification settings, email notifications, invite by email)
- looks nice
- have many features
For Matrix/Riot, there's a lot more:
- Matrix.org hosts the Freenode bridge for us, but that is open source too and anyone can run their own
- 100% compatible with current IRC rooms, automatically shortens long text and provides a link for IRC, automatically embeds links to uploaded files/images on IRC -- if you use Riot you get a much better UX but can work very well with users who choose to stay on IRC
- Servers are federated, meaning those who want to run their own can, and those who just want an account on Matrix.org can do that, and everybody can participate in the same room
- Matrix can also bridge to Slack rooms, and join conversations happening on different chat platforms
Rocketchat seems like a decent solution, but it's no comparison to Matrix for getting started. The best part is, you can use it today, nobody needs to make any decisions here -- just create an account and chat with everyone who is happy where they are!
Comment #137
ekes CreditAttribution: ekes as a volunteer commentedFor Matrix rooms - and they are now being made, and used, for Drupal. It makes sense to create them as Native Matrix rooms and then bridge them to IRC or/and where ever else it might be desired. You do then need the permission of someone with Ops for this however (unlike direct #freenode_#room channels).
This way you can add Matrix room administrators, unlike straight bridges to IRC. This means you can decide about how public they are, and how much logs people see and so forth.
So you can make a room accessible even for users who have not registered an account. Much more newbie friendly (more newbie friendly than all the Slack invite requirements). I believe the Portuguese channel https://riot.im/app/#/room/#drupalportugal:matrix.org (also world readable) ; and the Dutch language channel https://riot.im/app/#/room/#drupal-nl:matrix.org are both example that are native and you can just click to join. [There is also a general test channel world readable and non-registered public https://riot.im/app/#/room/#test:matrix.org if you want to look.]
Comment #138
markhalliwellI've been following this for a while, but haven't yet commented.
Sadly, there are already several different ways this can happen and, quite frankly, it's starting to get really.... really annoying.
Do I use IRC, Slack, twitter, d.o contact form/email, issue comment... now something new discussed here???
Do we move to another 3rd party solution that may not have all the features we need/want?
---
I do think moving to a 3rd party solution is a bad idea, even if it's open source; primarily for the fact of reliance (and for the other various reasons stated above).
Not to mention that it will never fully encompass our community's needs, wants or unique use cases.
This is very similar to the "Abandon issue queues and move to GitHub" discussion that we've had before.
---
Yes IRC is ancient. No one is disputing that fact.
It is, however, just a protocol.
I think people are forgetting that how users connect to it and what client the user decides to use is, entirely up to them.
That being said, I think moving to any platform that forces a user to use their "client" is a very bad idea.
---
Ever since I took over Dreditor, I had a radical idea that I never quite made public: providing per issue chat "rooms".
Originally, I had looked into somehow connecting to the IRC channels and even dynamically creating Drupal specific "rooms", that could be used.
However, that would really put a load on any server and could be considered "spam".
So I started looking into other solutions, mainly WebRTC (which I believe is IRC's successor).
It's already implemented in over half of all major browsers and it's success is quickly growing.
---
The reality is that we often work on issues where it would be nice to collaborate in realtime on specific issues.
What if we didn't actually have to "host" a chat server and instead utilize PTP (browser to browser)?
What if we could integrate it with and on the site all of use on a daily basis?
What if we could know when people are viewing the same issue just by seeing who's in the issue's chat "room"?
What if we didn't have to "onboard" new people into using new ways of communicating by downloading apps or signing up for 3rd party services?
What if it was just there, on drupal.org, when users logged in?
Wouldn't it be nice?
---
I know this is a different approach and still a relatively new concept, however I really think it's worth considering.
And I'd even be willing to help spearhead the initiative.
Comment #139
freelock@markcarver
This is a big reason I'm a proponent of Matrix -- we're not reliant on a 3rd party. I host my own Matrix server, and am using it to participate in #drupal, #drupal-commerce, #drupal-migrate, and others. I am using the Matrix.org bridge, but if that goes away another can be set up. Anybody else can join there via Matrix.org, or their own Matrix server. Drupal.org could run a Matrix server, too.
Completely agree! While I'm evangelizing for Matrix here, I'm communicating with people on IRC using it today -- and they're on their usual IRC clients. There are several different Matrix clients to choose from, but with bridges, Matrix connects the silos and lets people use whatever they want. Matrix does bridge to Slack and Gitter as well as IRC, and there are experimental bridges to Telegram, XMPP, Facebook Messenger, and others.
Please don't go bottle up conversations in Slack. Riot (a Matrix client) is not far behind Slack in terms of usability and features, but far more open and not reliant on a single host.
Now this is interesting... I don't think WebRTC by itself is a solution -- as far as I'm aware it's a transport for media. Matrix uses it for voice, video, and screensharing already -- but primarily peer-to-peer only works between two peers. For multiple peers, you need a server to "mix" the channels together so that everybody can participate.
But embedding a chat room per issue would be a very interesting solution. And (yet another) benefit of Matrix is that is can preserve history, make the entire chat visible to participants, as well as provide guest access. A chat room per issue could certainly be done -- embeddable Matrix chat rooms are on the roadmap for the matrix-react-sdk, possibly even as a GSOC project. And I've already started a Matrix API module...
Comment #140
markhalliwellWebRTC has RTCDataChannel, which allows for textual communication (i.e. chat).
A server isn't really needed for "mixing channels", no. The only server that is needed is STUN/TURN to setup the initial P2P signaling. Once a user has established a P2P connection with someone, the messages are broadcast by the person sending them. The "mixing" would happen (relatively) seamlessly in JS on the client side.
As far as "chat history" goes, I was imagining that we'd have a button or something that just posts to the issue itself (could even be automated at some point). No need to setup a whole new database and continue the discussion fragmentation we already have around issues.
---
However, the more I read up on Matrix, the more it sounds like it's just a superset of WebRTC with some extra flavor (which I'm fine with... same principle really).
Considering that there are native client SDKs for nearly everything, including JavaScript, I'm definitely inclined to perhaps pursue this route more.
First and foremost, I was imagining creating a d.o specific implementation.
People shouldn't have to worry about downloading, installing, signing up or paying for another service.
After that, another exciting prospect that can be accomplished with the above JS SDK is the ability to create a dedicated/native desktop application using Electron (supports all three major OS: Windows, Mac and Linux) and is actually what Slack uses to build its desktop app.
This would, essentially, allow us to just reuse the code already deployed on d.o but just wrapped in a "native" app.
Using a module/drupal interface for this kind of UI will be really challenging. I think our best bet would be a Node.js/react app that can be browserified/rendered on the site, kind of like what I'm doing with #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features.
Comment #141
freelock@markcarver Yes, it's a pretty great platform... we use a Matrix chat bot we've written to handle deployment of all our Drupal sites, among other things...
Node.js/react is definitely the approach I'm taking -- node.js for bots, and React for embedding a chat component on the page. I think the main challenge of implementing something like this in Drupal is getting anything from the chat back into Drupal -- given that long-running PHP processes is not typical of most hosting. But there is another alternative -- the "application service" API for Matrix is capable of sending notices to an external API. So we could set up an app-service and have it receive messages from Matrix to handle as it sees fit. That's not something I've done yet, but there are a growing number of bridges that use this API, and aside from needing a Matrix homeserver that gives permission to the application server (Drupal) -- I don't think it's particularly difficult to use.
So... I would think the main thing to do is design what the UX might look like, and that might suggest whether it's better to have a simple node.js bot to send updates to Drupal, or create a Drupal/Matrix app service that's more direct... or keep the actual "integration" much simpler, with nothing sent back to Drupal, just a standardized room creation mechanism using React... (if we don't need to get data back into Drupal.org, I don't even think we'd need a Node.js component, aside from bot-type behavior).
Cheers,
John
Comment #142
markhalliwellWhich is why this related issue is so important. If we could open up d.o's API, it would allow us to more easily integrate via a simple JS AJAX call to a specific/dedicated endpoint.
I think before any "design" happens, we need to identify our community's use case (i.e. needs and wants). We can design something absolutely awesome but miss the mark entirely.
I think any "bot" would be a secondary goal and entirely separate issue. The primary purpose of this issue is to evaluate an alternative to IRC (i.e. real time community communication). Thus, I believe any MVP would need to focus around that first.
The biggest misconception about Node.js is that it's only meant for "tools" or "automation". It's just a programming language. One that allows for easier portability between server and client side implementations.
Comment #143
realityloopGitlab just acquired Gitter and plan to open source it by middle of the year, seem like it might be a good fit.
http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/
https://about.gitlab.com/2017/03/15/gitter-acquisition/
https://news.ycombinator.com/item?id=13877156
Comment #144
dqdA maybe noteworthy hard debate about Matrix (much critics), just to bookmark it here for further reading. Mainly about Matrix's own view against XMPP in the beginning. Note: my intension is not to take down Matrix in this discussion here with this, nor to push it. I just read and investigate, so also about Matrix's ups and downs, and have no fixed opinion yet about it (lack of time).
Comment #145
freelockThe Matrix devs came from the SIP world, and had a lot of XMPP dev experience before getting frustrated by the lack of any consistent set of XEPs that could be relied upon to be implemented. And... in my experience, it's a vast improvement.
We ran XMPP servers for years for internal chat. We had a Jenkins integration, and always wanted to do more -- but we never federated, and there was enough of a learning curve we never got much more integrated with it.
More importantly, a crappy UX killed XMPP for us. Matrix, being much more like Slack, makes it really easy to have a room per project, invite whoever should be associated with that project, and easily find everything. Having synchronized history across devices, comprehensive search within a room (for its entire history, unlike the 10K limit of Slack) and IRC support as well clinched it for us. Having a bot available the first weekend that would provide a login link to every Drupal site we manage on demand made it instantly adopted by our entire team.
For us, Matrix is like an IRC bouncer that makes IRC much more like Slack... except completely free and open. No open source project should tie its main communications to a closed, proprietary silo... especially one that seems to be hostile to open source...
Comment #146
dqdThanks for your infos and insides about this, freelock. Much appreciated here.
Comment #147
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedCurrently I have a working experiment that bridges the following services:
- Slack
- Riot.im / Matrix.org
- Gitter
- Telegram
- IRC
I'm doing experiments with some drupal and docker channels and private servers that I won't mention here, reasoning privacy and security issues.
The workflow is currently this:
Slack <-> Riot.im/Matrix.org via Slack's ingoing and outgoing webhooks apps
Gitter.im <-> Riot.im/Matrix.org via Riot's Gitter integration
IRC chat.freenode.net <-> Riot.im/Matrix.org via Riot's IRC integration
IRC chat.freenode.net <-> Telegram via FruitieX/teleirc bot at a personal private server
I'm hoping to improve this process with additional software, and also provide support for RocketChat. Currently it's a very manual process and requires admin intervention, channel by channel.
Let me know how I can assist.
PS: we have implemented a IRC <-> Telegram bridge for #drupaldevdays that had mixed reactions (technical vs attendee chat) and has been turned off. A proper implementation has to consider the channel audience/target.
Comment #148
geerlingguy CreditAttribution: geerlingguy commentedIt's interesting (since nothing has been officially changed) to note that the IRC channels seem to be shedding many, if not most, conversations outside of support-related things. I've noticed the trend for the past few months, but the more recent drama in the community (which also resulted in our long time bot, the Druplicon, being banned—see #2863181: Druplicon's purpose changed - block it as we consider purpose/use of irc bot in the future) seems to be accelerating the shift to the drupal.slack.com Slack usage.
Ideally, I'd like to use IRC or some other more open protocol. But I'm also a pragmatist, and it seems like a lot of the relevant conversation and community members are either both in IRC and Slack, or exclusively in Slack now :/
Comment #149
ekes CreditAttribution: ekes as a volunteer commentedI'll note it's certainly not all. I'm in 3 Drupal irc channels that are active. Two of which don't yet have one of the close alternatives yet.
I've experimented with bridging some of the channels slack<->matrix<->irc. The cultures between slack and irc and can vary and jar - not necessarily but expectations about messages are different. The difference between matrix and slack however is minor.
So as matrix can offer an open source (and open click-url and see chat, through to full registration and invite) option even for the slack channels. I'd say we could start bridging some of those slack channels to matrix. Who's the admin of drupal.slack? (bridging channels requires adding api hooks). Some of these could even be bridged back into irc, but I take that step a little more carefully.
Comment #150
fuzzy76 CreditAttribution: fuzzy76 commentedA proprietary network run by a company *known* to throw out open source projects if they become too large? That's a terrible idea if I ever heard one. :-/ Not to mention their terrible UX involving signing separately into each Slack you want to participate in.
Comment #151
ricardoamaro CreditAttribution: ricardoamaro as a volunteer commentedI've been watching this thread for a while and it seems to me that what people are requesting from IRC is that it should have more automation, a common UI and still be able to accomplish what it has been doing for us all these years.
It seems to me that what we need is:
- to apply a better integration using an opensource chat solution on top of IRC . Freenode already has one https://webchat.freenode.net/
- have our Infra folks bring in a modernized and opensource version of our bot https://drupal.org/project/bot
There are several choices out there already mentioned in this thread, but for sure we need to keep ourselves Independently using FreeSoftware and not using some closed solution leaving ourselves out of options in case we are "thrown out".
Using FreeSoftware solutions everyone can still contribute to improve a bot, a webui or an integration, leaving the job of administrating these to the D.A. and volunteers.
Comment #152
geerlingguy CreditAttribution: geerlingguy commentedSo, thinking further on Slack... based on some things I learned from discussions there
apparently there are that many across all the #drupal-* IRC channelsthis stat may be incorrect)This doesn't sound sustainable to me, for so many reasons.
Comment #153
NWOM CreditAttribution: NWOM commentedDiscord doesn't have any of those three downsides (no user cut off, no charge, no message cut off). If we're potentially looking into closed source solutions (like slack), then maybe further investigation into Discord would be beneficial in the interim. There are plenty of groups that I idle in that have over 50,000 users, and also others that have IRC bot integration (from and to).
Comment #154
frobLet's not forget that slack is not, and has no plans to, start supporting open source communities. In order to lower the barrier to entry we would have to use some equivalent to the heroku app for user registration.
Can the idea of switching to slack please be put to bed? It is only more convenient if you work at an organization that uses it for internal communication. If not, then it is one more thing to keep open.
Comment #155
kevinquillen CreditAttribution: kevinquillen at Velir commentedSlack can also change the rules at any time - and as mentioned before, they did to other communities. Plus, for better security, logging, and policy enforcement, you have to go above the normal price tier and look at higher options. It is costly.
Don't get me wrong, I like Slack, it works for our company, but I don't see it working at scale or by cost.
Comment #156
freelockEverybody in the past few posts seems to be arguing for Matrix over Slack, at least by their arguments for open source, non-restrictive alternatives. Why are people continuing to use it?
Regardless, I agree with @eke above, let's get whoever is an admin on the current Slack groups to assist setting up Matrix bridges. Then people can continue to use Slack if they really insist -- but the rest of us can participate via Matrix.
Comment #157
ivaat CreditAttribution: ivaat as a volunteer commentedHi!
I do think that IRC is 1# one good place for people to come and ask questions. It will never go out. All other platvorms are not independent. Did check slack out. More for team work and free one seems to process data as well. Don't know about that privacy at end.
Perhaps solution is simple:
For crossposting minimalation link #drupal-support to #drupal + make #drupal-social active (add topic). for #drupal-social can be slack linked as well. There several softwares out ther what enable slack to irc. for #drupal-social that could be solution in terms of getting more people involved
Comment #158
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@ekes
About Drupal Slack
#2864161: Change Drupal Slack allowed/installed apps
That said, like many people here and in other technology circles, I'm feeling much more confident with Matrix.org and RocketChat, both open source, than with Slack.
Matrix.org
open source, multiple official and contributed clients and servers
self-hosted and available as free unlimited service
https://matrix.org/docs/projects/try-matrix-now.html
RocketChat
open source, official client and server
self-hosted and available as free service upon request
https://rocket.chat/download
Comment #159
shrop CreditAttribution: shrop at Mediacurrent commentedIs it possible to consider sticking with IRC and hosting a web IRC solution like https://webchat.freenode.net? The web IRC solution could be setup to make it easy to drop into #drupal-support. I experimented with Slack for a Drupal distro over the past year and we moved back to IRC. We found that many novice users had issues with Slack if they didn't use Slack elsewhere. Our team decided we would be ready to assist novices get going with IRC.
Thanks for your patience if that has already been recommended. This is quite a long thread.
Comment #160
heddnWhy can't we decide that we stick with IRC and let any and everyone bridge it to any and every technology on the planet? If you want to setup a bridge Slack. Good, go for it. If you prefer carrier pigeon, have fun. Has anyone else said anything about actually *replacing* IRC with something else, or just supplementing IRC with bridges for the past 159 comments?
RE: #159 there are already solutions that do that. See consensus around #50-#68.
Right now, this issue is essentially a venting board or bragging place for 1) why they hate IRC or 2) what technologies they were able to bridge into IRC.
Let's just accept it. IRC is here to stay. Long live IRC.
Comment #161
shrop CreditAttribution: shrop at Mediacurrent commented@heddn: Good deal! Thanks for the details. I am for keeping IRC and addressing specific improvements. May be time to break out specific improvements into separate issues.
Comment #162
frobI am also for keeping IRC. If we want to spend some of our precious infrastructure time (not sarcastic, infrastructure time is precious) we should do it on either an upgraded alternative to the web IRC client, https://webchat.freenode.net with another cheaper option would be to just promote the freenode webchat client more.
Comment #163
ricardoamaro CreditAttribution: ricardoamaro as a volunteer commentedSince i'm the Drupal group contact with freenode I would love to see some comments on the 2 proposals above at #151 in order to move ahead with some real outcomes from this thread, since people are a bit dispersed right now.
Comment #164
shrop CreditAttribution: shrop at Mediacurrent commented@ricardoamaro, I am supportive of both ideas on #151. Think starting two issues for these is the next step?
Comment #165
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedI think building upon IRC would be a good idea but I have some concerns about the split just staying in place when lots of people seem to already have migrated off freenode to the Drupal Slack.
Comment #166
ricardoamaro CreditAttribution: ricardoamaro as a volunteer commented@shrop yes, i think creating action items based on this discussion would be a good starting point. Today i went to slack and there is a huge crowd over there. Would be great to have everyone's constructive ideas and contributions based on IRC, since that's the general take of this thread.
Reading again the above i think #77 is a good solution for the first point.
And they have apps available for mobile
iOS: https://itunes.apple.com/app/irccloud/id672699103
Android: https://play.google.com/store/apps/details?id=com.irccloud.android
#drupal
#drupal-contribute
#drupal-support
Comment #167
fuzzy76 CreditAttribution: fuzzy76 commentedI think a lot of the comments the last couple of days come from people that haven't read this entire thread yet, as most of these aspects have been discussed already. One major pain point with IRC is that you can't read previous history unless you are a) connected 24/7 or b) run a bouncer (proxy) on your own server. This is not ideal, and is a problem solved on every other possibility out there (Slack, Matrix, XMPP, Discord, Mattermost, Gitter, etc.).
Comment #168
ricardoamaro CreditAttribution: ricardoamaro as a volunteer commentedComment #169
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commentedCreated: https://www.drupal.org/node/2864658 - "Modernize the IRC Drupalbot"
Comment #170
geerlingguy CreditAttribution: geerlingguy commented@fuzzy76 - note that unless we pay vast sums of money, Slack only allows access to the past 10k messages. With the flurry of activity this week, that means most of the channels on Slack have zero history anymore because other more popular channels have pushed past the 10k limit and do so on a daily basis.
Comment #171
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commented@fuzzy76: That one's not that difficult to solve with an IRC bot though. Admittedly the interface isn't quite as nice but it definitely works. In fact the Drupal IRC channels could have had that with Druplicon but a deliberate decision had been made to turn the logs off for most channels.
Comment #172
kevinquillen CreditAttribution: kevinquillen at Velir commented@geerlingguy plus, I think if it were the new 'official' chat channel for drupal.org, people would want SSO so there is solidarity between their Slack account and drupal.org account. You don't get that unless you pay $12.50 per user per month instead of $6.67.
Comment #173
fuzzy76 CreditAttribution: fuzzy76 commented@geerlingguy As I stated earlier, there are a lot of things wrong with Slack. My comment was not an endorsement for that particular service.
@antti that is not solving the problem, that is duct-taping a hack. Sort of like mirroring two mediums (or channels) through a bot also is. (Or using a cvs-era patch-based workflow on top of git, but let's not digress too far).
Comment #174
frob@fuzzy76, no it is not a hack or duct-tape solution. IRC is a chat protocol that we can build our own clients around. Every chat system is based on very similar protocols.
While I would be lying if I said that I read every word of every comment. I did skim through it all and I read anything that was replied or mentioned. The general consensus is that there is no consensus. The is no perfect solution and thus in order to get this issue marked as fixed. It seems like the best solution is what was most recently suggested.
- updated or better promoted IRC web client
- opt in logging
- modernization of chatbot #2864658
Comment #175
frobI did some organizing of the is, alphabetized (somewhat) the irc foss users. Assed wordpress to the irc users because they have not stopped using irc for support and are only using slack for wordpress contribution.
Comment #176
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commented@fuzzy76: I wouldn't go as far as calling it duct-taping a hack but I admit it's far from the ideal UI for such a thing. Some kind of a multi-user bouncer setup for everyone would be the better solution to build just on top of IRC but also much more difficult to implement.
@frob: How would opt-in logging work? everyone can set if their comments appear in the public logs and for those that don't want to the logs will just have lines that indicate someone said something? If so, interesting idea... has it been used somewhere previously?
https://www.drupal.org/slack currently lists 8 different Slack teams. I'd love it if things could be at least slightly less fragmented and for that I think there would need to be something more appealing than just an improved bot and promotion of the webchat. Whether the best choice would be one of the fully free/open source solutions or something like IRCCloud I don't know. IRCCloud does have the advantage of probably being the easiest to get up and running and even if it's not an entirely open-source self-hostable solution, it's just an addon.
Comment #177
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedConvos is Another potentially interesting option that works in a way similar to IRCCloud in that it's just added on top of IRC but is F/OSS and has to be self-hosted. Looks like it's in active development. Added it to the list.
Comment #178
frob@antti I haven't thought too far into opt-in chat logs, but what you said is the basic idea. I just thought of it while I was typing, and I should have brought it up in a comment first. Now that the DA is managing the bot this kind of thing is technically possible.
I expect there is more than 8 drupal channels on slack. It seems like we are hemorrhaging users from IRC to slack. This is a very bad thing and one of the reasons I want to get this issue resolved. Slack is not designed for harboring open source communities. This is why they have such a steep pay-scale. Everything about slack is designed around corporate team communication. I am not saying that we need to stay on IRC because IRC is the way we have always done it. But all the benefits (listed below) of IRC vs the two benefits of Slack for open source really makes the decision (to me) an obvious one.
Arguments in favour of IRC
Other open source projects still using IRC besides Drupal
Arguments in favour of Slack
Even wordpress which uses Slack for core development, doesn't endorse the use of slack for general support.
I am attacking the idea of using slack because it is where people are going, not because it is the proposed solution. Many of the other open source solutions also have merit.
I have not seen Convos before, looks interesting. I expect running anything like Convos would have to also get approval from freenode.
I apologize for the rant.
Comment #179
realityloopI think the biggest risk, which we are already seeing is fragmentation.
I vote for something open source (looks like Matrix is the frontrunner here to me).
Anyone using multiples of different messaging systems should also check out: http://meetfranz.com/
And the plugin repository: https://github.com/meetfranz/plugins
Seems like it wouldn't be too difficult to make a plugin for one of the web based Matrix clients.
Comment #180
frob@realityloop, I dunno. From everything that I read about Matrix in this thread, Matrix doesn't sound like an IRC replacement. From what I have seen in this thread there is no IRC replacement. All talk has been of using Matrix as an IRC bridge, which plenty of people seem to be doing. Using IRCCloud isn't replacing IRC either.
I'm going to put my neck out there and mark this as
RTBCNeeds work (I have updated the IS with things to do). We stick with IRC. Though a plan needs to be made to stop the migration of users out of the official support channels, or better define official support channels, I think this discussion is resolved.Comment #181
frobComment #182
markhalliwellNo, that's just one way to use Matrix. Matrix is an open protocol, just like IRC, but built with newer technology, concepts and features.
It semi-mirrors what WebRTC is attempting to accomplish.
There are many different ways to use Matrix:
http://matrix.org/docs/projects/try-matrix-now.html
Obviously IRC cannot support the features we need.
That is why this issue exists and why people are trying find other mediums that do.
No it's not.
Comment #183
marcvangendThat sounds like saying "email cannot replace snail mail". Of course it's different, but given how many people are switching to slack already, I can only conclude that tools like Slack/Matrix are seen as replacement, and probably even an improvement.
This issue will only become "needs work" once we agree on a plan and start implementing it.
Comment #184
Antti J. Salminen CreditAttribution: Antti J. Salminen as a volunteer commentedSeems like what there's agreement about is that we can't stick with just IRC and that while features that Slack offers are desirable, it isn't really an option.
Also seems like there's support for having IRC still be around as more than just a gateway you can connect through (so not Slack-style). That makes sense to me also because it would mean not asking the existing userbase to move to yet another platform. Many would also prefer a solution based on free/open source software.
Matrix and Convos look to be options that would tick all these boxes. IRCCloud gets close, but if there is a fully free/open source software solution that would be preferable.
Matrix being even able to bridge Slack in addition to IRC would certainly help adoption and it could be offered as the official solution. If it has the major pain points covered and works reliably I support choosing it too.
Comment #185
larsdesigns CreditAttribution: larsdesigns as a volunteer and commentedI second the statements and opinions of @greggles.
I can add that IRC is the most inclusive chat system for our community and when provided by freenode it supports the nature, culture and values of Drupal as an open source software community.
An area we can work on is to create easier access to IRC. Perhaps providing recommendations for IRC client software, and improving the instructions for getting started.
Comment #186
frobThis issue is confused and will go nowhere if we do not focus. Lets get a list of requirements since this has primarily been a scatter shot of suggestions thus far. These are the requirements thus far:
Requirements for chat system
This isn't an agreement, this is an argument. There is just as much of an agreement that IRC is the best solution at this time. There is nothing wrong with IRC as a protocol and it can do all the things that we have listed as requirements. In fact, it does them all right now.
There was a hiccup with the switch to Drupalbot, many #drupal rooms are logged by the bot and are searchable. A new site for the new Drupalbot is in the works.
freenode hosts our IRC channels
We have a list of "problems with IRC", but we need to update the Issue Summary to convert this into a useful issue where we can actually gather options and evaluate them without becoming a pro/anti-IRC/SLACK/CHATSERVICE issue. If it isn't done by the time I circle back here then I will attempt to rewrite/focus the IS by the end of the week. In the mean time I will add two requirements.
Open source
Drupal is an open source project and it should be important that we embrace open standards and open source. It can be argued, and I would agree, that this might be more of a nice to have than a requirement, except that with the mass of open source chat systems out there I believe we can find one that is best-in-class.
Not an island for Drupal
I am thankful that we have not seen a "lets just roll our own" solution for this mentioned, but I still think we need to be clear about this. If we move somewhere it shouldn't be a place that only Drupal exists. A self-hosted web client isn't a bad idea, but those of us who are involved in more than a single open source project shouldn't be required to keep an app running just for "Drupal Chat."
Comment #187
Antti J. Salminen CreditAttribution: Antti J. Salminen commented@larsdesigns I mostly agree but there are two things that lead me to believe that better documentation would not be enough. First, I think it is a good observation that there is an issue with the usability of IRC compared to Slack caused by the lack of a nice web-based interface and the barrier of entry having to install a (better) native client creates. Freenode webchat exists but it feels very dated and not something even I would like to keep using as the way to get to IRC while Slack's web interface is good enough for someone to do that. Secondly, at this point we also have to consider that a good number of people that have previously been perfectly capable of using IRC have already made the choice of moving their discussions to Slack so they seem to prefer something that it offers.
@frob:
You're right, I misspoke about there being agreement about just IRC being enough. What I was getting at and I'm hoping nobody would object to is adding optional functionality on top of IRC with Matrix or one of the other mentioned solutions that are able to do that.
Comment #188
markhalliwellNo. That's your opinion. It doesn't change the fact that IRC is severely outdated and lacks much needed features.
Um... no it doesn't. Which is why we have severely fragmented our community's communication in regards to which mediums/platforms are used.
I agree with with the open source, not so much the "Not an island" part. Yes, we'd have to create a "homeserver" for Matrix (see IS), but that's rather trivial.
---
@frob, I don't think you understand that Matrix allows us to "keep" aspects of IRC and would even allow us to bridge with IRC. Just because you are fine with IRC, doesn't mean the rest of us are. Please stop saying "that it's fine as is". It's clearly not.
---
I've updated the issue summary to be a little more concise with what has been discussed above.
Comment #189
markhalliwellMinor formatting
Comment #190
frob@Antti: sorry, I misunderstood what you wrote as to mean that we need to replace IRC with some other solution. I am all in favor of attaching more tech to our freenode hosted IRC.
IRC is old and that is a bonus, not a failure. It has been around for along time and it has continued to evolve to suite its use-case. We are talking about chat protocols and it is important to not throw the baby out with the bathwater just because chat protocols have seen a resurgence in recent years. The abundunce of options doesn't make our current choice any more or less useful.
We need to focus on features and not get bogged down on implementation. That has been a real confusing part of this issue. Everyone is looking to solve the problem and everyone is moving in a different directions. We need to know what direction to move before we begin working on an implementation. We have a list of IRC complaints, that part is done. Now we need an absolute list of required features. The list has been started in the IS.
@markcarver, thank you for focusing the IS.
I added gitter as a proposed option, and moved webrtc and "user is typing" indicator out of requirements and I doubt either is deal breaking.
Comment #191
frobDoes anyone know where this paragraph came from. It doesn't really make a whole lot of sense but it sounds like a quote. We need this paragraph cut or fixed. I don't know what it is supposed to say.
Comment #192
heddnI think that was a quote from the Drupalcon core conversation that launched this issue.
Comment #193
markhalliwell@frob, typing indicator and RTC (audio/video) aren't "nice to haves". They are a requirement. These are features that don't exist and force people go to other mediums that do have them. These are probably the biggest reasons for our current community communication fragmentation.
I think you're confusing what some people won't use or don't care about vs. what some people need (and why this issue exists).
Please stop trying to belittle this issue.
I also took out the verbiage about the Druplicon. Current implementations doesn't change the fact that bots aren't really a native part of IRC and require a manual and separate persistent instance/connection to be maintained.
Comment #194
pwaterz CreditAttribution: pwaterz commentedI think it's time to just pick one and go with it, and adjust our approach when it's needed. So much time is being wasted on arguing one chat client for another. I think HipChat and Slack have been vetted by the tech community as being good choices in this space. The company I work for went through this same process about two years ago, and we chose HipChat because it was more robust than Slack at the time. I think they both offer similar features, and someone with authority in the Drupal community needs to just pull the trigger. The longer it takes to make the decision the more productivity is lost in entire Drupal eco system. Does anyone think it would be a good idea to create a survey monkey survey to allow us all to cast our vote?
Comment #195
markhalliwellYes, for small to medium sized business/teams. Not for a full blown community like Drupal.
I've updated more of the cons in the Slack category.
Comment #196
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedIRC........
Can we quit arguing that IRC is outdated or not? It is. It's a fact.
However it does well a lot of things. And a lot of people like it and use it. And it's another drama if it ends.
Can we revise the topic description and title to something more friendly, like
This way it suits everyone (I think).
It's also been overwhelmingly repeated and discussed that Slack isn't what we need, for many reasons.
Some solutions are standing out for ease of use and no costs, other than the ones associated with bots:
Comment #197
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #198
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #199
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #200
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #201
frobComment #202
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedrecover lost edition
Comment #203
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #204
ivaat CreditAttribution: ivaat as a volunteer commented@lpalgarvio
don't know how irc sucks on mobile phone. depends what client is used. people who chat via irc have questions and it's more chat not tweets with short messages...
-----
this topic seems to be old and actually not a issue.
for #drupal, #drupal-support IRC using
for #drupal-social made suggestion to link for experiment slack with irc (software avaliable).
+ webchat and freenode has that already.
All other solutions seems to have purpose for this topic.
Perhaps summarise this by op?
Comment #205
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@ivaat
What I mean by sucking on mobile is the experience you get with each connection that is interrupted.
It's highly disruptive, distracting and annoying to get spammed with jargon when using regular IRC clients.
Which can happen multiple times a day, considering things like, switching between WiFi and 4G, going in the metro, passing through a tunnel, going downstairs on a steel reinforced concrete part of the building, weather issues, and so on.
Comment #206
freelockNice changes to the issue summary!
I would think that #3 should satisfy just about everybody (other than those who can't get over their Slack addiction...). There's no need for anybody to stop using IRC. We can just bridge all the IRC rooms into Matrix -- and this is already available/done as "portal rooms" -- anybody on Matrix can simply "/join #freenode_#drupal:matrix.org" to get into the main #drupal channel, and use the same pattern to join any other IRC room on Freenode. So there's not even any action necessary to have #3.
However, there are a couple improvements to suggest: with support from an Op in each channel, we can set up an official "plumbed" room, which would allow us to make the history available to anyone (if desired), and not just users since they joined the room.
And the other improvement? Add links/instructions to the appropriate community pages, send new people to the Matrix rooms (as well as IRC) and remove the Slack link. Encourage people to use Matrix or IRC, and not Slack.
Some other thoughts for longer term improvements:
If the DA would like more control over the channel names, I would recommend setting up a Synapse server on a drupal.org domain, which would allow for better aliases. If you use matrix.org to create the bridged plumbed rooms, you end up with room aliases like "#drupal-contribute:matrix.org" or with portal rooms, "#freenode_#drupal-contribute:matrix.org". Better would be "#contribute:drupal.org"
With a drupal.org "homeserver", we might also be able to auto-login Drupal users using their Drupal.org credentials. There's already an LDAP authentication system for Synapse -- I'm wondering how hard it might be to use Bakery or Saml to auto-provision/auto-login Matrix accounts based on DO accounts. Created #2867466: Provide Matrix provisioning/authentication system to track this feature request, at least on the Drupal side.
Cheers,
John
Comment #207
hestenetChiming in from the Drupal Association point of view:
I just wanted to say that we're following this conversation closely, and we do want to support the community in finding a good solution here.
We don't want to step in while consensus is still being built, but we do see several ideas coallescing:
And on the subject of 'something else' I do want to raise the point that there is an ongoing developer tools evaluation underway. And another update is likely to be posted to the community soon, laying out the short list of options:
All this is to say:
Comment #208
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented+++1 for the excellent plan detailed in #206 by @freelock.
more than anything I had given some thought before
Question remains, public matrix.org server (free) vs drupal.org server (has infrastructure costs but more control).
@hestenet
fantastic!
@Matrix.org vs Rocket.Chat to GitLab...
Matrix.org and GitLab integration:
https://github.com/matrix-org/go-neb/issues/127
https://gitlab.com/gitlab-org/gitlab-ce/issues/25634
https://forum.gitlab.com/t/matrix-interoperability/5570
Matrix.org and Hubot integration:
https://github.com/davidar/hubot-matrix
https://github.com/matrix-org/go-neb/issues/96
Rocket.Chat and GitLab integration:
https://rocket.chat/docs/administrator-guides/integrations/gitlab
Rocket.Chat and Hubot integration:
https://github.com/RocketChat/hubot-rocketchat
Matrix.org to Rocket.Chat:
https://github.com/matrix-org/matrix-appservice-rocketchat
Hubot can talk via 3rd party plugins/scripting to:
- GitLab
- Gitter
- IRC
- Mattermost
- Rocket.Chat
- Slack
- Telegram
https://hubot.github.com/docs/adapters/
There seems to exist more and more complete integrations for Matrix.org, however this needs to be tested.
https://github.com/matrix-org
Some stats from matrix.org free server:
- 7 drupal channels
- #debian channel bridged to #debian on irc.freenode.net with 500 users
- docker/docker channel bridged to gitter with 480 users
- linode channel bridged to irc with 280 users
etc
The free server currently provides working integration with:
- GitHub
- IRC
- Gitter
- RSS
- Slack
I've tried all these out in the portuguese drupal and the portuguese docker communities.
Twitter integration is broken on the free service and although there are integrations for GitLab and Telegram, they haven't included them yet in it.
Comment #209
ekes CreditAttribution: ekes as a volunteer commentedI can't see why the DA would set up a matrix server. They've not set up an IRC server.
As Matrix automatically federates a room when someone from another server joins it, this is this not so important?
https://riot.im/app/#/room/#drupal-nl:matrix.org is also https://webchat.weho.st/develop/#/room/#drupal-nl:chat.weho.st
If desired in the future you could have a chat.drupal.org that hosts an instance, but the chats could still be federated onto whichever other server.
In practical terms at the moment. Slack continues to grow. IRC continues to be used and be 'officially' supported. There is a real and existing disconnect between chat tools, and rooms. People are also starting to use Matrix.
I, and others, are already in Freenode IRC channels from different matrix servers. There are instances of native matrix channels too: #drupal-nl channel is native and then bridged into irc (and a slack channel).¹ I assume the Portuguese one is similar, and there may be others. These can be on one matrix instance, but you can join from your preferred one.
While some regional slack instances have been bridged to Matrix. The drupal.slack.com one hasn't yet. To bridge slack channels does require the operators to set two webhooks. The DA didn't - so far as I know - promote the drupal.slack.org; there was certainly no consensus for it. There's really no reason to wait on such things before making it accessible without invites and with open source tools.
* So there is nothing stopping publicising matrix rooms, bridged to irc, now.
* The only thing stopping people use open source software to chat to people in slack is they aren't bridged yet.
<footer>
¹ The difference for those interested is: in the first instance (IRC joined via Matrix) you don't end up with Ops on the room, the server sets everything. The second you get Ops, control permissions, but you need to get permission from the Op of the IRC channel to bridge.
Why might you want to do this? Well you could make the channel truly public for example. Like you can see the channel anonymously, just on a web page, without logging in! It's not the default, people need to know that people not in the room can see what's happening (a bit like the public bot logs, but even more integrated and obvious).
</footer>
Comment #210
fuzzy76 CreditAttribution: fuzzy76 commentedBecause Matrix does integrations, while IRC doesn't. You could connect user accounts to drupal.org directly, you could auto-generate rooms for projects, you could push commit-messages to said rooms, etc.
Comment #211
frobThere is also no need to setup an IRC server, freenode is the place for that. There is no benefit to setting up and self hosting an IRC server for an open source project.
I am really glad to see the refinement in the IS. We now have a list of requirements and some suitable options for reaching those goals.
@markcarver I am not trying to belittle this issue, I think that stopping further fragmentation of the drupal community is one of the most important things that needs to be done. That is one of the reasons I was trying to get people to stop complaining about IRC or Slack and stop bragging about their home-grown IRC bridge solutions and come up with some requirements. We have now done that.
I still consider the "someone is typing" indicator a nice-to-have feature, because in a room with 100+ people it can just cause noise or stop someone from typing at all while they wait for their chance to be heard.
I still consider RTC a nice to have because I have only once in near 10 years of doing Drupal needed to get on a call with someone and that was for a local dug meetup and not for community support. It would be nice to have it supported by whatever we use, but I can just as easily use any dozen video chat services for that.
It will be interesting to see the outcome of https://www.drupal.org/drupalorg/blog/technical-advisory-committee-forme... and if it causes anything in our list to change. One thing to note about gitter:
This is no longer true with gitter. The whole system seems to be built around rooms per project. I would also add, minimal required maintenance and minimal custom development required as requirements to switching as well. Of course, this begs the question what "minimal" means, but that is up to the DA that will be maintaining this new chat system.
Comment #212
wturrell CreditAttribution: wturrell commentedFirst, please read the additions I've just made to the issue summary (includes a few non platform-specific points)
My TL;DR would be: whatever we choose, please can we keep things as simple as possible, minimising noise, clutter and cognitive load?
FWIW I can speak highly of the web and iPhone version of IRCCloud (note I'm on a free account, but sleeping my Mac Mini at night still seems to magically hold the session open and avoid the 2-hour timeout). It's reliable and gets out of the way – with it in a pinned tab, I can go ages without being distracted by it at all, yet I'll still see notifications straight away. For me the biggest feature isn't scrollback, but the ability to turn off "Show nick changes, joins and parts" – people waste huge amounts of time re-reading these every time they check a chat window (even the condensed equivalent on Slack).
I appreciate IRC for it's plain text feel, especially the lack of Emoji - I think simple emoticons like :) and :( communicate a range of feelings (also useful: words). I honestly find icons, avatars, animations, etc. a huge distraction when reading through a transcript because they appear more important than the surrounding text. Similarly, my gripe with auto-embeds, such as those in Slack, is that they take up a large amount of real-estate disproportionate to their importance in the conversation (and the excerpt that's embedded isn't necessarily the bit you want to read). I'd want the ability to disable or compact them. Note a benefit of Drupalbot's node summaries is they are all on a single line.
I'm not sure how important integrated audio/video chat should be - I'd suspect most of the time people prefer to take time to think about what they say and then type it.... When we do have meetings, is there any real problem with using Google Hangout etc? I wouldn't want people forced into using video chat, it's important all participants still have an audio option. Also: make it easy to mute microphone, see yours/others connection quality to help diagnose problems.
Clearly a single chat system is preferable (I have sympathy for anyone who is currently has to straddle both IRC and Slack) - but I'm unconvinced what we choose it is will make any significant difference to the number of people who use/contribute to Drupal - people won't be put off just because we're using Chat Foo or Chat Bar.
Most activity takes place elsewhere (as @webchick once said: "issue queue or it didn't happen"). It's important for people not to feel out of the loop because they weren't participating in text chat/RTC, and it shouldn't be seen as a requirement to contributing to the project.
So I'd disagree with the premise that Drupal currently "lives" on IRC, where it really lives (and must) is drupal.org.
Comment #213
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@wturrell
Slack and Riot (matrix.org) do support voice and video calls with webRTC.
I've tested these in the past and these functionalities are documented.
Speaking of voice and video chat, in Slack voice and video calls are for pay in channels.
For chat between two people they are provided for free.
I'm finding very difficult to accept the arguments you've made, so I've made new corrections to the issue summary.
Comment #214
frobPlease lets not argue and post counter-points inline in the IS. I combed through it and removed some duplication and extra information.
Currently I think our issue summary shows clearly what the problems are and what we would like in an IRC replacement. Lets see what happens from the news in comment #207 and maybe adjust our expectations accordingly.
Comment #215
wturrell CreditAttribution: wturrell commented(written pre #214)
I primarily want to make the case for prioritising simplicity over feature set, and consider how what we choose could impact people's productivity (also, the fewer built-in features we insist on, the quicker we can implement something that does most of what we need).
I took care not to directly back any individual solution. It is, however, perfectly legitimate to include some positive views about IRC in the issue summary to provide balance - leaving a one-side section misleads those unfamiliar with the subject and annoys those who are. This list of "Concerns people have voiced about IRC" has evolved into a list of features (or lack of them) - I went back and listened to the 2015 discussion that sparked this issue; while technical stuff was mentioned, I interpreted it as being as much about the group of people who simply don't have enough time to be on any form of live chat or chose not to because they believe the stream of information is too overwhelming. Additionally, there were those who thought they might be missing out on important discussions, but still felt it wasn't worth the effort. Whatever we do we'll struggle to solve that.
I had written some longer replies to @lpalgarvio's comments but ultimately I also have spent too many hours on this issue today and would rather do something more productive than arguing for or against IRC, so briefly:
- I'd endorse quite a few of @frob's remarks, including most recently about "someone is typing" not necessarily being a positive thing, and that RTC isn't essential (I'm aware there's no formal Drupal policy on which platform, nor should there be imho, but the DA and the UX group use Hangouts for their regular meetings and the archival to YouTube provides transparency to the rest of the community without costing money).
- I disagree about integrated file-sharing, that nobody has mentioned it at all in the comments suggests it's demonstrably not a priority. People being in different places fragments a community, people sharing a link from Google Docs doesn't. Also not everyone needs (or wants) the links they share to be permanent (and indeed not everyone wants chat logs to be permanent actually), but those files we need to preserve already have a canonical location on Drupal.org - e.g. screenshots, patches and other work attached to items in the issue queue, policy documents, etc. Also, as I wrote earlier, I would resist the temptation to "embed all the things". Adding inline photos might sound nice, but wait until people start posting "amusing" animated GIFs in response to everything (I seem to remember in HipChat there was no way to turn those off…)
- I stand by what I said about IRC being simple compared to the Composer, Drush, Git and other CLI skills we expect people to learn (and the learning curve for Drupal itself) and I agree with @crell's comments in #112. All chat systems have a learning curve - as far as the initial setup process is concerned, I don't think there's that actually a huge amount to choose between any of them, given all can now be web-based. And as someone who's unfamiliar to matrix and bridging, that's just as daunting to me as IRC might be to someone else. As far as everyday use, well, I find Slack's UI very cluttered, even when I turn as much of it off/down as I can. Please let's try and consider there will be a subset of users who feel the same way (and that's why many may have stuck with IRC). Also, to start with, we need to try and get all our *existing* users in one place whilst annoying as few of them as possible, then we can figure out ways to encourage others to join.
Comment #216
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedGood comments above,
I'm not aware of all the possible configurations and customizations on many of the chat platforms.
Among them, being able or not to turn off "someone is typing" or uploads, possibly can if at all be turned off at server level only, and not per channel, as these options don't exist on Slack or Matrix, at least, with the free hosted services (perhaps different with self-hosted Matrix).
Animated gifs and all the extras are controlled via integrations/apps in Matrix and Slack at server and channel level, meaning, a server admin can approve / enable a set of integrations/apps, which in turn can be individually enabled per channel basis, by channel admins. I'm unaware if they can be force enabled for all channels.
Important to note, on Matrix, non-channel admins can't change a channel integrations, and channel admins don't need to be server admins.
In my view, webRTC is exactly essential, as we need to provide communities with a proper & functional way to communicate with voice and do conferences for the kind of events that require this (including but not limited to meetups, live conferences, public board meetings, etc). The world is dominated by closed source free/non free half-baked solutions that are generally not 100% synchronized or compatible with everybody's devices.
This is exactly what webRTC tries to fix, with the end goal that all these proprietary chat platforms (skype, hangouts, talk, duo, whatsapp, etc) that failed to adopt XMPP and evolve it in collaboration, which instead did fubar EEE tactics, switch over to this new set of standards. While I understand not everyone will want to use it, there is so much to gain from using it and allowing the communities to use it.
https://en.wikipedia.org/wiki/WebRTC
I can't give a precise indication about file sharing, regarding if files can and should persist forever, if they can be purged automatically after X time, or again, if they can be disabled. But having them creates new possibilities. Sending a file over a channel becomes more accessible than putting it over Google Drive or Dropbox and requiring a jump to another site and requiring (or not) a login in that same site.
All the complicated stuff about Matrix and Slack rests alone on server admins and channel admins, or on special features like device approval, with not many people will use and is optional. Everything is very much simple until you decide to create channels (Matrix does offer a lot of options on this).
In comparison with IRC, setting up channels properly (registered) is equally complex, but I find registering and configuring an account on a IRC server more complicated than on any of the other services described in this issue.
I tried first Matrix (with Riot client) and didn't found it over complicated. I did find Slack and Gitter overly simple, with limited functionality (at least on the free versions).
Cheers
Comment #217
MustangGB CreditAttribution: MustangGB commentedWe use Slack in our offices and it works fine for us, however in such a large community as Drupal is having less than a week worth of message history makes it completely useless.
Comment #218
dqdSorry that I didn't had and still don't have the time to read all comments here. It feels disrespectful but it isn't. This discussion is cluttered over several discussions actually and spread over a long time so that all the effort of people trying to explain their POV will be lost in the nirvana of this long scroll page. It's sad to see this but unavoidable.
Tell me if I am wrong, but something what is missing from my flying visits all over the spots was, that somebody with more insights has mentioned to compare what other developer groups have in process of planning and if there are maybe similar discussions going on, which we should link or embrace to take a look over.
Many of you will remember when the Drupal community got a hard and long discussion going on regarding its sometimes "isolated" position and solitary choices made apart from what's up around, and while I have to admit that I didn't understood every 100% concerns, I see the positive effect on Drupal 8 integrating with Symfony and Twig apart from code regarding community efforts. And while some old school Drupalianers maybe have mumbled against it at first place, many others have joined and communities have started to mix up and to automatically grow on both ends. It was refreshing. With some loss of course. But that's life. Something to watch all over many different situations in life and work. At least for me being long enough in a position to do so.
As a project and company lead I have spoken last week to some of our employees, the developers in the company, and stated that I more and more see a real issue rising in the huge fragmentation going on in Open Source development (look at Linux Distros and DEs) over the years. And while I am an Open Source advocate, I still look for improvements to consider all the time. And to rise this issue is such one, and important. The unremitting split of man power is a huge issue in Open Source and "libre" community driven development because of developers hubris not willing to merge or to think outside the box. Or even worse: to believe to be the only small group of people to know what is best to do and split/fork/reinvent/seperate from the others.
And that's why I would love to see more consensus here between large communities like Drupal with Symfony and Twig etc. regarding chat solutions. Like it was consensus with IRC back in the days. And that's what it made so available and improved (and maybe still is? Who knows). Please consider that improvement and availability has a strong relation to the consensus of many communities using it. As more consensus regarding this issue here with other developer communities will rise, the more future proof and less time consuming it will be to maintain.
That's why one of the most important marks which have been made here, was, that some solutions integrate well with IRC. I saw my eyebrows perking up in that moment. Simple as it is: Integrating is the opposite of separating.
Comment #219
betz CreditAttribution: betz commentedSorry if I missed it, but who manages the current slack account for the drupal rooms?
We would just want to create bridges, so everyone can use their favourite app/service and be happy.
:)
Comment #220
betz CreditAttribution: betz commentedJust want to link to another issue at #2885060: Drupal Chat Bridges IRC <-> Matrix <-> Slack
Made an overview of most channels, on irc and slack side.
We also started most matrix rooms on matrix.org (linked from above issue).
Comment #221
freelockbetz++
Comment #222
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #223
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@betz #2864161: Change Drupal Slack allowed/installed apps
Comment #224
dqdbetz++
Comment #225
webchickWhile I'm pro-Slack from a "reduce the barriers to entry for contributors" POV, here's an interesting counter-argument. :)
Last week, someone purporting to be drupal.org user @marvil07 started an online petition on change.org. Originally, this petition's title and body text were about supporting Megan and Dries in light of recent community controversy. After amassing 40-odd signatures, the owner of the petition switched to the malicious twitter account that's been harassing community members, and the title/text was changed to the opposite: asking for Megan and Dries to step down. (See https://twitter.com/merlinofchaos/status/895767767646748676 for before/after screenshots.)
The reason this petition had any legs in the first place was because someone registered an account pretending to be @marvil07, and impersonated him on Drupal Slack (see https://twitter.com/RAKESH_JAMES/status/895906793888530433 for a screenshot). Because Slack is a third-party service, we had no ability (that I know of) to determine that the email/IP address was a phony, and so several people (myself included) interpreted this effort as genuine when it was secretly an effort to get people to dox themselves by handing their first/last name and physical/email address to a bunch of anonymous people with malicious intent. :\
Anywho. Don't think this changes anything wrt this discussion, just another day in #DrupalDrama land... :P
Comment #226
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedIt was clever, and left me surprised, astonished and confused I guess.
However bold and smart it is, it's also dumb and stupid, because it makes them look as trolls (the same thing they are accusing others).
I think they are way past the assertiveness and correctiveness ( that they might had with any or all of their arguments) with these stunts, and I can no longer discern what is true, more or less true or false, or false.
Can we just reboot or go back in time? Can't understand anything at the moment. Honestly, I'm starting to look indifferent to all this, and putting my trust that everyone together as a whole, can fix everything, instead of pointing more fingers.
back to topic,
There is no central login - no LDAP, no Oauth, no GPG keys, no device confirmation keys (Matrix uses this), no drupal.org account linking, no way to block accounts from being created with your nickname, no big brother ID card checking, no nothing.
So no one can ever truly confirm one's identity, unless a method is implemented.
But I guess this problem is not new. Anyone can post anything with a fake or temporary account in any protocol, even on IRC.
Regardless, trust is always personal.
Comment #227
gregglesOn irc we do have the ability to set up a cloak and we can only give out cloaks to people who have setup a password and password reset mechanism. Then there is some more faith the person is who they say they are.
People who don't have a cloak have their IP show up to everyone in the world, for better and worse.
That is not a super obvious element of irc and someone could definitely just use tor or a vpn and change their nick briefly and trick a lot of people.
Comment #228
frobI do not think Slack is the way to go and I would argue that Slack only works to "reduce the barriers to entry for contributors" for people who use Slack. As someone who doesn't, it is just one more thing for me to run.
On the topic of SSO, right now we are using Slack through a hack. If the DA where to actually choose Slack for this, then we could setup SSO through SAML. This means we can enforce d.o user account creation and federate the accounts to Slack. https://get.slack.help/hc/en-us/articles/203772216-SAML-single-sign-on
Comment #229
kevinquillen CreditAttribution: kevinquillen at Velir commentedTo get SSO though, that comes with a hefty annual fee for Slack, which requires the Plus tier ($12.50 billed per month per user annually, or $15 per user billed monthly). It gets costly very fast at that level for orgs. Unless, Slack were to have some plan for super large OSS communities, which I don't think they do - and ultimately still leaves them with the control to pull the plug or change the rules at any time.
Comment #230
frobRight, Slack is prohibitively expensive. This is known. However, we could customize https://github.com/rauchg/slackin (which is what we are using for user signup) to verify user account creation against d.o for the initial account creation.
Comment #231
markhalliwellSlack has been debated... to death... and it's not a viable option for our community.
Please re-read the issue.
Comment #232
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedWell,
a few more points
In my opinion we still need to provide a resolution for it:
a) delete all channels, block channel creation and have a single channel directing people to go to other protocols. but this will piss off people by forcing people to change.
b) make bridges and let it be, simple, and still encourage people to go to other protocols.
--
Not plausible on my opinion:
c) if you don't use Slack, the way it is, it's just standing there and making people confused.
d) If you delete Slack, then someone will eventually create a new one, leading to the same problem.
Comment #233
webchickPeople are "voting with their feet" and ending up on Slack, regardless of current policy or what the ~60 people on this issue say. drupal.slack.com has 4,406 members currently (707 show as inactive, which means "only" 3,699, compared to the 303 active in #drupal on Freenode right now). Several initiative teams have switched over to using Slack as their official meeting channels over IRC, etc.
So it appears it is indeed a viable option, at least for a very large portion of our community, so we may want to stop debating and start accepting that fact, and instead focus on deciding what (if anything) we want to do about it.
Comment #234
freelockWell, Slack seems like an extraordinarily bad choice as the home for an open source community -- a closed, siloed, proprietary software-as-a-service provider.
That aside, most of us who are arguing here for Matrix are not trying to get people who love Slack to stop using it -- nothing of the kind. We're just asking for some assistance setting up a bridge to a completely open source alternative, which also happens to allow IRC users to participate. We're trying to bring the community back together again, without forcing anyone to have to choose a client they don't care to use.
Why is this not an obvious thing to do?
Comment #235
pwaterz CreditAttribution: pwaterz commentedI agree with webchick. I know it's proprietary, but it's a great communication tool. I think until something open source comes along that can offer similar functionality and stability the community should move forward on the decision. I think it'll be hard to find tool that offer stable voice and video chat that isn't closed source. If there are tools, then there's the added expense of maintaining infrastructure to support it. With Drupal having such a global reach, that could get very expensive. Also it's not something the community should be spending their time on, we should be focusing on core, contrib and making the platform stronger. I think Slack would enable us to do that more effectively. Also I would assume slack is pluggable so you can use different clients if you wish? Trying to get everyone to agree is impossible, a decision needs to be made and then re assessed in a few months if it was the right one.
Comment #236
frobSlack is too expensive. It doesn't support us. They literally have no product for open source communities. They have promised one for years, but it is not a priority. We have found a way to make it work, but for now, it is a stop gap.
Those numbers only show one thing. People are not willing to put up with IRC as it is. When there is a low barrier to entry alternative they will use that instead. This is good information but it doesn't prove anything other than people prefer Slack to our current implementation.
Good, they should. Slack is built for small focused teams and as a product it works well for this. Hopefully they are not reaching the message limit and what they are discussing doesn't get lost to time.
A majority can be wrong. We have debated here the merits of different systems in this thread. We have only really come to one conclusion. Slack isn't the final answer, we need a solution. I don't think we have found it yet. Maybe this is because we are debating the wrong thing. We are debating a replacement for IRC. I think we have reached a post-IRC era and we need to rethink how this system of chat really benefits a project. What is the purpose of the rooms in IRC and how can that be better serviced with the tools that currently exist. There are hundreds of ways for people to talk to each other.
What I am trying to say is: Maybe we no longer need an official ad-hoc chat room system. Just like how the forum was mainly off-loaded to drupal answers (for specific QA), maybe the type of system needs to be different and more purposeful.
I am asking this as a questions:
Seriously, we have identified problems over and over again. Let look at some use cases, aside from idle random chat.
@freelock, As far as setting up matrix bridges goes, open issues for specific issues. I don't see think this is the right place to ask for that. If Matix is implemented and its good people will start to use it.
Comment #237
freelockThere is a growing contingent using Matrix now, and an issue asking for Slack admins to add the necessary webhooks for the bridges - #2864161: Change Drupal Slack allowed/installed apps . We don't need to bridge all the rooms, but the large community rooms make total sense to do.
Slack has quite a few downsides for large communities like ours:
- Performance problems with large groups, undocumented maximum room sizes (what happens when we go beyond 5000? that's not far away, and at least 1 open source community hit a wall at that size).
- Search becomes useless because Slack only allows free groups to view up to 10K messages, which can happen extremely quickly.
- High cost to unlock features that Matrix and others have for free.
@pwaters there are several open source voice/video chat systems -- we've found Jitsi to be pretty effective. Matrix provides WebRTC voice/video that works pretty well 1 - 1 today, and they are in the midst of replacing their matrix.org-hosted Freeswitch instance with a Jitsi back end anybody can host.
We've also used BigBlueButton for webconferencing with good success.
Matrix is also working on a really cool VR teleconferencing system -- think Holodeck... https://matrix.org/vrdemo
But all of this is beside the point. The point is, there is no need to replace IRC entirely, people can continue to use it to participate in chats -- but if we can bridge IRC with Matrix and Slack, then everyone can participate on their platform of choice.
Comment #238
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedReminding why Slack can't be used for this project or any team larger than X number of members as any kind of serious or main chat platform.
- so-yeah-we-tried-slack-and-we-deeply-regretted-it
- https://get.slack.help/hc/en-us/articles/201314026-Roles-and-permissions-in-Slack
For me Slack is only and just a means of bringing people to Drupal through an additional chat platform, bridged, recommending but not forcing users to switch to another. Cause everyone will miss out on features that it doesn't has nor ever will have.
Comment #239
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@freelock++
@webchick++
@frob++
However, Slack doesn't have to be the one solution and there are already solutions that fit better:
- Matrix
- Rocket.Chat
- Mattermost
Comment #240
realityloopI hate to see the loss of history on a free slack tier, would be much better to use Discord which has searchable unlimited history, and voice/video and desktop screen sharing capabilities all free of charge..
Comment #241
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commented@all
We are making a bof at https://events.drupal.org/vienna2017/bofs/irc-and-bridging-drupal-community
The bridging of IRC channels with Matrix is a much nicer and opensource way to solve this debate supported by dozens of people above.
For those of you that still don't know how it works feel free to choose a client:
https://riot.im/app/
https://play.google.com/store/apps/details?id=im.vector.alpha
https://itunes.apple.com/us/app/vector.im/id1083446067
https://riot.im/desktop.html
Comment #242
Morbus IffListen, I know all you guys like VHS and already have players and lots of tapes, but Betamax really IS better. You just need to buy a deck, replace all your tapes, and try it out, you know? You'll be a total convert when you do. Trust me!
Comment #243
freelock@morbus iff Yeah, haven't you switched over to Wix? I hear it's the bomb! Can do everything Drupal does, no headaches! Let's all go ditch our open source and go proprietary...
Comment #244
frobRE: Matrix, show us. Give me a url that I can go to, such as http://drupal.slack.com or http://webchat.freenode.net and start chatting.
Until then, don't tell me that matix will be better, show me that matrix is better. I know, it's a bridge! But if I have to set up anything at all it is not an improvement over IRC.
This is why slack works right now. Someone did that. They setup the Slack channel and they made it public and they setup the herokuapp to automate channel invites. That made it easy.
ANSWER: I guess this was addressed in some of the first matrix comments. Freelock in #125 listed a bunch.
Why were these links so hard to find. It looks like we already have Matrix bridges setup. So then, what are the next steps? Bridge into Slack? Can we use Riot.im for this for free?
I am not asking about Matrix as the merits of matrix are all over the place in this thread. I am asking if anyone has looked into using riot.im as the web/app based IRC client? We need to read the EULA and Privacy Policy to make sure this is something that we can do. If so then just start editing doc pages to include links to the Riot.im freenode bridges.
Comment #245
freelockIt's much easier to onboard on Matrix/Riot than Slack, no invite needed.
Those URLs work -- but we've plumbed better bridges now, so you can drop the #freenode_ part out of it and get to most of the Drupal rooms we've explicitly bridged. E.g.
https://riot.im/app/?#/room/#drupal:matrix.org
https://riot.im/app/?#/room/#drupal-media:matrix.org
https://riot.im/app/?#/room/#drupal-commerce:matrix.org
https://riot.im/app/?#/room/#drupal-console:matrix.org (actually bridged with gitter, there's no IRC)
... etc.
You can go to https://riot.im/app/?#/room/#drupal:matrix.org right now, click "Join" and pick a username, and you're in... In the newly bridged rooms, you can even see history back to when the Matrix room was created. If you want to continue using that username, be sure to set a password and a recovery email, but those are optional...
Comment #246
frobI'm going to go out on a limb here and change the IS to reflect Matrix as the heir apparent. Or at least the figurehead we are leaning toward. Basically I am adding tasks to help us evaluate Riot as a service provider (the DA will need to chime in on that I am sure) and also list out some next steps for moving forward.
Comment #247
markhalliwellThe DA did: https://www.drupal.org/node/2490332#comment-12028868
Which is why this issue stagnated for a while.
---
GitLab + Gitter.im (+ Matrix bridge) sound more like the direction things are going.
This is why I said what I said above: please re-read the issue.
Yes, the issue is very long and, despite what the issue summary says, it seems people need to re-read the conversation to grasp how these conclusions were made and the reason behind why.
Comment #248
tim.plunkettI was able to use riot/matrix to impersonate myself (an IRC nick with a password AND a cloak). That is bad.
Comment #249
markhalliwellIn basic "open rooms" that allow anyone to create any username they want, and isn't really tied to any sort of true authentication mechanism, sure... that's certainly possible.
We can easily authenticate against real Drupal accounts if we needed, especially with something like GitLab + Gitter.im.
Comment #250
markhalliwellAlso, we wouldn't likely be promoting or using riot.im's software specifically, it'd be the bundled Gitter.im feature that now comes with GitLab, under the drupal.org domain likely.
The riot.im links were just given to show that Matrix does have web UIs as well, with riot.im being the most prominent.
Comment #251
frobI have been using riot alongside my IRC client. This is what that looks like.
Comment #252
frobRE: @markcarver
Is there something wrong with the IS?
Drupal console is a gitter matrix bridge, for those who want to test gitter integration. I don't see why running riot through its paces would stop the use of gitter in any way. It wouldn't even halt the use of Slack or IRC which is a big reason why it makes sense.
Is there something wrong with the Remaining tasks? Why wouldn't we use riot.im's implementation? Our current chat is hosted on freenode so why wouldn't we continue to host general chat on a 3rd party?
Comment #253
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commentedComment #254
dqd@webchick Thanks for the inside @ #225. Didn't know about this WTF.
From what I summed up for myself after being small part of this discussion all 2 months again is, that most of long term community members here, who really know about all the back and forth of it, embrace a scenario where some bridge is build to IRC to give an entry point for new community members which are used to more new chat applications without loosing IRC. But it should be sth. Open Source or at least supporting Open Source in a certain way with optional bridges for common other chat solutions. Is this correct? But isn't it already running via the drupal rocket web chat url brigded to IRC?
But if this is the way to go, I worry a lil bit about the authentication security to prevent stories like the one described by webchick. Maybe I am wrong, since I don't know of all of their mechanisms, but shouldn't we limit the bridges to chat solutions only, which can be included in the authentication mechanisms D.O. uses or will use in future?
PS: Did I missed it or was chat solutions embracing #mobile not part of the discussion yet?
Comment #255
davidhernandezRE #225, just to add some extra info, that situation was resolved because Slack forces you to register with a valid email address. So when brought to the attention of an admin, the admin can see the registered email and verify it was an imposter. From a moderation perspective, that isn't possible with all the alternatives.
Not to beat this particular dead horse, but I will repeat what I've said in other issues. As a community, we are inherently distributed. We always have been, and continue to be. Issue queues, forums, stack exchange, reddit, meetup.com, IRC, Slack (of which there are many), discord, twitter, facebook, etc. I have yet to see a strong argument to "decide" the community should be in one place, and what that place is.
With the drama that has gone on this year, it has brought up many questions and concerns about communications, participation, and who controls it. I'm increasingly mindful of this, and concerned about trying to funnel and control it so deliberately.
Comment #256
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedIt's becoming increasingly more evident that we will need a central authentication system (LDAP, OpenID, SAML, CAS, OAuth, etc) and local servers that can federate and authenticate against to dissipate all the security issues.
Matrix and RocketChat allows this.
Matrix with the synapse local server:
- LDAP: https://github.com/matrix-org/matrix-synapse-ldap3
- OpenID: https://github.com/matrix-org/synapse/blob/master/synapse/rest/client/v2...
- SAML 2: https://github.com/matrix-org/synapse/blob/master/synapse/config/saml2.py
- CAS: https://github.com/matrix-org/synapse/blob/master/synapse/config/cas.py
- OAuth: could not find yet
RocketChat with the local server:
- LDAP: https://rocket.chat/docs/administrator-guides/authentication/ldap
- OpenID: not supported yet
- SAML: https://rocket.chat/docs/administrator-guides/authentication/saml
- CAS: https://rocket.chat/docs/administrator-guides/authentication/cas
- OAuth: https://rocket.chat/docs/administrator-guides/authentication/oauth/
This requires however that we setup a local server (federated or not with the others).
This is just a quick search, testing needs to be done in depth.
Comment #257
ivaat CreditAttribution: ivaat as a volunteer commentedI still don't understand whats wrong with IRC? Reminding of original topic:
"At core conversation session by @kgoel at DrupalCon LA , 2015 on "Pain points of learning and contributing in the Drupal community" , several people mentioned that they don't like IRC and they don't get on IRC.
During core mentoring at PHPWorld and people from other Open Source community said that they don't use IRC and its 1990's chat client which is way too old to use in the Drupal community and why Drupal still lives on IRC."
I see mistakes at topic but first lets just go over of types of people community has. There are those who like to help via forum/question website (web interface). There are those who love using IRC.
* IRC is not a CHAT client. IRC = Internet Relay Chat
There are so many IRC client softwares out there that just pick what suits for you and connet to IRC server.
IRC is very popular with teams or simply community. Make channel, register it and invite all you team members TO irc server.
You can be anonymous in IRC if you like. Privacy is in your hands.
With IRC is good that you don't have put up own IRC server but can be done very easily. There is also so many web based irc clients.
Point is i havent seen any solid arguement why exactly IRC is not okey with modern days. Even if will be implemented #slack, matrix and what not people will use IRC and belive me. Lot of dissapointing supportes if IRC #channels gets taken away.
Comment #258
realityloop@ivaat I think the main issue is persistance of history when your absent from IRC, not everyone knows how to set up a bouncer....
Comment #259
webchickSince we've been going around in circles for quite some time, I'm going to attempt to bring this issue to conclusion. Wish me luck! ;)
WHEREAS:
- There is a "critical mass" of people already on Drupal Slack, who will not go back to IRC, for a variety of valid reasons.
- There is also a non-trivial percentage of people who prefer IRC, for a variety of valid reasons.
- Matrix (or similar technology) can apparently allow us to have our cake and eat it too by bridging these two so folks can use whatever technology they prefer, but we can still talk together as a single community.
I PROPOSE:
- We close this 250+ reply emotion-laden issue, and spin off a dedicated issue around setting up a Matrix server (or whatever) and begin working through the implementation issues (such as security/authentication/impersonation).
Sound good?
Comment #260
heddnI'm good with the proposal in #259. Before we mark this as closed though, let's get those issues opened and/or linked in here. Then let's kiss this issue goodnight.
Comment #261
heddnHmm, maybe #2885060: Drupal Chat Bridges IRC <-> Matrix <-> Slack is that issue? If so, someone want to go ahead and mark this fixed?
Comment #262
frobComment #263
frobOh, and webchick++ heddn++
Comment #264
Greg BoggsFrob has also spent significant time discussing and summarizing conversation about Matrix here:
https://www.drupal.org/node/2864161
Comment #265
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commentedThe closing proposal on #259 by @webchick seems to be a good direction. There is already a group of people that know how to move the creation of a matrix server forward. We can create an issue for it, ask the DA for a subdomain (maybe "matrix.drupal.org") to be used and meet in Matrix/IRC
https://riot.im/app/#/room/#drupal-bridges:matrix.org & https://riot.im/app/#/room/#drupal-infrastructure:matrix.org
Issue for this initiative is created
https://www.drupal.org/node/2905534 "Setup a dedicated drupal.org dedicated matrix server".
Thanks all for their patience and effort.
Comment #266
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented#257
Saying IRC is private or privacy aware is missing out actuality. Compare it to Signal or Matrix. Limitations are at the protocol level.
@webchick++
Comment #267
webchickDang, I knew that was way too easy. ;)
Turns out, Matrix is not quite the panacea that I hoped it was. :\ In reviewing some of the comments in the implementation issue and talking more to @mlhess, @davidhernandez, @tim.plunkett, and others, there are a number of problems/concerns with a bridge solution like Matrix.
Among them:
I think we're basically down to two options:
Assuming that the cons laid out here and elsewhere around Matrix/a bridge solution are indeed both valid and insurmountable, I think we should timebox the remaining discussion on this (to DrupalCon Vienna, maybe?), and then have someone (the Technical Working Group? the DA?) make the call, since whatever solution is chosen would/could ultimately become their expense and maintenance burden.
Comment #268
pwaterz CreditAttribution: pwaterz commentedThanks for the investigation webchick.
Made a quick survey:
https://www.surveymonkey.com/r/XKZPYBC
See results at:
https://www.surveymonkey.com/results/SM-6R9V6KKK8/
Comment #269
webchickHm. While I appreciate your mutual desire to bring this issue to conclusion, if we're going to do a survey, it needs to be much more broadly distributed than this issue, which is by definition only folks who've stumbled across it. (e.g. @Drupal twitter, Drupal Planet, announced explicitly on Slack, announced explicitly on IRC, etc.)
However, I'm not really sure that surveys are the way to go here, since there are numerous technical, security, community, and ideological concerns here that won't be nuanced through a simple choice like that.
Comment #270
pwaterz CreditAttribution: pwaterz commentedWide spread distribution would be better, but why not see what the popular vote is with in this thread? Then bringing it to a wider audience if it makes sense. Having a complex survey will push people away, we are all strapped for time.
There's never going to be a consensus on this topic, I think this thread proves that. I think choosing slack as the rich communication tool is the right way to go. Analyzing it to death isn't going to get us anywhere. If people want to continue to use irc that's fine, but the organizational choice should be slack. I think I saw in this thread that the board is already using it, so why can't we move forward?
Apologies if I come off harsh, I just want this topic to move forward.
Comment #271
webchickFair enough; doesn't hurt to have it as a data point.
Comment #272
Greg BoggsI wonder, has anyone gotten a price quote for Slack logging? If not, does anyone mind if I contact slack and ask?
Comment #273
colanThe assumption with the above comments is that the only Matrix option is using matrix.org, and they're solved if we instead run our own Matrix server, which would be just as good as running our own Mattermost server. Can we add this as one of the options?
Comment #274
davidhernandezIf I remember correctly about every time this was investigated, the Slack cost would be something like $15k-$16k per year for the number of users we have.
Comment #275
frobI really don't see how reading those comments came to this conclusion. If we run our own martix server and use d.o as the user authentication system (the same way it would have to be run with slack) then these issues become moot.
I really don't see how a survey will help as well, but it is one more data point.
The issue queue here starts with evaluation of riot and ends with:
Comment #276
davidhernandezWe should confirm that since I'm not sure how that figure was calculated.
Comment #277
pwaterz CreditAttribution: pwaterz commentedAdded matrix.
Comment #278
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@colan++ has summed up what i was going to try to re-explain once again.
Slack is not an option. Its useless as a tool for a large community.
@webchick have you read or re-read the links i dropped about other communities on which slack failed horribly?
Also, you are dismissing that we are implying Matrix/RocketChat/whatever to be @SSO bridged to Drupal.org via LDAP, CAS, SAML, Oauth or other method to REQUIRE a drupal.org account, and also a valid email address.
About @privacy - you can't have full privacy if you want to patrol the community.
It's one or the other.
@pwaterz that poll is obscenely biased.
Please remove it or refactor and then reset it.
It needs options for ALL these to be fair:
- Matrix
- RocketChat
- Mattermost
- Gitter
- Telegram
- Hangouts
Regards
Comment #279
frobMany of these issues have been discussed at length this thread #2864161: Change Drupal Slack allowed/installed apps
Comment #280
pwaterz CreditAttribution: pwaterz commentedUpdated the survey with more meta data.
At the very least this is proving useful for building a good survey.
Comment #281
Greg BoggsI believe the Slack cost is calculated at a discounted rate of their pricing model based on currently active users on the server. But following up would be good because it's not a trivial amount of money.
https://get.slack.help/hc/en-us/articles/204368833
Comment #282
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedthanks @pwaterz.
Comment #283
webchick@lpalgarvio: I'm merely reporting reality. The reality is that regardless of other communities' experience, regardless of Slack's limitations as a platform, their pricing, etc. that's where 90% of the Drupal community is today, and they have no intention of moving to anything else.
I don't think all of the concerns about bridging are resolved by hosting our own Matrix server, though some are. My understanding is the security team + DA is a flat-out "won't fix" to any bridging solution, self-hosted or otherwise, due to the additional risk of impersonation, privacy violations caused by lurkers, costs associated with developing workarounds around those issues, ongoing maintenance staff time/cost required, etc. Both IRC and Slack are currently free (as in beer), and entirely maintained by third parties so do not incur any additional burden on the DA/security team.
Comment #284
freelockWow, this seems like a bunch of mis-information floating around. @webchick #267, point-by-point:
Not true. Matrix automatically disambiguates display names that are the same, by adding the globally unique "Matrix ID" of the user. It's trivial to see who is who when looking in the Riot client, and ban/kick as appropriate. The only real change here is that kicks/bans need to happen on whichever side of the bridge the abuse is coming from -- either the Slack side, or the Matrix/IRC side (the Matrix/IRC bridge does propagate kicks and bans).
Again not true. The bridge works fine today, under moderation. DNS changes are only necessary if we want to support Matrix addresses in the :drupal.org namespace. Which would facilitate doing a central login/ additional options for reputation management, but is entirely optional.
And if we did set up a :drupal.org Matrix server, it would not be pointing to matrix.org -- it would be pointing to whichever server we designate as the Drupal.org Matrix server. This isn't a Saas -- it's an open source server. Who manages SMTP for drupal.org? It's the equivalent of setting up a mail server (but in my experience, far easier to administer, having run my own Matrix server for nearly 2 years, and my own mail servers for over 15 years).
This much is true -- but you also can't enforce a Drupal Code of Conduct on IRC rooms. Adding Matrix does not change the overall situation -- it does open up the Slack silos so that people opposed to Slack can participate in the same conversation, which to me is the entire problem here.
For rooms of > 1000 people, is this really a concern? Not asking to bridge every Slack channel, just the community ones where IRC has been largely abandoned. Druplicon used to have a public log of these anyway -- does Drupalbot?
*splutter* You think IRC or Slack is secure?
Agreed, bridges are not appropriate for rooms that have extremely sensitive content. Matrix E2E rooms are, and add a level of security you don't have on either Slack or IRC.
This is the really lame situation we're trying to improve.
This is another really lame situation we're trying to fix -- making an open source project entirely dependent on a commercial, proprietary SaaS with known hostility towards open source. Seems like a risk we can easily avoid here...
Really the only valid "con" I see here is the room membership list -- across 2 bridges, you're not going to see everybody who's in a particular room. But if it's meant to be a public forum, and public logs exist anyway, I fail to see why this is such a big issue.
And the only other "con" is that there's one more channel that might need moderation -- and yet there are plenty of people available to moderate.
Meanwhile, there are lots of other advantages to Matrix that make me wonder why people are interested in Slack at all, but that's a different topic. On this topic, the coming "Groups" functionality which should land in weeks, probably before Vienna, might provide an alternative to reputation management that makes Matrix a really compelling option.
Comment #285
webchickI'm reporting back third-hand information. One of the other folks who are opposed to Matrix (I'm not one of them; I'm just pro-reality, and pro-wrapping this issue up before it hits 300 comments :P) will have to respond to explain their rationale.
Comment #286
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedThis poll will need a proper clarification on it's page or elsewhere where it is shared.
Otherwise it's probably going to be a battle of "do you want slack, the super popular easy chat that you probably already use vs matrix, the foss underdog which you probably never heard of (wth is foss anyways.. oh like drupal)".
Just like Telegram faced vs WhatsApp.
(But i appreciate the effort that @pwaterz has already done).
Comment #287
pwaterz CreditAttribution: pwaterz commentedThat's exactly where I am. I think we should give Slack a shot, unless there is something concrete stopping us. Then we can open a room called #replaceslack ;)
Comment #288
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #289
ciss CreditAttribution: ciss as a volunteer commented@pwaterz That survey won't produce useful data. Its results can easily be manipulated by voting repeatedly in a private window.
Comment #290
frob@pwaterz The many cons of slack have been discussed at length here. From the IS
Comment #291
webchick@frob: ...and yet, 3800 people are actively using it every day, which is an order of magnitude more than use IRC. Again, these are just cold, impersonal facts. All of the valid rationale in the world doesn't change them, unfortunately.
Spoke to @hestenet at the DA. He said:
"Any expense for the DA to run a custom server is not currently budgeted, and would likely need to be fund-raised for and/or approved by the ED/the board"
Given that any such fundraising/approval process would take time/energy/focus away from the DA's other efforts, including improving our collaboration tools, I'm going to crystal ball a bit here and say that's probably going to eliminate the self-hosting option until/unless we have some kind of crisis like Slack decides to boot everyone off. (I personally would much rather have pull requests and real code review tools than a fancier chat solution, and think most people would agree.)
EDIT: Also I totally just started the #replaceslack channel on Slack. 😂
Comment #292
realityloopPerhaps we should at least set up http://slackarchive.io/ for the public slack channels?
Comment #293
freelockI would join... if I could stomach Slack. How about we bridge that? 🏃
Comment #294
frobMajorities of people make bad decisions all the time. And I don't expect this to happen over night. In-fact the only urgency that came of this was from this statement.
Why? Where and When was this decided?
If the DA started paying for use of Slack as an official chat service, I would save the DA around $168/month by no longer getting involved in chat online. My DA membership cannot possibly cover a Slack subscription. Not trying to sound threatening, just running the numbers.
The status quo has served for a year or more, we can wait for more funding and for more planning to be made. This should just get in the queue, it is by no means an on fire priority until Slack boots everyone.
Comment #295
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@realityloop So one proprietary solution (slackarchive) to fix one of the many problems of another (slack) to give people a way to chat and contribute to an open source software (drupal). Lets throw in some more proprietary solutions, paid or not, to fix it better, because it's too broken by default.
Makes perfect sense.
Without the emotion of Perfect Sense of Roger Waters.
http://www.metrolyrics.com/perfect-sense-part-i-ii-lyrics-roger-waters.html
Comment #296
webchickOk, sounds like status quo it is. We can revisit once the DA's collaboration tool work is done, or an organization like Freenode offers a trusted Matrix server to lots of different open source communities who have this same problem, or Slack boots us all off, whichever comes first.
In the meantime, spun off: #2905773: Document in places that mention IRC that Slack also exists and has lots of people actively using it
Comment #297
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commented@webchick, @hestenet:
Matrix and Freenode are already collaborating and have bridges setup since 2015
: https://matrix.org/blog/2015/06/22/the-matrix-org-irc-bridge-now-bridges...
If Freenode chose to work together with matrix giving them access to all channels, logically it's trusted by them.
Since then lots and lots of features and bugs have been improved in order to make the Freenode/Matrix a clean and SECURE experience, including the availability of the dedicated server: https://matrix.org/blog/2017/05/12/update-on-matrix-org-homeserver-relia...
On the other hand they have been aggregating more and more OpenSource Tools together with Matrix like JITSI https://matrix.org/blog/2017/08/23/introducing-matrix-widgets/
So, yes, if we are still loving OpenSource and all that it provides then Freenode via Matrix is the way. It will be the best place for our community.
Comment #298
davidhernandezNot everyone considers this a con.
Comment #299
frob@davidhernandez, before we get into these arguments again, please read all 297 previous comments. We have gone back and forth over every pro and con of slack, irc, matrix, and other services to a great extent.
The issue summary is an accurate representation of what has been discussed from comment 1-297
Comment #300
freelock@davidhernandez "Requires users to register" is a room setting in Matrix -- all Matrix users are registered, apart from "Guests" who basically have accounts with no password, which is entirely irretrievable if they lose their corresponding browser cookies.
Room settings:
... Our Freenode channels are not that strict in the first place. And if we set them to +r, Matrix can handle that -- I'm in several +r rooms on Freenode already, via Matrix -- including #docker and several other open source projects. (oh yeah, another benefit of Matrix -- "getting off the island")
This is a policy question, and Matrix supports more different policy variations than either Slack or IRC. That's part of why we're trying to work out policy here -- and it's quite frustrating that the DA's answer is apparently one spawned entirely by fear of the unknown and shutting down contributions a bunch of us are trying to make, rather than actually trying to work out a solution we can all live with.
Comment #301
webchickThis is an unfair classification. It's spawned by their desire to focus time/energy/money on a priority (improving developer tools) that has far greater benefit to the community. Which, given they have limited resources, is exactly what they should do, frankly.
Nothing stops folks passionate about this from continuing contribute—e.g. experimenting on separate AWS/Slack instances to address the full extent of the "cons" list, working upstream to make the offering more seamless so it lessens the maintenance burden, etc.—in the meantime.
Comment #302
freelockShutting down the bridge stops us.
I'm not going to contribute to a Slack solution at all. Nobody stood in the way there as people moved to it -- and when we come along trying to resolve the fragmentation we get shut down?
Comment #303
pwaterz CreditAttribution: pwaterz commentedTo me it seems like some new tickets should be spawned from this one exploring/defining integration steps for each option others feel passionate about. Thoughts?
Comment #304
webchickI don't quite see how shutting down the bridge stops you from continuing to prototype to address the outstanding concerns. You just need an IRC server with some channels, a place to run Matrix, and a Slack instance, correct?
The reason the bridge is being shut down, to my understanding, is because there are several blocking concerns which haven't yet been addressed, and in the meantime it's sucking time/attention/focus away from the DA + security team + other volunteers when they are all focused on a much higher priority thing. Which seems fair enough.
Comment #305
freelockEvery one of the "Blocking concerns" have been addressed, ad nauseum, in several different issues, in several different ways, by several different people. It's like the DA folks are willfully not reading them, sticking their fingers in their ears and going "la la la I can't hear you!" refusing to listen or consider at all.
Clearly the DA is hostile to Matrix. It's unclear to me why, because for every objection there is a really sound response.
Comment #306
webchickJust a thought: maybe it's at least in part due to your delivery? ;) I'm usually not super willing to help people who accuse me of sticking my fingers in my ears and saying "la la la I can't hear you!" ;) Tossing an obligatory link to https://www.drupal.org/dcoc here. Remember we're all on the same side here: making Drupal more awesome.
The situation currently is the DA has clearly stated they do not have bandwidth for this initiative right now. Hence, postponed. I'm really not sure why that's being taken personally.
There are others, who are not part of the DA, who have stated several concerns. I am really confused about how you can say they've been resolved "ad nauseum," when one of them was "don't pass our data to third parties," and with the DA saying, "we don't have budget/resources to run our own server." That seems pretty well and truly unresolved.
I think what I would do in your position is continue prototyping, maybe put together a blog post or video or something showing the awesomeness so that when the DA's plate does open back up again, they have something concise to review that's not a 300+ reply issue.
Comment #307
hestenet@freelock
I totally appreciate your frustration. I hate being an obstacle. In this case it comes down to a few factors (some of this is reposted from the other issue where we've been talking):
#2905534-21: Setup a dedicated drupal.org dedicated matrix server
Point number 2 above is a real tough one. I think your suggestion here: #2905534-22: Setup a dedicated drupal.org dedicated matrix server (i.e: Do this only on the biggest public channels, and with a Topic warning set)... is a good one. But I'm not sure that actually meets the concerns people have been raising (I hope they'll chime in to raise their concerns with that solution).
If we solved:
... in ways that the people who raised those concerns agreed solved them..... then we're still stuck needing to find DA budget and resources to spin up and start managing another server. I don't think I can get approval for that right now.... but per @webchick's point, maybe those things can be hashed out..
If they do remain unresolved or contentious... I do have to say that my default stance will continue to be deferring to privacy in the current climate.
Comment #308
Greg Boggs@webchick thanks for all your effort getting this issue updated and for providing some focus on the current status of Matrix bridges. It's a hard thing that you're doing for the community to work on these communications with everyone. And I really appreciate your time and energy. I know a lot of folks are eager to have free software chat and free software clients for Slack, so this is a difficult issue for a lot of people.
Comment #309
freelockMatrix provides a level of verification not possible in IRC or Slack -- right down to device fingerprints (needed to support e2e encryption). The Matrix solution to impersonation is disambiguation -- if there is more than one user with the same display name in a room, show enough information that it's clear who is who. This is not easily defeated.
We already know Slack has a problem with impersonation -- it's happened before, and required admin control to address. IRC is a wild west, if the room doesn't require registered nicks... and users need to know to register their nick to avoid impersonation there.
Matrix provides the same kinds of kicks/bans/ignore options as IRC, at least as far as the Drupal channels have needed to go.
Nothing precludes people going to a private room. These are public chats, and at least some of the time, have had public logs. What is the issue here?
Again, this seems like a weird constraint for a public room meant to provide support to the public. If a team wants to have a single channel that is not bridged anywhere, for private team communications, nothing precludes that, nobody is arguing that all communications should be public. We're just trying to make it easier for people to find and use *PUBLIC* chat rooms. Why should anyone care what client the person on the other end wants to use?
This is like saying "I'm not going to send email to you because you use Outlook." My email might end up on an Exchange server I don't control -- horrors! Gmail is the worst -- Google can see all your email, so I'm not going to email anybody with a Gmail account. That's exactly what's being said here, just substitute email for chat to see how ridiculous this is.
Well, that is the issue here. The people who have raised these concerns have all gone silent when their concerns have been addressed. Thus the frustrations.
Not necessarily. The first step of the solution involves no DA budget, no resources, no need to manage another server. That's only needed if the DA wants to offer "@drupal.org" identities or room aliases -- but that can easily be added in the future, or not at all, without diminishing the usefulness of the bridges we're after.
The only thing we need to complete these bridges is a Slack admin to grant permission to add them. It's a couple minute process, for each room, and it's done. And the DA can move on to other issues, not need to be involved at all until after the rest of the infrastructure issues are dealt with -- drupal.org Matrix servers are a "nice-to-have" but in no way essential to solving the chat fragmentation issue.
Comment #310
webchickMy understanding is the blocking concerns there is that Drupal's Slack community has some community norms, like:
My understanding from talking to folks there with concerns is that:
Are there solutions that have been presented for these that have gotten missed along the way?
Comment #311
freelock@webchick ah, thanks, finally some clear explanation of the concerns people still have after all the dialog -- this is what's been missing:
This makes it sound like it's not Matrix that is the problem the DA has -- it's IRC.
And yes, I agree, this is a fundamental issue with IRC, that's probably not possible to solve. There's no way I know to have a public IRC channel and put the DCoC in front as a gate -- IRC simply isn't that sophisticated.
So if these are the concerns, why not at least leave the Matrix/IRC bridges in place? Nobody has raised any valid concerns about that bridge -- why remove it? From your first list, 1 and 2 are not an issue with the IRC bridge -- they are only issues with the Slack bridge. 3 and 4 are not possible on IRC already. And from your second list, these are all issues you seem to have with IRC, none of them apply to Matrix or the IRC bridge. (FWIW, Matrix can easily address all 4 items from your second list, if bridges aren't involved).
Comment #312
webchickYay, glad we're speaking the same language! :D Sorry on my end; I don't know really anything about Matrix and I wasn't behind Drupal Slack, so I'm trying to "bridge" (ha!) two worlds, and sometimes failing badly at it. :P
So, pardon my further ignorance, but what is the benefit of a Matrix/IRC bridge if it doesn't also connect to Slack (where, once again, the vast, vast majority of people have already moved)? Wasn't the point of exploring Matrix to fix the regression of the community chatting in two places? Or would this basically be to give IRC users some of the additional benefits Matrix has, like groups functionality and additional security?
Comment #313
Greg BoggsOne of the biggest features for me would be being able to use a better, open-source client to access Slack. It's possible I can get the RIOT client connected to Drupal Slack through gateways: https://drupal.slack.com/account/gateways. So, that might be a win even without bridging. But, with the bridge, all I had to do to connect to Slack was click a RIOT link and it just worked.
Comment #314
freelockWell, a Matrix/IRC bridge basically allows us to use a rich, Slack-like interface with normal IRC -- and interact with people who still use IRC. Obviously if it's not bridged to Slack, we're not part of the conversations on Slack -- but at least we are on the conversations on IRC.
Well, yes, that's one part of it.
My shop has been using Matrix for 2 years -- it's our core platform. Many other shops have chosen Slack, but we (obviously) prefer to use open source, self-hosted solutions. And one of the big benefits of Matrix is that they have done a lot more work on bridging to other networks than anyone else -- their vision is to make "chat" universal, like email, instead of silos like the early days of email where AOL users could only mail other AOL users, Compuserve users only interact with other Compuserve, etc.
Matrix is trying to be the SMTP protocol for universal chat.
But if having mandatory registration and DCOC acceptance is a requirement, this obviously is inherently at odds with a broader open conversation. It's also a (huge!) barrier to casual questions from new Drupal users, so I question whether the Drupal Association wants to even have an easily reachable place to offer this kind of support -- or if they want to continue to only have a closed, restricted conversation among people who are ok with Slack.
It allows IRC users to continue using IRC without any change whatsoever. And it allows those of us who prefer Matrix to post code snippets, screenshots, have video/audio conversations, embed widgets, use a variety of other bots, all while degrading gracefully to IRC. If we hadn't said we were using Matrix, IRC users would never know the difference -- they would just see the automatic paste-binning the bridge does, links to images/videos/etc and miss out on the richer experience.
Bottom line here: is the DA trying to be inclusive to the broader community, or exclusive to those who are willing to use Slack? (there's probably a lot more of us than you realize...)
Comment #315
freelockWe can certainly create bot-controlled Matrix rooms to bridge to Slack, and basically make the bot enforce a similar signup workflow before inviting users to a room that requires invitations. The membership list sync'ing is limited by the current Slack API that the bridge uses, but otherwise this could address all the other concerns expressed here -- if we don't then bridge that room to IRC.
I'd be willing to write up such a registration bot and include as a submodule or related module in https://www.drupal.org/project/matrix_api , if this is deemed necessary, so that the list of registrants can be managed in a Drupal 8 site...
This approach doesn't solve the fragmentation issue, but it would at least allow people to use a single open source client in all the conversation locations, while preserving Slack and IRC room silos as they are.
Comment #316
webchickThis question misses the mark, IMO. The DA / security team isn't in the chat business at all right now (both IRC and Slack grew organically from community pushes, and both are maintained by 3rd parties). Them wanting to stay this way is one of the reasons this issue is postponed right now.
So it sounds like, among other benefits, Matrix can be like a fancier and more feature-rich UI for IRC. So can you explain why does that need the DA or security team to do anything? Why can't someone who wants a fancier UI for IRC use matrix.org/riot.im/wahtever on an individual basis? If it's a matter of a trusted third-party, could they connect to Freenode's Matrix server that was previously mentioned, or..?
Comment #317
freelockWell, if the DA wants to stay out of it, that's fine. At some later date when appropriate we can all revisit an "official" chat service, and by that point Matrix might be the most compelling option anyway...
But if it's not the DA opposing bridging to slack, who is? We've already bridged much of IRC, and there are some country groups already bridged into Slack.
Personally, I'd just like to participate in the Slack conversations without having to run Slack. And all it takes is an admin on a "maintained by 3rd parties" slack room to approve two webhooks. (Something that can easily be revoked if it proved to be a problem).
As part of a growing group of people on Matrix that "grew organically from community pushes, and ... are maintained by 3rd parties" we're just asking to be able to participate on a free, open source client instead of having to use a proprietary SaaS to be part of the larger conversation.
We don't need anything for the IRC bridge -- just that it not be removed. And if you're not controlling the Slack access, then we don't need anything from you at all.
We were looking to expand this to Slack, and bridge the communications. If IRC and Slack are fundamentally at odds with each other, then it sounds like this is a non-starter.
We do already. We just don't want that taken away.
Freenode doesn't have a Matrix server -- not sure where that misinformation came from. Matrix.org works closely with Freenode staff to make sure the > 100,000 bridged matrix users meets Freenode's standards for privacy, security, all the concerns being raised here. And by all accounts, it's a very good relationship between Matrix and Freenode.
Comment #318
webchickIt's members of the current Slack Admin team, several of whom have posted in this thread and others with their concerns. I think they've mostly gone quiet at this point because they're feeling repeatedly dismissed and unheard. :\ Sounds like you feel the same way. So let's all try and work on our communication a bit, here; this really doesn't need to be an emotional discussion, and it's really just getting in the way of people understanding one another.
Right, and they are just asking for their blocking concerns to be resolved prior to facilitating this. But it sounds like at least some of them may not be resolvable?
Sorry, I'm confused again. If a Matrix/IRC bridge can exist without the DA / sec team / Slack admins needing to do anything, what exactly is threatening to get "taken away" here?
And ok, sorry about my misunderstanding of Freenode/Matrix. I thought that's what @ricardoamaro was saying in #2490332-297: Evaluate whether to replace drupal IRC channels with another communication medium.
Comment #319
davidhernandezI'll say again (Though maybe it hasnt been said in this particular issue. There are multiple gong on.) you can connect to Slack through an IRC client. You don't have to use Slack's own app. If that is someone's main concern.
Comment #320
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedSorry for interrupting this debate, and for posting this again, but this deserves attention.
@webchick and dear all IRC admins and Infra team,
Our #drupal-pt has been affected by this change and it can not be.
You see, it is oversee, ran and managed solely by the independent Drupal Portugal Community, and the ADP - Associação Drupal Portugal, non-profit organization registered and running in Portugal, which also founded all the Drupal Portugal channels across different platforms - channels which you can consult here and here.
This has happened because in the past we have decided together with the Drupal Association many years ago, in 2010 or 2011, to allow in the #drupal-pt channel the drupalircowner user, and set it as the owner, in order to Protect our IRC channel from misuse and abandonment.
You have however decided to also block (ban) the bridge in our #drupal-pt channel, as well as in other community channels, such as #drupal-be, #drupal-in, #drupal-nl and others.
It is causing us harm and grief.
We kindly ask you to unblock the bridges in such community channels, as they are run independently.
Also, if the action was taken against official channels, why were we target as well, and why weren't we warned?
Thanks
Comment #321
rodrigoaguileraRemoving the IRC-Matrix bridge feels like very hostile movement against matrix without very solid reasoning.
Now I have to search for an alternative IRC client :(
Comment #322
freelockIf it's Slack admins who don't want to be bridged, why did I just get kicked and banned from several Drupal Freenode rooms?
Has there been a single instance of abuse from Matrix in IRC? Why this drastic, hostile measure? It's very much going to reduce my participation in Drupal, that's for sure -- you've just banned my IRC client.
@webchick the threat was just made real.
This is a case of the IRC admins banning the Matrix bridge, blocking us from participating in the community, because of security/privacy concerns that the Slack channels have? Ones that are already worse in IRC itself than they are in Matrix?
Sheesh. Utterly ridiculous.
If the problem is IRC is not compatible with Slack, why is IRC banning Matrix? Can anyone point to an example where the Matrix/IRC bridge has been any kind of problem?
Comment #323
hestenet@lpalgarvio et. al-
I'm sorry this is proving disruptive to your community. We are trying to find an appropriate response. The issue being - in none of these issues was Matrix bridging ever approved as a permanent solution for any official or semi-official drupal-# channel.
It *was* approved in this issue #2902791: Bridge drupal-in IRC channel with #drupal-in:matrix.org as a *test* for the possibility of bridging. As far as I'm aware no one ever opened issues or asked about bridging any other channels.
At the same time, the #drupal-pt clearly took this idea and ran with it and are now largely dependent on it, so this is obviously disruptive...
I'm very sorry about this disruption, but given the unresolved issues we chose to decommission this integration until or unless we can resolve those concerns. Those issues of privacy/impersonation/consent still trump convenience or disruption.
Comment #324
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedI've talked with timplunkett over Riot <-> IRC. The conversation wasn't pleasant, as i rushed in, very upset with this matter, asking to talk with the people responsible for this. I'll not comment on how he responded, which i frankly don't care if it was correct or not, but on the facts.
- timplunkett refuses responsibility.
- denies that he is an IRC admin.
- admits he is a Slack admin.
Now I see on IRC:
- timplunkett nick changing to timplunkett[m] (Matrix alias)
- is an admin on many IRC channels, like #drupal (+Aeiortv, since 5+ years)
- probably is a Slack admin as he admits.
Probably also has access to the drupalircowner user, which is one of the only users to have op access in #drupal-pt.
Am I the only one who sees conflict of interest? Was I lied to?
The Bridges are still broken for the Community channels.
Comment #325
freelockBut those are issues with the Slack bridge, not the IRC bridge!
I've been using the Matrix IRC bridge for 2 years now in a dozen Drupal rooms, in exactly the same way as many users use bouncers, and I'm certainly not the only one.
Now, I'm effectively disconnected from IRC, at least the ones that have the drupalircowner set. (Several others are fine).
Where are the negative results from this "test" that have led you to intentionally break communications channels some people have been using for years? A bunch of hypothetical fears and irrationality here. No wonder the Drupal community is fragmenting -- with administrators actively fighting to shut down communication channels.
Comment #326
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@hestenet
The Drupal Portugal channels exist in Matrix since 09/Jan/2017, bridged the same week, and the Telegram channels exist for far longer, and have been bridged successfully on 22/Aug/2016.
Both are now broken because Telegram interfaces with IRC, and now people are talking to walls.
They both predate ANY decision and were implemented solely by us, and demonstrated to others to show the potential.
Why would the admins assume that these channels are dependant of DA? Which others have been affected?
We want the bridges back on for our community channel.
Comment #327
hestenet@lpalgarvio - Just to be clear here @timplunkett is not responsible for these changes or this decision, though he was one of many people consulted, and one of many people concerned about the issues mentioned in #2490332-307: Evaluate whether to replace drupal IRC channels with another communication medium
I will say this again. Our passion about choice of chat clients =/= forest fire. The community is not burning down over this. We need to be very careful, deliberate, and respectful when making new technical choices and integrations.
Right now, we have not achieved the appropriate cross-community consensus to implement bridging in a way that satisfies the concerns in the comment I linked to above. There has also been a lot of running roughshod over peoples concerns and just implementing new tools without trying to build consensus, in the hopes that it would just build organic momentum. And admittedly that is a strategy that has worked for other tools. For this tool, where a person's words are bridged with or without their opt-in, that technique has not worked and in fact, backfired on concerned parties willingness to consider this solution.
@freelock - are you currently prevented from using Matrix just as a client? (does it have that capability?) Or does it *only* work as a client by bridging channels? (Edit-to-add: I don't know how you were using this for 2 years if it required freenode admins to set up the bridge, which should have required consensus from the drupal IRC admins?)
Comment #328
webchickHm? Only the lack of adoption of the DCoC and lack of registration were Slack-specific concerns.
Impersonation is one of the biggest and not satisfactorily addressed, from anything I've read nor what I've been told. Apparently thanks to @mlhess testing, there's a webchick running around on riot/matrix despite me never logging into one of those places. While Matrix (apparently) provides additional info to help people suss out that that's not me, IRC doesn't. I'm just "webchick[m]". That's what we call in core a "critical bug" and it blocks release, as it should here.
Consent is also a huge one and not addressed. While people probably are less ideologically concerned with their information from IRC landing in Matrix vs. landing in Slack or a similar commercial entity, there's no way for them to know that this is happening on their behalf. While it's been argued this is no different than an IRC bouncer, IRC bouncers are fairly common. Bridges to entirely different chat platforms are not. And the onus is on this team to prove they have consent; "well no one complained about something they didn't realize" is not a valid defense. :)
@lpalgarvio unfounded accusations and conspiracies against community members are not tolerated. If you have an issue with the way someone treated you, the CWG can be contacted to help mediate.
Comment #329
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commented@webchick I'm not here for any of that, and I don't want to seek any issues with tim, so I'm just going to refrain from contacting tim.
Since this decision doesn't look to be reversed any time soon, neither the Drupal Portugal community channel seems to be going to be fixed by any of you any time soon either, I've opened a new ticket whereby I ask for the delivery of the founding status of the channel to our @Druplbot user.
https://www.drupal.org/node/2906035
Comment #330
wturrell CreditAttribution: wturrell commentedThis sentence irritated me a bit:
Firstly, it depends how you measure it obviously, but I'd suggest most of the overall Drupal "community" rarely if ever use chat at all (myself included), and imho that's a good thing. Chat being popular doesn't necessarily mean people will be more productive or any nicer to one another.
As for the second bit, who can predict what they'll do? Who knows if Slack will be better/worse/good/evil/still exist in five years.
Also, does it even matter if Drupal has more than one chat platform? Other than the issue queues (which is where decisions are supposed to happen) and other bits of Drupal.org, most of the project is fragmented. Arguably, all that matters is a page with a canonical, up to date record of where to find certain groups of people, and the continued ability for individuals to specify on profile pages etc. where they can be found.
Imho, the key concern for end users is surely not the platform but the ability to use a client that broadly matches their personal preference (whether it's something minimal and text based, something they can run in a web browser, or a mobile phone app, a client that supports audio and video chat, or something for those people for whom proper language is apparently no longer good enough and who can only communicate via Emoji and animated GIFs...) Plus basic security, identity verification etc.
Matrix was sounding very promising when I last contributed to this thread, especially given its non-commercial nature and choice of clients.
Also, we can't keep rerunning this conversation just because people coming to it fresh haven't made an effort to read the previous comments (many of which are detailed).
Comment #331
freelock@hestenet I am blocked from many Drupal channels right now because of this. Matrix does not talk IRC directly, its bridge does.
There are two types of IRC bridges, "Plumbed" which require an IRC op, and permits some configuration changes on the Matrix side of the bridge, and "Portal" which do not -- any Freenode channel may be joined and it auto creates a Matrix room with restricted settings that do not permit past history visibility or guest access. Both have been kicked as a result of this action.
@webchick what's to stop anyone from impersonating you on any of the hundreds of other social media systems? The world's a much bigger place than just the Drupal chat rooms. Mastodon now allows anyone to run their own Twitter-like service, and use any display name they want. There are plenty of naming collisions in the real world -- the best you can hope for is to make a clear disambiguation policy, like Matrix does -- or go hole up in your own silo where you don't have to talk to any outsider.
For Matrix in particular, yes there can be many webchicks. However, you can just say "I'm the one that is @webchick:drupal.org" and nobody can spoof that, if you're registered on the Drupal.org server. It's much like email, except that nobody can spoof your 'from' address/Matrix id. (At least not without hacking your client somehow). For the IRC bridge, if you have registered webchick on Freenode, you can't use that nick from Matrix without authenticating to Nickserv. (I'm just "freelock" on IRC, not "freelock[m]", and my Matrix account is registered with Freenode's nickserv like anybody else with a registered nick.)
Regarding consent, isn't a notice in the channel topic sufficient? Who doesn't read that when entering a room? And Matrix rooms only show history to people who have been present in the room at the time of a particular message, unless an admin explicitly configures otherwise (which can't happen in a "portal" room).
But, more to the point: If the bridge was only "a test", where is the transparency around the results of this test? You all have given mysterious hand wavy excuses for shutting it down -- where is there an incident that could not be handled with a normal kick or ban? Where is there an example of the Matrix bridge causing an abuse issue that could not be done even easier from IRC? Where is there an incident of something private becoming public due to the bridge (in a public room of all places!)
Can anyone provide a clear, understandable, specific example that came out of the test other than "somebody registered my name" that is reason enough to disrupt a bunch of country team's chosen communications, and a lot of other users who think chat should be universal and not a bunch of silos requiring everybody to load up a bunch of different apps to talk to somebody?
Comment #332
frobOne of our communities is burning down. RE: #2906035: Return the #drupal-pt channel to the community the dismantling of the bridge has segmented this community. Please reinstate the bridge for their channel. Also here.
Comment #333
markhalliwellThat hasn't been true for years.
Per https://www.drupal.org/irc/adding-channel
The DA/infra has always been the "end point" for all IRC related things. Yes, there are admins (ops), but the DA/infra "own" most of the #drupal-* related channels (drupalircowner).
Never mind the fairly recent Druplicon -> Drupalbot drama and now the explicit "banning" of Matrix bridges ^^^
One cannot claim to have no stake in the matter and then simply impose a unilateral decision that affects our entire community like this and say they're "not in the business"... DA/infra is very much in the center of it all.
This, amongst many others, is part of the reason why this whole issue exists in the first place:
Finding a better solution for everyone, even for DA/infra.
Comment #334
hestenetHello everyone, I can appreciate here that many people are very frustrated and are doing their best right now to communicate in a respectful way. I very much appreciate that and encourage us all to continue that to the best of our ability.
There are two additional elements here that I think have made this more contentious and more unexpectedly disruptive than I think the IRC admins in general and other concerned parties thought it would be.
Until now that's mostly been a point of convenience and consistency - and not really contentious because it simply helped all these local communities manage those communities in a consistent way, with help from the existing irc admins, and for any new users to join those channels to understand that anything they join in the drupal-* namespace follows the same namespace.
In this case---- bridging for one of these channels was enabled almost as soon as the channel was created, without the knowledge of the majority of IRC admins.
To be completely clear - until 2 days ago my understanding was that there was no bridging set up until the request for #drupal-in in the issue queues. I have only recently learned that it was set up in many other channels without issues being opened, and without consultation of the majority of IRC admins.
^^ This kind of situation is what has lead to other communities banning bridging in official channels, like the ##techsupport community, for example.
That said... it is not the fault of the majority of people in the #drupal-pt community who used these bridging solutions. They had no way of knowing they were set up without the knowledge of most of the IRC admin group. And the disruption they are experiencing is real.
I propose the following:
TLDR - We'd like to put in place configuration to allow Matrix to work as a IRC client/bouncer, to resolve the disruption this caused to the #drupal-pt community. It will not allow any of the additional features that matrix provides that could create 'plumbed' style bridges, which is where all the unresolved concerns of this issue are hung up.
These changes will hopefully be in place by Tuesday afternoon, pending time of both IRC and Matrix admins.
@freelock, @lpalgarvio, et al -- I hope this resolves the immediate disruption? At the very least it should let us slow down and stop making panic decisions.
In the medium to long term, if this solution does not work for the #drupal-pt community we can forward the existing drupal-pt channel to a new channel completely in the Portugal community's control, not overseen by us. However, I would like to keep the drupal-* namespace consistent, just so we can keep on top of managing it.
Comment #335
freelock@hestenet thank you for listening and taking our concerns seriously. Using the "portal" bridge only is fine by me, and makes it so I can actually participate in IRC, instead of being effectively banned. I was using it happily and effectively for the past 2 years.
The only reason I got behind the efforts to "plumb" the bridges in the first place is because I think open source projects should use open source infrastructure, and this was an easy first step to bring the community back together again -- a community that has been ruptured by the introduction of Slack. While there may be a bunch of people using Slack, there's a lot of us for which that is not an acceptable solution, and Matrix seems like an easy solution to this problem. I still think that's the case, and will continue to advocate for that... but for the time being, restoring at least the portal bridge works for me.
Comment #336
mlhess CreditAttribution: mlhess as a volunteer commented+1 to the above, thank you for putting this into words.
The work to do that is being tracked in #2906243: Allow matrix users to use matrix as an IRC bouncer client
Comment #337
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedthank you for the proposed resolution hestenet.
I've commented in the drupal-pt issue, without reading fully this thread.
anyways, i can't comment further at this moment, but i might do later or tomorrow.
Comment #338
hestenetNo problem @lpalgarvio - I know you're very passionate about protecting your local community. :)
Comment #339
ciss CreditAttribution: ciss as a volunteer commentedDo we have the means to quantify active users (or user activity) across the Drupal channels on Slack? 3800 users seems somewhat high - given the activity i saw I would assume that number includes any user that has joined one of these channels at least once at some time (without signing out afterwards).
Comment #340
frobI am not sure where the 3800 number came from. My view of analytics show it much much much lower. The highest loggedin users in a day is 843 on August 30th. It seems to float in the high to mid 600 to low 700 mostly during the week. With that number dropping to around 200 for users actually sending messages.
That is unless I am looking at the wrong number. These look like the number of users sending messages on any given day.
Comment #341
davidhernandezThat is daily activity, though I don't know what counts as activity. Number of registered users is 4550.
Comment #342
frobThe more number of people sending messages floats around 200. Is there any way to get this stat from IRC? This is the general room of slack that I got these numbers from.
The total number of nicks in #drupal right now is 278, that is that I can see.
The important thing is to get actual comparable stats. So to compare that 4550 we would need to know how many people ever logged onto IRC ever. That isn't a valuable comparison and is likely impossible to get.
For example, as soon as I heard there was a drupal slack I parked my nick. I never had any intention of using slack, but I wanted to make sure no one else took my nick. This means that I am counted among that 4550 number, but I don't use slack.
Comment #343
freelock470,482 messages sent, and stored by Slack. Of which 460,482 of those are only accessible by a third party (internal Slack admins), not even viewable by Drupal admins. Sad.
Next I wonder if it will shut down access when the number of registered users hits 5000, like it did for FreeCodeCamp.
But by far the most complete essay detailing why Slack is so bad for open source is here: http://www.pdfernhout.net/reasons-not-to-use-slack-for-free-software-dev... . Very much worth a read. And it even mentions this very Drupal issue. Choice quote here:
Comment #344
ciss CreditAttribution: ciss as a volunteer commentednetsplit.de frequently logs joined users (although for whatever reason #drupal is missing). From personal experience the amount of idling users on IRC is very high. To get reliable stats I can only think of two options:
I agree that some hard numbers would help to get a better picture of the current state of fragmentation. One of the questions I consider most important at present is where new users currently try to get in touch with the community:
I have no idea where Matrix fits in. Someone else will have to fill in those blanks.
Comment #345
geerlingguy CreditAttribution: geerlingguy commentedNot sure if you were intending this to be a dig at the Matrix bridging, the Slack community, or both... but I just wanted to note that I'm one of the 4,000+ lurkers in Slack, not because I want to be, but because maybe 1/3 of the time someone wants to ping me on a contrib issue, it's annoyingly inside Slack.
Slack feels great for smaller, focused communities (e.g. Regional user groups, small office groups), but one of the best aspects of IRC is that through using it for #drupal-*, I also found tons of other great OSS communities like #docker, #ansible, and many others (all one /join away). It would be a shame to jump ship to Drupal Slack island.
Comment #346
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commentedComment #347
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commentedUpdated the links so they point to the #freenode native rooms instead of the ones using the IRC integration.
Comment #348
dqd@webchick
I feel with you,
so I got a rhyme for you:
it's too late ...
it is a quite long debate
It seems to be Drupals fate
already hitting number #348 ...
Sorry, not my native tongue :) (just a little joke for the weekend) ... Wow, we are already on page 2 of comments? The discussion becomes absurd. There are percieved more users being in the chat discussion than actually being in the chats...o.O
@geerlingguy Good point.
Comment #349
betz CreditAttribution: betz commentedWe had a Chat BOF here at the Belgium DrupalCamp yesterday.
Joined where people behind the rocket.chat and matrix initiatives.
One conclusion was to work bottom up.
Get the local communities bridged on different platforms.
Comment #350
jbitdrop CreditAttribution: jbitdrop as a volunteer commented@betz, can you elaborate a little bit more on "bottom up"? Do I misapprehend it? It reads kind of "Local communities would like to do their own thing"... Shouldn't there be a consens on all levels before changing anything on local communities? How many people of how many local communities have agreed on that (approximately)
@diqidoq: heh. :) yeah some more relaxing at this issue could be healthy ...
@webchick: From what I understand of your comment,
We have no real mechanism yet to force unique Drupal user identities on the other chat solutions to prevent misuse of Drupal nick names? Doesn't this also affect the logs? This would also make Drupalbot messages and commands like seen userxxx useless. Doesn't it?
Comment #351
betz CreditAttribution: betz commented@jbitdrop yes, bottom up.
Local communities are unrelated to the main infrastructure. And offcoarse we need permission to do so, but that seems easier to reach for now.
Many communities are bridged already...
Comment #352
dqd@betz: I see some issues raising here. As already stated: What about the Drupal bots? And what about the stated questions regarding unique user identity, security and chat logs? I see some clutter coming up here soon and this can possibly seperate the communities a lot. How does these bridges work? Could somebody else try to be me there? And can I see the bridged users from my POV when I am logged in on IRC only, but they are logged in on rocket only? Or only the other way around? I am still curious if this will be a future prooved effort.
Comment #353
Greg BoggsThat's a lot of questions in a paragraph, but I think I know some answers for you so...
If we set up bridging, then:
To reiterate, some of the bigger concerns expressed are:
1. Bridged users don't display in Slack until they speak. For big channels, this is not a big deal but for smaller ones, it's quite strange.
2. If bridges are set up, there are now 3 services where you can register a nick: Freenode Matrix and Slack. Currently, we only have 2 places you must register to protect your nick.
3. A few folks are worried about adding people from Slack to Freenode without express warning to those people.
4. The Drupal Association staff aren't currently resourced for running Matrix servers.
5. We don't generally trust the RIOT folks as much as we trust Slack or Freenode.
Comment #354
freelockSome clarifications re: Greg Boggs's post...
Log visibility is defined per room. Due to an agreement between Matrix and Freenode, the current "Portal" bridges are required to be created by the bridge, and restricted to only show history to people "since they joined the room" and "no guest access" on the Matrix side.
If a room is "plumbed" with a bridge (which requires IRC ops), these visibility and guest settings may be changed, and also other bridges may be added to the same room (Slack, gitter, etc). Room visibility settings are visible to all Matrix users. Other settings include make all history visible to all registered members, visible to anyone (including guests), or visible to members since they were invited. Changing history visibility only affects visibility of messages sent after the visibility change -- so you cannot make older messages public that were sent when a room only allowed message visibility after a member has joined.
Well, not quite. Matrix is decentralized, and there are several thousand "homeservers" already. I run my own Matrix server, as do many of us in this thread. You don't need an account on the matrix.org homeserver, although most people start there. It's much more like email -- you have a domain part and a local part (although the syntax is flipped -- I'm @john:matrix.freelock.com for example). What's more, you have two different things: a "Matrix ID" aka mxid, which is meant to be hidden, cannot be changed or spoofed, and is only shown for disambiguation (unless you go looking for it); and "Display name" which you can set to anything, and there's no restriction saying it needs to be unique within a room or anywhere else.
For bridging, this depends on the bridge -- from within Matrix you can set your IRC nick with freenode, and register it as usual, doesn't need to have anything to do with your MXID -- it's just like any other IRC client. For Slack, it shows the bot user as the Slack account, and your display name and avatar from Matrix.
This I really don't understand. Why is Slack considered more trustworthy than Riot? Riot and Matrix has a very public development process, much like Drupal. Every developer is known, you can reach out and talk to them, see all their commits. They have gone through a rigorous third party audit validating their end-to-end encryption. Why on earth would you trust a closed, proprietary shop where you cannot see the source code at all, over a fully open source, fully visible codebase? Do you even know who develops Slack?
This is the single biggest reason there's a large number of us that think Slack is entirely inappropriate for Drupal, especially when there are multiple compelling open source alternatives.
Comment #355
Greg BoggsI can't speak for why people trust Slack. If I had to guess, I would say that the Slack brand is well known, it's used by millions of people, and many people are required to use it already for work. So, they are familiar with it. Contrasting Slack which everyone has heard of to Matrix and RIOT which is something they haven't heard of before, the difference is pretty noticeable.
Comment #356
kevinquillen CreditAttribution: kevinquillen at Velir commentedI would rather have a chat system that has SSO to drupal.org account and optional 2FA, than to not have it. To get that with Slack, the cost would be astronomical.
At least with Riot/Matrix you can run it in-house and control the rules, whereas Slack could decide to cut our community off whenever it feels like it (this has happened). But I don't see where Riot/Matrix offer SSO/2FA authentication capability (so we know who is who), but perhaps I am looking in the wrong area. I think after all the events of this year, and the importance of security in the days to come, those two things are very important.
Comment #357
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedThe Drupal Portugal community is fully bridged again.
Telegram, Matrix, IRC, Gitter, with RSS feeds from our website and twitter, and notifications from GitHub.
Comment #358
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedA separate channel for association and management related topics is partially bridged as well.
Comment #359
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedIdeally now we would have a full bridge in place between Telegram and Matrix, as well as posting directly from our website to Facebook and Twitter (and no need to get RSS from these) but this will have to wait a little longer.
We dropped support for Hangouts and Slack. No bridge, no support.
Comment #360
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedWe are also moving our data from Google Drive into our git repositories at GitHub, because Google keeps axing and changing their services and terms of services. We will keep it at a minimum or discontinue it completely.
Our GitHub repositories are also in sync with copies on GitLab, and these are linked to the hosting solution for auto-deployment.
Comment #361
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedAlso without any kind of integration at the moment: meetup.com / eventbrite.com, which we rely on for publishing and managing events (with proper registration and payment if required) for small and larger events, such as meetups, days and camps.
If you are curious:
- https://github.com/drupalportugal
- http://drupal-pt.org/pt/participa-na-nossa-comunidade
- https://www.meetup.com/pt-BR/drupalportugal/
Comment #362
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedComment #363
dqdSo for the protocol another short summary with question mark to all the criteria we should agree on here
(Most of the discussion participants already follow that, but it can get out focus soon by reading the whole thang, that's why.):
When we look at this ^ table, then it becomes clear, why this discussion escalated a bit. But we should cheer up on this positively. It also shows off, that many care of chatting with each other for Drupal. That's a good thing. At least for those who care about contact. A large community can become anonymously very fast. We only should follow these steps above and should try to move out all misinformation on protocols etc. and should replace it with useful informations. And sources should be independent, not biased nor from the protocol/client developers itself.
And last but not least a statement you will tarring and feathering me for: We should not be forced to decide for a not so good solution only because some local communities use them already, sorry. That should not be the most important criterion here. That's why I agree with @jbitdrop on worrying a lil' bit about the "From the bottom up" attempt.
Comment #364
webchickI think those are all lovely criteria, except the evidence of the community moving en masse to Slack doesn't bear them out. It appears the vast majority of the community cares a lot more about a seamless chat experience than any of those criteria, and since most people are already using Slack within their organizations, putting Drupal Slack just a tab away, Slack is basically going to win here every single time until the tide shifts to something else. :\
Comment #365
rodrigoaguilera@webchick
That sounds a bit defeatist.
Can't Drupal as a free software project help to change that tide?
If people follow the criteria that you are mentioning is it worth it to develop free software anymore?
Personally I was introduced to Slack by members of the Drupal community to participate in conversations that only happened in Slack and that happening for a free software community made me sad.
I read news today about Slack stopping being monolingual and reminded me of Dries and @enzo talking about welcoming non-english speakers and I feel that is another point to be considered.
I also realized that I lost access all my private messages on Slack for the Drupal team. I feel this only should be one reason to stop bringing new people to Slack. Bridges are a nice transition for that.
Comment #366
freelock@webchick these are broad assertions that carry with them a bunch of implicit problems.
What part of the community are you leaving behind, by moving to Slack? Your most ardent open source advocates. Is that wise for an open source project?
This is an area Drupal has been hugely better than WordPress, and now you're abandoning those principles, going into a silo, and sharding the community into free vs. non-free. What's next, a bunch of competing modules instead of coming together on best of breed solutions?
That sounds like a real dig at the UX of chat solutions it sounds like you haven't even tried.
Slack is far from seamless if you need a separate login for each Slack team, have to do all this switching all the time... if you want seamless, give Riot a try, it can unify all your chat (which is why it's the only chat I use these days).
That's a wildly unsubstantiated argument. Again I wonder, have you asked who you're leaving behind by this decision?
Sad. Just sad. We've offered a solution where everybody wins, where people can use their chat platform of choice and not be excluded from the conversation, but the DA has made it clear they prefer tight control on public chats and forcing proprietary solutions down your throat if you want to participate, instead of having an open, inviting, easy way to participate with the broader community.
Comment #367
webchickOnce again, I'm not pro-"leaving behind" anyone. I'm pro-Free Software. I've dedicated 12 years of my life to churning out GPL code. I contribute on Drupal.org and not GitHub. Etc.
I'm just. stating. facts. I'm really not sure why some people in this conversation are getting so defensive about facts.
Comment #368
freelockWait, what?
I don't care what you use for your job. I care about what tools the supposedly open source Drupal community mandates using, to talk with the rest of the community. Two entirely different things.
There are very real costs to using Slack -- and if you're not paying them, who is? At the moment, unless somebody's paying Slack, you're just free-riders on Slack's infrastructure, and Slack has made it quite clear that having huge open source communities free-riding on their infrastructure is nowhere in their business plans. And lots of large communities have had trouble beyond a certain threshold we're fast approaching. Why even go there?
Matrix, and Freenode, very much have supporting open source communities in their business plans... and Matrix makes it really easy to self-host.
But... facts? What's the overlap between Slack users and Drupal users? Are you asserting that all Drupal developers have to use Slack for work? Since when? That's news to me.
There's lots of other silo'd communication platforms out there. Microsoft has one. Atlassian has a new one. Github has one. Facebook has two or three. Google has a dozen.
Only Matrix is trying to make it possible for you to stay on Slack, or whatever silo you choose, and communicate with people in other silos.
I completely disagree. By blocking bridges to other chat platforms, the DA is very much mandating and asserting control over the Drupal chat infrastructure. Just ask the Drupal Portugal folks whether they have control, or you do. And thus you're acting as protectionists, preventing the open exchange of ideas across platforms, and blessing the conversations happening on Slack to the detriment of all other platforms.
You (the DA) have taken a stand here, like it or not, while pretending to have no responsibility whatsoever. Please.
I have yet to see how privacy and security is compromised in any way by adding bridges to what are supposed to be public rooms. There is no leak of email addresses, only the IRC nicks or Slack usernames. These are supposed to be public forums, right? Anybody can still create private rooms wherever they want, nobody's trying to stop that. The bridges don't bridge all of Slack -- only designated rooms. Bans and kicks can still be employed to deal with abuse. Impersonation seems to be the big concern, and yet there can be/has already been impersonation on Slack and IRC too -- Matrix does not make this problem worse.
But that's exactly what you're doing.
Comment #369
webchickI'm not sure it's useful to continue this conversation, since we've been going around in circles for awhile.
I'm not part of the DA. I'm not pro-Slack. I'm an observer of community interactions, and reporting back what I'm observing.
@hestenet is part of the DA, and has asked that we revisit this conversation once developer tools improvements (the current DA priority) is done.
Seems reasonable to me.
Comment #370
frob@webchick++
Lets let this simmer until that done.
Comment #371
NWOM CreditAttribution: NWOM commentedAfter following along in this conversation for the past few months now, both sides of the equation make absolute sense in my opinion. I figured I'd maybe provide my own insight as well coming from perhaps a support oriented perspective.
On one side of the coin, the community is already transitioning to a new system regardless of whether we are ready or not. So with this in mind, more options are potentially necessary right off the bat, whether it is a closed source or open source solution, especially since the community has already unofficially chosen a closed source solution.
On the other side, we might be delaying the inevitable, and might just want to start off with an open source solution from the get-go which may be a bigger time investment, however it caters more towards the end-goal.
-------
However as it stands with Slack currently in-use, it adds its own limitations to the equation as well. None of the text is currently being indexed or archived, like it is currently on IRC.
Also, I am of the opinion that with these more easily accessible solutions like Slack and Discord providing a more easy-to-use IRC equivalent form of communication; it is very likely that #support related queries will also increase on the "Slack/Discord" front; rather than via the current form of stack exchange tips, support issue threads, and IRC #support, which can all be searched via search engines.
I propose that we first deal with the situation as it is now, and setup an indexer to at least the #support side of slack. We would have more flexibility to then choose either an open source or closed source solution and can migrate the text afterwards.
Comment #372
dqd@ #365
No, its sounds concerned, caring and worried...
... Because of such things ...
... proving that she is right.
@webchick++
As larger as a community gets as harder it will become to bring them all on one table to really make farsighted and smart decisions. Emotions and other gossip gets easier in the way than smart decisions are able to be made soon and can fastly become a snowslide. That's why I would love to see some more self-irony and smiles in all of our faces when looking in the mirror. And all community members being longer than a decade in Open Source communities know about these dangerous dynamics. So her worries are proven. We should really focus on Drupal and ask ourself how Drupal was able to become such a great project over such a long time and should put our own POV's a lil' bit on the side and should not overweight our own "things we believe to be right about". Ask yourself: If this would be such an important issue really, then, how has Drupal made it for so long without it? It's not meant future denying, but meant as a call for not letting it become a hot potato in all our hands.
Errm, ok ... I maybe lost a lil' bit focus here as well ... it's maybe because I listen to Rachmaninov while typing this ... :p ...
Comment #373
lightweight CreditAttribution: lightweight commentedI've been doing Drupal for over a decade, and I've been watching other free and open source communities (Mozilla and Creative Commons) adopting Slack as a community messaging technology, and it saddens me deeply. I'm especially disappointed to see the leadership of those communities (and Drupal) advocating for using a fully closed technology to promote an open community. It's starting the slide towards fauxpen. This trend needs to stop. I've written a brief post explaining the problem: https://davelane.nz/arresting-slide-open-fauxpen I will abandon this community if the leadership does not recognise the need to be prefigurative - using means consistent with the aim of maintaining a thriving open community.
Fine by me to support Slack as an alternative to a FOSS option, and all the FOSS ones have a "SlackBridge" functionality for those whose desktop is already afflicted with a Slackclient, but the first class solution needs to be FOSS.
Comment #374
dqd@lightweight, errm, that's exactly this kind of emotional sayings I Iwas talking about. Let's please calm down and let's have a relaxed and mature talk about a way out of this ..., well, quite secondary issue here... We should not fire such big words in situations where this is far too much for the actually issue. It's about a freaking chat protocol man, not about an unfixable core bug ...
Comment #375
wizonesolutionsZulip's Twitter account told me that they offer fully-functional accounts for open source projects: https://twitter.com/zulip/status/909177760106536961
We last looked at Zulip a couple years ago. Perhaps the experience has gotten better since that time, and it warrants another look? I haven't looked at it myself. A half-joke tweet about Slack, the message limit, and my verbose rubber ducking just turned into an unexpected conversation about this thread :) (hi @lightweight)
Comment #376
lightweight CreditAttribution: lightweight commentedGiven that most hosted solutions use a per-seat cost model, e.g. Slack's, for a huge and growing community like Drupal, it makes sense to host your own open source messaging option (or pay someone a fixed amount to do it) so that your scaling cost is far more tractable, and grows with infrastructure requirements (which will surely be a far more favourable cost/participant ratio), not based on some arbitrary per-user model. A per-user model is a significant cost risk if the community continues growing. (howdy @wizeonesolutions :) )
Update: ah, I see that some enterprising Drupalers in the EU have already set up a Rocket.Chat - joined that already. Sounds like it'll scale to meet the community's needs, without the price tag. I'd be very surprised if a community as valuable as Drupal didn't get sponsored hosting capacity thrown at it by enthusiastic providers.
Comment #377
freelockNew blog post from Matrix.org, where they have addressed some phishing and spam concerns of some other open source crypto-currency communities: https://matrix.org/blog/2017/09/19/matrix-riot-for-cryptocurrency-commun... ... this allows people to set up a Matrix server that can block non-trusted DM invitations for its users...
Comment #378
Alex MalkovSome history of slack-chat became paid. See the screenshot https://seafile.93323.ru/thumbnail/3ed17aab66934fbfa477/1024/2017-09-20-...
Comment #379
kevinquillen CreditAttribution: kevinquillen at Velir commentedYes, it is a rolling 10k message history limit. We hit this limit fairly fast last year with 120 people (across ~70 chat rooms in our org). Now we pay for Slack, and it costs us about $12k a year, which I find expensive for a fairly low amount of people. Having been through the ringer with a lot of chat platforms (yet to try Riot/Matrix), free Slack doesn't really solve anything except lower the barrier of entry to get into the app, and then there are paywalls everywhere.
Comment #380
ekes CreditAttribution: ekes as a volunteer commentedI'm guessing this is the issue that got riot.im client partly banned from #drupal-* channels on Freenode so I'll note this here:
At Drupalcon I've now had to help several people who use riot as their IRC client. I'm not sure they are even aware of the differences about Matrix and Freenode, and certainly don't know about the ins-and-outs of this discussion.
It is deeply unfriendly for first time sprinters to get a 'Banned' notice when they try and join the IRC channel, it's also quite confusing. Explaining registering a nick, or changing to remove the [m] doesn't really help. I had a new contributor who had ended up installing another IRC client, on top of riot that they normally use, just to get into IRC because they didn't understand.
Comment #381
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commentedYou are right @ekes and i think any filtering right now doesn't make any sense anymore after our BoF session.
I'm asking to please remove the filtering from drupal-* channels. There are have been also cases of Drupal local communities wanting to use their own channel the way they want like Drupal-pt, Drupal-in and few others. They have that right. So let's remove the filters. This enforcing of security is going way above what a chat platform needs to work well and is making hard for people to contribute to the community, as @ekes said.
In the BoF in Vienna there was a strategy defined. I've updated: https://www.drupal.org/node/2905534 with meeting notes and next steps
Comment #382
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedLetting everyone know of the discussions on the Community Summit and the BOF session at the DrupalCon Vienna, followed by some progress.
This was heavily debated and consensus was achieved with the people present (about 14 people).
Consult the document here - https://etherpad.openstack.org/p/drupal-chat-bof
Additional info - https://drive.google.com/drive/folders/0B-39hK-7nJXKTHpLbkRnd1lKR2s
We are currently working on PoC of Matrix and Rocket.Chat servers, supported by community members (floris, lpalgarvio, betz and ekes).
Bridges may be addressed in the near future, as well as SSO authentication against drupal.org.
All these are experimental and controlled, and will be reviewed periodically.
The objective is to research and then reach conclusions before eventually a decision is made. Any decision that implies costs will probably have sponsors behind, and there is already parties interested.
Problems:
It is evident there are problems to address with the current "official" implementation in IRC. Citing a few:
The same is valid for the "unofficial" implementation of Slack. Citing a few:
Solutions:
Concerns:
You may try these servers here:
Rocket.Chat - https://drupalchat.eu/
Matrix - https://drupalch.at/
Comment #383
hestenetI wanted to post a follow up here after several excellent discussions that have taken place: in person at DrupalCon sprints and in the chat BoF(thank you for posting notes @lpalgarvio), online, and by video conference with the current IRC admins.
The Birds of a Feather session at DrupalCon Vienna was a good reminder that the hardest problems to solve are the human ones, not the technical ones, and these are the problems that most require empathy and collaboration in the spirit of open source.
The fundamental problem that people on all sides of this issue want to solve is this:
People have a variety of preferences in communication mechanisms, with diverse motivations rooted in free software advocacy, privacy and security concerns, or the powerful convenience of using tools that are already central to their daily workflow.
If necessary, a decentralized communication channels are okay - but forking communication, and thus our community, is not.
One of the only ways to achieve decentralized communication without forking is through a bridging solution- as was initially proposed here, but several members of the community raised serious concerns having to do with identity/impersonation, notification of bridging, moderating across multiple platforms, and more.
Fortunately, following DrupalCon and several other conversations I believe we've created a roadmap that should help resolve these issues:
Identity/Impersonation protection
Notification
Moderation
Configuration management
Most of these issues are technical ones that can be resolved with the help of users in our community who are experienced with Matrix as a tool and can create patches to fix the underlying issues, or perhaps with the help of the Matrix team. Some of these issues are matters of policy.
For all of these, we should document our direction as we go in the issue queues, as well as the use cases that motivate each element.
Because this issue has become so unwieldy, I propose that we close this current issue, and open a new one in a dedicated issue queue, with the steps outlined above in the issue summary as our roadmap to advance the use of Matrix for bridging IRC. The infra team may also review other chat platforms that are in use by various regional communities and create a list like the one above for evaluating/integrating those as well.
Here is the project we've created for resolving the issues above, and hopefully move forward with Matrix bridging: https://www.drupal.org/project/matrixchat
I've created a meta issue in that project for resolving the Matrix-specific issues: #2916635: [meta] Issues to be resolved to enable Matrix bridging with IRC
Comment #384
ricardoamaro CreditAttribution: ricardoamaro as a volunteer and at Acquia commentedThanks @hestenet
I thinks this is great feedback. I personally agree on all the points and let's move forward with Matrix bridging: https://www.drupal.org/project/matrixchat
Comment #385
dqdValuably and extensively written summaries and info sheets, @lpalgarvio @hestenet. Thanks for the hard work on this and all the empathic concerns and conversations you followed, merged and reported back in a forward thinking and postive/constructive manner. Sadly not all of who have concerns were able to join your offline discussions, but your representation seems sensitive and well done.
One thing I would like to add to the well formed and forward thinking concern here: "If necessary, a decentralized communication channels are okay - but forking communication, and thus our community, is not." is that the first Okay is caused by the reality of "Changes in the landscape of online chat options are fragmenting the community and community conversation." and therefore it is inevitably required to nitpick on a still existing and resilient low level entry for all community members via IRC being able to communicate with all others (the bridged ones) without additional tools required the same way it used to be. I know it's implemented in your "round-ups" actually, but I felt the need to highlight it one more time.
TL;DR: "new features should not break old features", IRC is still THE chat solution for many Open Source communities and should keep being the "bottom" from where we add new on top.
P.S. Is "(Works as designed)" the right status?
Comment #386
colanI believe this is the better status.
#380: The issue for that is #2906243: Allow matrix users to use matrix as an IRC bouncer client.
Comment #387
frobHonestly I think "fixed" is the correct status, but "outdated" works too. The goal of this issue was to "Evaluate whether to replace drupal IRC" and I think we did that and now we have a plan to modernize. Way to go everyone! :)
Comment #388
colanHere you go!
Comment #389
fuzzy76 CreditAttribution: fuzzy76 commentedWhile these are great principles, I fear you are effectively raising the bar for bridging so high that no bridge will satisfy the requirements without a lot of development (which I predict won't happen). These changes require a node.js developer that somehow want to do a lot of work to satisfy a PHP community.
Comment #390
dqd@fuzzy76: Who is "you"? Can you refer to a post you answer to? Here are many thoughts in it. And your solution? Or are you advocating for lowering the "principles"? Which would - if you mean what I think you mean - turn many away from new chat implementations. Including me. Like many, I am involved in many different Open Source development communities and I am absolutely fine with IRC but accept new implementations and contributing to them, if the community wants it. But I won't follow on the edge.
Comment #391
fuzzy76 CreditAttribution: fuzzy76 commented@diqidoq By "you" I am referring to the consensus expressed by @hestenet in #383. I think the requirements set require us to write our own chat bridges (or atleast contribute heavily to an exising one), which I doubt will happen. Drupal has this tendency of amassing requirements through bikeshedding which ends up preventing adoption of practices from elsewhere.
Comment #393
matthieuscarset CreditAttribution: matthieuscarset as a volunteer and at Appnovation for Appnovation commentedThere are only 53 responses to Surveymonkey... not really sure those results represent our community ! :|
Comment #394
dasjoSorry I don't fully understand what the decision was at the end of this issue. Could someone point me to the next steps? Thanks!
I just came across this again, because at a DrupalCamp in Germany, the local communities decided they want to go away from Slack and move to DrupalChat.eu as the central place for chat communication.
Comment #395
andypost@dasjo I think it makes sense to create follow-up about https://drupalchat.eu/home and it's rules, registration and probably integration with Matrix https://github.com/matrix-org/matrix-appservice-rocketchat
IMO RocketChat is very nice tool! I using it more then year without issues
Comment #396
dasjoThanks for that andypost. I have created a brief follow up #2954073: Promote Rocket Chat instance as an alternative to Slack