4 ms·
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
by buserror 11y ago
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
- cdent 11y agoa) 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.
- buserror 11y agoWell 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 ;-))