Author doesn't grok IRC. By /definition/ IRC is 'mostly idling' on most open source channel. It can be bursty, but most of the time you come to the channel once a day to read the log, or send a couple of question that you might get an answer to when someone wakes up.
If there is more traffic than this, it's unmanageable for development purpose; but it would also apply to many other chat systems anyway.
It's still a LOT better than skype chat and all the other 'answer me NOW' systems
a) I (the author) am making reference to the impact of bouncers with IRC in OpenStack projects. The error, if there is one, is perhaps that both my posting and the one I reference in the first paragraph are trying to generalize from experience in OpenStack that is not normal. In OpenStack the channels are _not_ 'mostly idling' and that is entirely the problem.
b) It's true that when I started using IRC about 15 years or so ago, I was coming to the game a bit late, at least relative to other internet services I'd used and the age of IRC. I hope since then that I've managed to catch on, but maybe not.
Well then perhaps the point you might have clarified is that a noisy IRC channel is the problem all along -- perhaps it'd be better to split it into 2, perhaps for 'core' dev and one for 'user' or something.
I hope you didn't take offence to my comment, if you read it with my 'idling' point of view, you can see why I was shaking my head when reading -- getting /anything/ done on a noisy channel is completely useless -on any chat system- unless you explicitly give Voice on request...
I my experience, quietish IRC channels are fantastic, I'm on about 20 of them, 24/7 (or so it appears to everyone ;-))
If there is more traffic than this, it's unmanageable for development purpose; but it would also apply to many other chat systems anyway.
It's still a LOT better than skype chat and all the other 'answer me NOW' systems