[johnomarkid]

Issue #2, that slack is based on synchronous communication, is something that is always ignored. Sometimes I log in to slack and see a conversation that I want to add something to, but it is 4 hours old with 50+ new messages on varying topics. Even with Slack's new threaded messages it is hard to evolve the conversation after all the synchronous folks have moved on to other topics.

[fiatjaf]

I don't understand why people seem to thing that chats will solve all the problems. Chatting is having to write the same thing a million times.

[tetrep]

> Chatting is having to write the same thing a million times.

If you find yourself repeating the same thing a lot in chat, it would be a good idea to document it somewhere and just paste a link. With a link to the relevant documentation, a lot of people will just do the rest of the legwork on their own, and will now be able to quickly reference it going forward, and hopefully bug you less in chat (you can always be explicit and refuse to answer people, asking them to read the docs instead).

If you find you're pasting too many links too frequently, then it's time to make an FAQ with those links, and start linking to that.

[branchly2]

The problem is though, that some people like to be the local expert on IRC/Slack with all the answers. They don't want to document it elsewhere.

[joshuamorton]

Then that person is doing all the legwork, but someone else can come along and create a KB themselves with those answers.

[BuuQu9hu]

Fix your group's culture. Document things. If people refuse to document things, then do it for them and shove your docs in their face. Do it until they write the documentation themselves.

[mverwijs]

> Fix your group's culture.

Culture-change is about the hardest thing to achieve.

[npizzolato]

It's also the most important thing. If your culture is bad, changing what tool you use isn't going to fix everything. You're just going to have a new tool everyone uses poorly.

[mkj]

Could clever chatbots help there? Might be hard to avoid being intrusive though.

[artursapek]

It's easier to ask for help NOW and get customized answers NOW than to dig through a wiki/documentation for the answer.

[rdiddly]

Proving the point that someone then has to repeat the content of the docs.

[artursapek]

Of course - I'm just saying it's easier for the customer/consumer.

[maccard]

It's easier for you. As the person who answers your question, it's easier for me to point you at the documentation

[freehunter]

What you're looking for is email. Multi-user chat simulates a real life conversation, and in real conversations it's also awkward to say "hey so going back to what we were talking about 15 minutes ago..." after the conversation has moved on.

[natefinch]

No, email is terrible. There's no history. You can't "scroll up" to see what people were talking about. You can't link to another specific email to reference it (yes, there's archive services, but then you have to go dig through an archive to try to find a horridly formatted email to link to, which is completely separate from the normal consumption platform).

[freehunter]

I actually argued here recently that email was hard to switch away from because of the history. You can keep your emails forever. I have emails from 2007 sitting in my inbox. And if I want to keep them, I can download them with IMAP or POP. If I send an email to five people and they remember to hit "reply all", well that's a conversation, isn't it? And if I need to show someone an email they weren't party to originally, I can forward it to them.

[natefinch]

That puts the onus on every single person to maintain the history of the project. Lots of people delete mail (not me, but lots of people). Also, you can't retain history of what was sent before you joined. Also, emailing individual documents means people can't research by themselves.

[freehunter]

I mean, email isn't meant to be a document repository. Slack (or other chat) is great for immediate conversations with many people. Email is great for slower conversations with a more limited number of people. A wiki is great for a very slow conversation. An actual document repository is great to be able to link to when using any of the other conversation methods.

Just because Slack isn't good at slow conversations doesn't mean it's bad. Just because email is bad at including people who joined after the fact doesn't mean it's bad. Those aren't their strengths, and that's fine. They still serve their own purpose just fine.

[u801e]

You're correct, but Usenet does provide those features and is very similar to email from a user standpoint.

[snakeanus]

This is just wrong.

[lucb1e]

I never used Slack, but in IRC I'd quote what the user said (a format like "<user> message", optionally with a time) if it's really relevant; and in Telegram it's a simple matter to rightclick and reply (which allows people to click/tap it to jump back to context) which I feel much less bad about.

[delias_]

If I really wanted to bring up a topic that had passed, I would break out to a separate channel and invite the relevant people and drop a note in the main channel with a "bringing things back up about $conversation in #newchannel". This works better than writing to threads in my experience.

[maxxxxx]

I have recently started using slack and I see the same. Once a conversation has moved on it gets awkward to move back to the previous topic.

[ntaylor]

This may be a shortcoming of the UI, more than anything else. There's definitely room for improvement here as I often miss updates to threaded conversations even as I'm looking for them.

[hehheh]

I think they could make threads work with some simple changes:

* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.

* Allow the user to collapse a thread so they no longer see it in-line.

* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).

* Allow the user to navigate between threads using only their keyboard.

As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).

[ska]

Chats (of whatever type) have never been a good solution for this, that's why mailing lists exist. Improvements there would be nice, sure, but are unlikely to come from a chat service. They just solve different problems.

[codingdave]

This is more of a usage problem that anything else. If your organization makes decisions based on synchronous communications, without stopping to notice who wasn't included and get their input before final decisions are made, that is a cultural problem, not a tooling problem.

[flukus]

The biggest problem I had is that if you wanted to scroll back through those 50+ new messages you need 32GB of RAM.