Hacker News Reader

Comment by jtl999 | Hacker News Reader

The problem I have with large group chats like Slack, Riot, IRC is that it's hard to get information from them when you've been "out of the loop" for a while. Much better to read a bunch of forum threads or tickets, then trying to make sense of a long scrollback.

View on HN

You shouldn't be trying to. Slack is a tool used for raid iteration, not an event / decision log. Unless you establish some strict conventions, like having an announce / decision channel with very restricted traffic, you should still record important decisions somewhere else, and give that to people when they need to 'catch up'.

That doubles the authoring workload, though.

If you're talking on something like a forum, with individualized contextual threads, then those are already auto-categorized for reference later.

I guess the equivalent would be to start new chat channels per topic, and index them somehow? But realtime chat tends to have more organic topic drift than post-based discussion.

> I guess the equivalent would be to start new chat channels per topic, and index them somehow? But realtime chat tends to have more organic topic drift than post-based discussion.

Well said. It's a shame IMO how much forum software has deteriorated in innovation post 2010 or so. Discourse is nice, but not my cup of tea when compared to the layout of "classic" forum software, phpBB, SMF, etc.

Classic forums software was pretty much a web based NNTP gateway -- some even supported nntp integration directly. Posts were threaded.

Then along came unthreaded forums in late 90s/early 00s. Things like phpBB are not my cup of tea when compared to the layout of usenet or slashcode.

> Classic forums software was pretty much a web based NNTP gateway -- some even supported nntp integration directly. Posts were threaded.

Ah. We have a different view of "classic forum software". NNTP was before my time.

Doubling the authoring workload is inevitable for anything particularly important. It's discussed once, then distilled down to a more consumable form a second time. If a new employee joins it's not like they're going to read two years of slack backlog to get going.

Doubling the authoring workload is important, though: it ensures that everyone walks away from a long conversation with the same summary. Even if you're present in a conversation, you can think that someone agreed with something you said when they actually scrolled past it or forgot.

Traditional meetings have secretaries and a procedure for approving minutes for this very reason.

Reply on news.ycombinator.com