Christopher Aedo has recently published IRC, the secret to success in open source. It does an excellent job of explaining the importance of communication for successful collaboration in open source projects. He then, however, goes on to suggest a strategy for coping with IRC that is, to me, one of the least pleasant and one of the most damaging features of OpenStack interaction. He suggests that people use an IRC bouncer, or other technique, to maintain a persistent presence on IRC, hear pings when not actively present, and perform automatic catchups when returning.
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!!!!"—but the killer is the way in which it allows, encourages and even enforces the creation and expression of project knowledge within IRC, leaving out people who want or need to participate but are not synchronous with the discussion.
Logging, the usual technical solution and excuse for this problem, is insufficient:
The logs from a busy channel can be huge. Unless you were present in the conversation or really know what you're looking for, good luck.
IRC conversation, by its very nature, involves quick exchanges of information that is dense with jargon. In a busy channel these exchanges are interleaved. For a reader that is not already familiar with the jargon it can be challenging to distinguish one exchange from another.
To be clear, the existence of the jargon is an important hallmark of a community having developed the shared language that is required to have shared goals. It's not a bad thing that it exists, but it can be exclusionary if the majority of communication and interaction is in the jargon encrusted environment.
If the most active members of a channel are consistently using IRC as the mainstay of their interactions, especially in an asynchronous fashion, the volume of content they create will be high but it will not be consumable by others. It will be heavy with jargon and will not be the result of considered reflection on the topic.
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. Not only will you catch a fish when the answer shows up in email, so will lots of other people on their own schedule. If you do participate in any interesting conversation on IRC take a moment to curate the information and results into a message to the mailing list or a blog posting.
Leave IRC for chatter, noodling, urgent issues and, most importantly, the building of relationships with your comrades. You can't build a relationship with someone who isn't actually there and you aren't helping someone be human (and a productive thinker) by pinging them to be there when they aren't.
Update: Stefano Maffulli has written a thoughtful followup that covers some of the issues sanely: Balancing IRC and email, the secret of success for open collaboration. He even includes one of my favorite axes: some advice on how to use email properly.