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.
