This site is an archive; learn more about 8 years of OpenHatch.

[Ccsf-campus-staff] [revised SUBJ] extra material on irc -- in particular would like to flesh out Training Mission on 'irc bouncer'

Katherine Moloney kmoloney at mail.ccsf.edu
Thu Apr 10 18:06:23 UTC 2014


---------- Forwarded message ----------

On Tue, Apr 08, 2014 at 03:36:02PM -0700, Katherine Moloney wrote:
> This is Katherine from that 3/22 OpenHatch open source workshop at
> City College of SF (a big thank you to Geoff, for bringing you).
>
> I'm wondering if you wouldn't mind writing up a short description of
> 'why irc is still the medium' -- I found the explanation that you gave
> while we were sitting at the Chinese restaurant quite enlightening,
> though I couldn't repeat it for anyone else (the difference between
> first learning & knowing well enough to teach someone else).

Now I have to remember what I actually said... Some random thoughts
follow; hopefully I've covered the main points I made before.

Some of the reasons are historical and there just hasn't been a
compelling reason to switch. Some are still valid, and are good reasons
not to switch.

IRC is an open protocol. There's no tie in to any OS or server provider
or infrastructure. I can find a client for any OS I chose - be that
Linux, Windows, OS X, an Android phone, whatever. Equally if I want to
run my own private server (there are quite a few big companies who have
internal IRC servers used by engineers) then there are options and the
clients will talk to them just as well as the public servers. Most of
the other chat protocols that have been around a while (ICQ, MSN, AIM)
don't have that flexibility - I have to run the provided client
(assuming there's one for my OS, or hope someone has reverse engineered
the protocol enough to implement one for my OS if the vendor doesn't
provide one) and I can't run my own private setup if I want to.

IRC is also plain text. This is actually helpful. It means that it's
more accessible (e.g. for people with vision problems using screen
readers). It makes it easier to log for future reference. It means you
can easily have a client running on a VPS or remote server (my IRC
client runs on a machine in London for example, and I connect to it via
ssh from where ever I happen to be). It's also low bandwidth as a
result. I can be on a modem or a mobile phone connection and still able
to effectively communicate via IRC. I can be half way around the world
and it doesn't make a difference to the others in the channel.

Very few clients for other chat protocols support the disconnected
operation quite so well. Even if you want to use a graphical IRC client
there are "bouncers" which can run on a server that you connect to and
they then let you see traffic you missed while you were offline. I think
this is one of the great strengths of IRC - it gives lighterweight
communication than a mailing list. It's easy to ask a one line question
or jump into an existing discussion, and it's much faster if the
participants are all around at the same time. But it also works well for
time lapse conversations - I can ask something and potentially have
someone answer an hour later if they happened to be busy (or in a
different time zone and at work/asleep/whatever).

It provides a good broadcast mechanism - a bit like Twitter in that you
can say something and people can either ignore it or interact, but the
existence of channels means that you're narrowing down the audience a
bit and/or the topic of conversation (depends on the channel policy;
some are more social while some are very focused on particular
projects). More traditional chat clients tend to be more geared towards
one to one communication, with group chats a bit of an afterthought, or
something that you have to create when necessary rather than always
being there for people to join.

That said I know quite a few folk who don't use IRC at all, but instead
are very active on project mailing lists. There's definitely a lot of
advantages to those as well - lists work much better for archiving
questions and their answers, or being able to provide a lot of detail
around a question. They're a better way of trying to ensure the question
(and answer) aren't missed as well - IRC can be quite busy at times and
people aren't always paying full attention to it, while it's easier to
leave list messages unread and come back to them when you have time.

> Also, do you know any links describing how to productively log the irc
> channels one follows?  I too was under the impression that, if no one
> was on the channel, then the question was lost and would have to be
> asked again.

I think one of the key things is that if you turn up and ask a question
and don't get an answer within a few minutes it can still be worth
leaving your client connected for longer and seeing if someone
eventually answers. I've seen people turn up, ask a question and
disappear within a couple of minutes and then 10 minutes later someone
notices it and goes "Oh, if they'd stuck around I'd have said <foo>".

Logging is very much a client thing and I don't really know how to drive
anything except irssi (which is a text mode client and I wouldn't really
recommend it to people starting out). For offline operations the term to
search for is "irc bouncer" - this is a program that runs on a server or
VM somewhere and lets you reconnect from your personal machine when it's
online and see what you missed.

> Thank you again for coming and pitching in as you did.

No problem; I felt that the audience appreciated our time and it's
always nice to be able to try and convince more people to get involved.

J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/ccsf-campus-staff/attachments/20140410/43bc3a90/attachment-0001.html>


More information about the ccsf-campus-staff mailing list