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

[lmm]

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

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.

[kuschku]

> * 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

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.

[molsongolden]

Agreed. Tell me if I am wrong but it sounds like the gist of the post is NOT "stop using bouncers and IRC", it's "stop using bouncers and IRC to answer important project questions".

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.

[sanxiyn]

I agree current IRC logs are a pain, but isn't that a reason to improve logging (say, hide join/quit by default, add search, etc.)?

[peterwwillis]

Persistent IRC does not prevent people from using a project mailing list, it does not negatively impact 'creating relationships', and it does not make projects less accessible. Everyone in the world has an e-mail address. IRC does not prevent its use.

[aaronem]

Is that a problem with persistent IRC, or a problem with community members not stepping up to ensure that knowledge which gets developed in IRC doesn't die there?

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

[dwc]

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.