5 ms·
Persistent IRC Considered Harmful
- cmsj 11y agoStrongly disagree. Persistent IRC is hugely valuable. Issues with notifications in particular, speak more to your discipline than the technology - no different to getting email notifications.
- acveilleux 11y agoIt's one thing inside a company. It's another in the open-source world where it's a great way to foster an in-crowd and exclude everyone else.
- baldfat 11y agoTo me Slack and the likes are just glorified pretty IRC.
- acveilleux 11y agoSlack at least keeps an history so you can go back and read the transcript of a conversation you missed that was important. With IRC, you're completely cut out unless it's in your client's buffer.
- pavel_lishin 11y agoIsn't that one of the things that a good bouncer can do for you? I've checked the logs in my IRC channels on plenty of occasions when the last-30 scrollback wasn't sufficient.
- apetresc 11y agoHence the logging solutions everyone is mentioning, yet the article criticizes. So, having logging is bad for IRC because it excludes people because... there aren't any logs? What?
- joezydeco 11y agoI'm on a IRC channel that has been running constantly for over 15 years now. We wrote ourselves a logging bot. It was nice for a while, until people started reading scrollback and picking up conversations about themselves that weren't always pretty. Sometimes you need to vent, other times you just want to talk candidly. The consensus was that IRC should be approached like a conference room. If you're there, you can listen. If you're not, you don't get to bug the room. Wasn't the optimal solution (the scrollback and link capture was extremely useful at times), but that's the way it went.
- lmm 11y agoIf all your project design happens in conference rooms that can be pretty bad. In five years' time people will have no idea why or how a particular decision was taken.
- Karunamon 11y agoSerious question: Is anyone actually able to point to a five years old conversation when trying to understand why a decision was made in most any projects out there today?
- lmm 11y agoI can't check how far back they go right now (site blocked where I am), but yes, I've found IRC logs from a number of years ago useful when trying to understand parts of a couple of OSS projects I contribute to.
- Karunamon 11y agoHuh. This is a resource I'd never considered, then. I've always thought IRC conversations to be mostly ephemeral.
- 91bananas 11y agoSimple solution, don't vent about people in public channels where they may be able to see it. [0] Be a normal person and talk behind their back when you get home [0]http://www.anyclip.com/movies/bridesmaids/lillian-and-annies-big-fight/#!quotes/ http://www.anyclip.com/movies/bridesmaids/lillian-and-annies...
- pen2l 11y agoSomewhat related: someone please suggest an ssh client app for the iphone! (So I can persistently irc)
- baldfat 11y agoPersonally I use Weechat and glowing-bear.org for my IRC and it works amazingly well.
- tokenizerrr 11y agoConsidered harmful by who? Why do my habits harm you? As someone who is persistently connected to about a dozen irc channels you don't come close to persuading me of why that is a bad idea for me to do so. I have no issues ignoring pings when I am busy, for example.
- woah 11y agoI have to disagree. I used to use irc in the way this article recommends. I then tried hipchat and slack, which really changed how I communicated because of their persistent nature. Now I use irccloud to get the same UX for irc. It's simply way more useful. Mailing list emails are a pain, and it is a delusion to think that they are somehow a more permanent record or something than irc logs. A project should be generating documentation if there needs to be a permanent record. Mailing list emails are a very poor substitute for persistent chat, and they are a very poor substitute for documentation. Also, the title is considered cliche.
- beefhash 11y agoPersonally, I believe this misses the point partially. The point of IRC with a bouncer is to have a way of combining synchronous (live chatting) with asynchronous communication (highlights and reading up logs). > What to do instead? Use IRC when you're actually there, leave when you're not. If you join IRC and you have a question for someone who is not there, send email to the project list (with a good subject!). Consider sending to the list even if the person who you think will be able to answer your question is present in IRC. Many small projects don't actually have a mailing list; the closest thing to it is some kind of issue tracker, which comes with its own set of problems. Additionally, e-mail incurs a seemingly heavy time penalty to send -- some kind of greeting and valediction always must be present. On IRC, doing so is amounts to almost wasting everyone's time if you have an issue to bring up. Of course, these kinds of cultural things vary between IRC channels, and these are just my two cents on this.
- sikhnerd 11y agoPretty much disagree entirely. I've found being in these open source channels 24/7 extremely valuable as have many others. Seems like the author is railing against the fact that dealing with notifications may be difficult, but luckily most IRC clients give you a ton of options on how/what/when you should receive them. I think even if you turn notifications off entirely, you will find some value to being in the same places as the developers of the software you use.
- adamors 11y agoThese "Considered Harmful" articles are so unsubstantial at this point that one could make the argument they are harmful.
- cdent 11y agoHi, original author. Reading the comments thus far (about 30 minutes in) it's like many haven't even read what I wrote. Sure, the title is cliched, that's on purpose. Sure, notification can be an issue, but I think I made it clear that that is a secondary issue. The primary issue is that the use of bouncers results in habits which result in the information being inaccessible to other people, other people who may not yet be able to decode the logs. In other words, to people who are saying "using a bouncer make my life easier": It's not about you. It's about making a conscious effort to make other people lives easier and make projects more accessible.
- pavel_lishin 11y agoCan you elaborate on your point about jargon? Your advice to avoid bouncers seems to be for the people who are in charge of the project - but those are the people who would be the most able to understand the jargon, and to skim the channel and understand what's happening in the middle of any given chunk of 100 lines.
- cdent 11y agoThe issue with jargon is only an issue if the the IRC logs are the primary place where information sharing is happening. It goes like this: If leaders™ are using bouncers and that use is reinforcing the habit of having all info exchange in IRC then, because IRC itself encourages the use of jargon (because it is conversational and personal), the logged information for the project will be very jargony. Mailing list postings, which are a bit more considered and more broadcast oriented, are less subject to the shortcutting that leads to jargon. Thus a mailing list posting ought to be easier to digest, at any time, by someone who is not as familiar with the jargon. So the issue here is not that the jargon makes this difficult for those leaders. Certainly they will be able to scan the logs for the hallmarks of the stuff that matters to them. That's exactly why jargon is useful...to them. It's not, however, useful to other people. This about keeping the open source projects, you know, open.
- sanxiyn 11y agoThe very reason mailing list posts are easier to read is because they are harder to write. That's why IRC explanations get written but mailing list posts (or wiki pages, or documents) do not get written.
- pavel_lishin 11y agoIf you're using a bouncer, it's trivial to set it up to change your nickname when you're not there. That clearly communicates that you're not present, but that you will respond in time. All the other points are kind of silly. You can say the exact same thing about email, or Slack/Hipchat, or SMS. > There are many reasons why one might consider this unfortunate—no opportunity to be truly away, frequent interruptions, an inflated sense of urgency, and a powerful sense of "oh noes, I'm missing what's happening on IRC!!!!"
- zwdr 11y ago>If you're using a bouncer, it's trivial to set it up to change your nickname when you're not there. This is a terrible way to communicate your absence. It's spammy, potentially confusing and, worst of all, imitates a built in functionality of IRC. The _only_ correct way to set an away status is IRCs builtin `away` message.
- pavel_lishin 11y agoWhere's that quote from? fwiw, I 100% disagree with it. Setting an away status is fine, but if I join a channel, it's not at all trivial for me to see who is away and who isn't (although, this may just be the way I have my client set up.)
- zwdr 11y agoWhat quote? And yes, in my opinion some IRC clients have suboptimal defaults or missing support for this. It's a shame, but changing your nick to emulate a built in IRC command is in no way a solution. Away is standard, and every client should support it. In the end it's a question of the channels rules, but spamming nick-changes is annoying-- especially because people use different formats and simple filtering won't catch all cases. In addition it also breaks queries and might change your identity from a trusted nick to one that could be... everyone. You're advocating using a hacky workaround that stems from client-side UI issues, instead of using a well-defined built in message. This just seems wrong to me, in every way.
- peterwwillis 11y agoAnecdotal: most of those in the open source, gamer, and hacker worlds have been using persistent IRC for decades without being harmed by it. It keeps people from having a social life, but other than that...
- buserror 11y agoAuthor 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 ;-))
- orliesaurus 11y agoIRC Chan logs bots and IRC Bouncers are helpful - totally disagree wth this article. Its the user experience that varies depending on the solution used but as someone who has been using both for 10+ years I find the ability to be always in the loop really really helpful :)
- daigoba66 11y agoI wonder if anyone has experience using mailing lists/listserv for regular business software development (ISV, in house, startup, consulting, etc.)? I know they're common, and work relatively well, for open source projects with decentralized teams. But I never really considered that it might be awesome for other types of software development. In particular, as I currently work for a consulting company. If all emails related to a project flowed through a mailing list then it could provide a nice and centralized spot for everyone, including people brought onto the project after the start, to reference and search past communication.
- xxpor 11y agoI kind of just assumed this is how most places worked. Not to the level of LKML or anything, but my team's mailing lists are sort of similar to python-dev (if not slightly more tactical).
- towb 11y agoI'm mostly in smaller channels, max 120 nicks. If someone joins a channel this size or smaller, it can take a while before someone comes around to answer a question. But when they do you will probably get your answer, and you are able to quickly ask some follow up questions if needed. And in the end I believe this often is a quicker way to solve a problem than asking on some forum or mailing list. And there is the room to be social with like minded people in every time zone. I think it works great this way. And if people leave the smaller channels when they are not around I'm afraid many of them would just die.
- dharma1 11y agoI've been using IRC for over 20 years, on and off, these days mostly for work. I also use Slack and Telegram daily (and both of these have persistence). I think built in persistence is hugely valuable, and together with that and IRC clients with up to date UI/UX are the key things IRC has been missing. Sure, you could use irccloud.com or something similar, but it still feels old school. IRC has pretty much been dying a slow death for mainstream users as other messaging apps took over. Considering Slack is now valued at $3b, yet is fundamentally IRC with persistence, nice UX and lots of integrations - I'm surprised the guy who originally wrote IRC - https://en.wikipedia.org/wiki/Jarkko_Oikarinen https://en.wikipedia.org/wiki/Jarkko_Oikarinen - didn't take it further or see the potential to raise funding for a commercial product more recently. I would also be interested in seeing some kind of completely decentralised persistent IM architecture, maybe using blockchain. This looks interesting https://matrix.org/ https://matrix.org/
- Torgo 11y agoOne size does not fit all. This applies equally to IRC lovers and haters.
- colindean 11y agoChat systems are meant to be ephemeral. The conversation goes away after a time. Logging makes history discoverable, but nothing yet has been able to provide an actionable summary of the transcript. Slack is getting toward it with its reactions feature, which could be employed consciously by users to mark lines for inclusion in some kind of daily/weekly summary log sent via email. IRC lacks this facility since it lacks a unique identifier for each line. It might be possible to repeat the line to a bot, though, but that seems messy and allows for significant duplication or alteration of what was said. I personally use irccloud.com for persistent IRC, but mostly for push notifications to my phone.
- xemdetia 11y agoIt's awkward that the author describes openstack, which is one of the few projects I am aware of that actually schedules meetings on IRC for discussions and debates (https://wiki.openstack.org/wiki/Meetings https://wiki.openstack.org/wiki/Meetings), quite literally to resolve issues where IRC doesn't work for them. Compare this to other projects/channel communities like #mysql, #postgres and #clojure where this doesn't happen, and all communications are ad-hoc. I agree with some of the other people that the author doesn't grok IRC. It doesn't force you to be instantly available, just available eventually. The amount of effort it takes me to respond to a question I know in IRC is an order of magnitude less than an email, and email lists with a lot of mindless chatter can just be as insular or more insular than IRC groups. If the author has issue with individuals getting constant highlights then they should redress them to communicate with the community as a whole. The appropriate interaction on IRC starts off with asking the channel/community as a whole a question (much like the mailing list described). It feels like openstack has a lot of newer people that don't really understand the expected etiquette/workflow on IRC.
- emacchi 11y agoWorking on a project such Open [1] as OpenStack [2], IRC is the way to go for meetings & quick discussions ore following-up a bug or an urgent thing, that need to be synchronized. For everything else (async), Mailing-List allows anyone to be part of any discussion in this Open project. It brings sanity and consistency in the way a community can communicate across different timezones & work schedule. If you like and respect Open-Source, you'll mix IRC & Mailing-list carefuly. Thanks Chris for this blog, I totally agree with you on this one. [1] https://wiki.openstack.org/wiki/Open https://wiki.openstack.org/wiki/Open [2] https://wiki.openstack.org/wiki/Main_Page https://wiki.openstack.org/wiki/Main_Page
- emacchi 11y agoWorking on a project such Open [1] as OpenStack [2], IRC is the way to go for meetings & quick discussions ore following-up a bug or an urgent thing, that need to be synchronized. For everything else (async), Mailing-List allows anyone to be part of any discussion in this Open project. It brings sanity and consistency in the way a community can communicate across different timezones & work schedule. If you like and respect Open-Source, you'll mix IRC & Mailing-list carefuly. Thanks Chris for this blog, I totally agree with you on this one. [1] https://wiki.openstack.org/wiki/Open https://wiki.openstack.org/wiki/Open [2] https://wiki.openstack.org/wiki/Main_Page https://wiki.openstack.org/wiki/Main_Page
- mjgoins 11y agoYou can see how long someone has been away from their irc session with: /whois username