3 ms·
> The author doesn't equate them - they even list many critical things that Slack has that IRC doesn't. Which makes their conclusion even more silly. After rea
by rumanator 7y ago
> The author doesn't equate them - they even list many critical things that Slack has that IRC doesn't. Which makes their conclusion even more silly.
After reading the article I feel you're misrepresenting what the author actually said.
The author lists a number of problems with Slack that in his opinion renders it "not a tool built for open source projects to use for communication with their userbase", and instead Slack is "a tool built for teams".
The author stresses that communicating with a community leads to entirely different usecases, and that "Slack has gone on record as saying that it cannot support this sort of use-case".
Afterwards, the author proposes IRC as a technology that mitigates some of the design problems that render Slack ill-suited for communicating with the userbase of open source projects.
The author enumerates arguments (technical and not so technical) to support his thesis. You've ignored them all.
- chrisseaton 7y ago> I feel you're misrepresenting what the author actually said There's literally a section called 'Problems with IRC that Slack solves'. And there's no 'but...' at the end of that section. It's just a list of things Slack solves. Maybe that's why people want to use it? It solves their problems? > The author enumerates arguments (technical and not so technical) to support his thesis. You've ignored them all. I think you've misread my comment or the thread. I wasn't providing a critique of their points... I was responding to the idea that they were equating them. They weren't - as you said, they have a list of ways they thinks IRC is better, and a list of ways they think Slack is better. So they weren't equating them.