Personally, 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.
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 ;-))
I'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 - 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/
Strongly 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.
Slack 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.
I'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.
Simple 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
If 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.
Serious 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?
I 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.
Isn'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.
Hence 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?
Hi, 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.
> 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.
But what happens in the absence of bouncers? Is the information even written down at all? (IME: often no). If the information ends up on a mailing list or issue tracker, is that any more accessible to other people than IRC history? (IME: again no).
Rather than try to get people to change their habits, it would be better to produce tooling that supports the use strategies people have evidently found effective:
* Public, indexed/searchable chat logs in a place that's easy for newcomers to find them (many OSS projects do this already)
* Chat systems where you don't have to do some complex bouncer setup to be able to participate on the same level as the core contributors (e.g. Slack or Gitter, where scrollback is available to every user, even newcomers)
* Support for indexing into useful pieces of chat log, or for excerpting parts of a log into a more permanent home. Slack does something a bit like this (persistent snippets in a channel). HipChat offers some level of integration with Atlassian's terrible wiki product. Google wave seemed to have this as part of its idea.
> * Chat systems where you don't have to do some complex bouncer setup to be able to participate on the same level as the core contributors
Offer a public quasselcore with your project and allow people to create accounts on it?
> * Support for indexing into useful pieces of chat log, or for excerpting parts of a log into a more permanent home. Slack does something a bit like this (persistent snippets in a channel). HipChat offers some level of integration with Atlassian's terrible wiki product. Google wave seemed to have this as part of its idea.
That’s already possible if at least one of your users is using Quassel as bouncer, as it stores its logs in an SQL database. Supported by default are SQLite and PostgreSQL.
Agreed. Tell me if I am wrong but it sounds like the gist of the post is NOT "stop using bouncers and IRC", it's "stop using bouncers and IRC to answer important project questions".
Logs are honestly a pain if you are just trying to keep up with the important things. Lines and lines of join/quit/hi/hello/how's that pasta/I like movies/etc...
I believe the #indiewebcamp channel handles this situation with a wiki. I haven't use it in a while but I think the wiki-bot lets you define wiki entries right from IRC so if something important is discussed then it can be permanently summarized and indexed on the fly.
Persistent IRC does not prevent people from using a project mailing list, it does not negatively impact 'creating relationships', and it does not make projects less accessible. Everyone in the world has an e-mail address. IRC does not prevent its use.
Is that a problem with persistent IRC, or a problem with community members not stepping up to ensure that knowledge which gets developed in IRC doesn't die there?
Can 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.
The 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.
The 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.
I was also wondering about the jargon angle. In my experience, jargon is also prominent on mailing lists. I don't understand what's problematic about jargon on IRC that it's true elsewhere.
Considered 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.
I 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.
It'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), 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.
Working 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.
Chat 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.
I 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.
I'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.
Anecdotal: 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...
Pretty 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.
IRC 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 :)
If 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!!!!"
>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.
Where'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.)
What 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.
Oh, i'm sorry, I thought your response also started with a >; I thought you were quoting something. My mistake.
And I agree that nickchanges can be annoying; I guess I've never been in a channel big enough where it was a significant issue.
And yeah, it's hacky - but given that IRC is fairly bare-bones, I think it's a good human-readable compromise. You can register your afk nickname as well, and notifications work just as well if you configure your client/bouncer to highlight them both (which I think most do by default anyway.)
I'm really not sure whether you're pulling some kind of a passive-aggressive "I'm being misquoted so badly that I refuse to even acknowledge it's a quote" routine, someone has edited their message, or you're genuinely not seeing it. At least currently the text after the ">" is a direct quote from the message it was a reply to (i.e. your initial message). It also seems pretty representative. If you disagree with that text 100%, it seems that you perhaps intended to write something else originally.
> this may just be the way I have my client set up
Two explanations are either yes, your client is configured to show active and away people the same; or other people aren't using the 'away' feature, so they show up as active 24/7. In the former case, fix your settings; in the latter case, it is other people who need encouragement to change - but encorage them to make use of the built-in away feature, don't encourage them to change their nicks :)
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.