
Persistent IRC Considered Harmful - bengillies
http://anticdent.org/persistent-irc-considered-harmful.html
======
beefhash
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.

------
buserror
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
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.

~~~
buserror
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 ;-))

------
adamors
These "Considered Harmful" articles are so unsubstantial at this point that
one could make the argument they are harmful.

~~~
jordigh
Modest proposals considered harmful? :-)

~~~
adamors
That Eric Meyer article says it better than I could.

------
dharma1
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](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/)

------
cmsj
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.

~~~
acveilleux
It'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
To me Slack and the likes are just glorified pretty IRC.

~~~
acveilleux
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.

~~~
joezydeco
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.

~~~
lmm
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.

~~~
Karunamon
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?

~~~
lmm
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.

~~~
Karunamon
Huh. This is a resource I'd never considered, then. I've always thought IRC
conversations to be mostly ephemeral.

------
cdent
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.

~~~
pavel_lishin
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.

~~~
cdent
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.

~~~
sanxiyn
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.

------
tokenizerrr
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.

------
woah
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.

Also, the title is considered cliche.

------
xemdetia
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](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
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.

[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)

------
colindean
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.

------
daigoba66
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.

~~~
xxpor
I 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
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.

------
peterwwillis
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...

------
sikhnerd
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.

------
orliesaurus
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 :)

------
mjgoins
You can see how long someone has been away from their irc session with: /whois
username

------
baldfat
Personally I use Weechat and glowing-bear.org for my IRC and it works
amazingly well.

------
Torgo
One size does not fit all. This applies equally to IRC lovers and haters.

------
pavel_lishin
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!!!!"_

~~~
zwdr
>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
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.)

~~~
zwdr
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.

~~~
pavel_lishin
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.)

~~~
jsnell
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.

