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.
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
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.
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 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/
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.
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.
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.
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.
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.
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.
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.
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.
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.
Thanks Chris for this blog, I totally agree with you on this one.
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 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.
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).
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.
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!!!!"
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.
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.
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.)
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 :)