The real answer is: just fucking use email. Why is email not one of the options suggested in the TFA? It's universally available, durable, allows long-form conversation and thoughtful deliberation, doesn't tell you that "someone is typing," and offers you the luxury of checking it at a set interval only a few times per day.
The way many organizations have collectively abandoned email in favor of instant messaging is a travesty.
Which isn't to say that all the advantages you list for email are not true. They are. It's just that most people will shy away from an otherwise-decent solution if it has terrible UX.
Insecure in what manner?
To me it's no more insecure than a VCS - sure, anyone could edit anyone else's code, but version history was always there.
(but it's read-only, there's no rebasing, people still use old-school e-mail clients)
I think the ideal is the approach you get with discussion forums: Create a set of boards organized around topics, and place named, threaded conversations within those boards. People can join a board, in which case they will be able to get a list of new conversations related to that board's topic. They can then subscribe to just the conversations that interest them, and unsubscribe from ones that cease to be of interest.
The archive on a mailing list is a second-class artifact, typically hosted via HTTP, and usually people don't care about the quality of the archive's UX.
The structural organization on NNTP is also a first-class artifact that everyone can refer to. A mailing list will go straight into everyone's inbox, with all their other mail, until they filter it away.
News groups and mailing lists don't scale super well, in that, when you subscribe, you then get sent everything. Maybe not terrible for the 5-10 emails a day from my kid's playgroup's email list, but absolutely awful for trying to keep up with a team of 100 people.
Or use digests, mail filters/folders and a convention for tagging message subjects.
Once you get down to the individual conversation level, the fine-grained management bits you talk about are not good UX, they're band-aids for dealing with bad UX.
2. Contextually-scoped lists. If a topic is of limited concern yet intrusive, split it to a separate list. Moderation and management may be necessary. Technical teams should be scoped correspondingly. 100+ team members is excessive, 3-15 far more typical.
Internal Q&A, forums, and email all work because you can have long-form conversations on them but an important consideration is discoverability. If a new user wants to find out why X is true for some service, they'd better be able to do that without interrupting someone else.
VSCode is somehow fast despite running a bunch of linters/compilers/language-servers while typing, and similarly built on web tech, and ... in case of a JS/NodeJS/TS project it also handles tens/hundreds of thousands of files with ease, oh with full text search.)
The big win was the ability to rapidly subscribe and unsubscribe from lists as you needed them. The actual corporate email distro lists were handled by a dedicated IT team who insisted on tickets for everything, so most people just added filter rules to their inboxes instead of dealing with that mess.
As for S/MIME, certificates are a pain to deal with for most people and all they really care about is transport-level, not E2E encryption.
However, you can't "just use email" -- Email's threading model is great for asynchronous work, but it is poor for synchronous communication and also doesn't support modern features that make it easier to communicate ideas efficiently (shared history, markdown formatting, image previews, emoji reactions, etc.). It's essential to be able to have (semi)synchronous written conversations with people you're working with, especially if you don't want to spend your days burning out on video calls.
This is why we created Zulip -- it's designed as a real-time communication tool with email's threading model and all the nice features of modern chat apps that email lacks. And the reading user experience is actually a lot better than email, because Zulip provides is designed with the goal of saving time when prioritizing, skimming, reading, and replying to conversations. It's also 100% open source software (not open core!).
Not if you have a mailing list, and then going off the record is as easy as removing the mailing list from the CC field.
This is an implementation failure, not really a fundamental problem with email. There is no reason that email clients don't support markdown, except that nobody has ever wanted it. There was someone who made a utility to switch markdown to regular MIME email, but just as a proof of concept. It works.
I assume what you mean by this is an inline thumbnail that expands when you click on it? Again, there's nothing about email that prevents it, it's just the way email clients are. That could be fixed
Okay, that's fair, there's no way to do this in email, short of sending a single emoji back. On the other hand, I think everyone would agree that this is more of a nice to have feature, than a necessary one, and one that really only makes sense in the world of quick, back and forth chat programs.
Personally though I have nothing to complain about with slack. It has threading. It only has one level threading but that might actually be a good thing because we slack with non tech people too. One thread is sometimes hard for them to grasp. Make that a regular threading model and they will utterly get lost. You can see how that completely breaks down with emails in most places.
We use slack both for synchronous and asynchronous communication. It's all about the culture and what people expect. Not really different from email. Remember the people that send you another email if you didn't answer their first one after 5 minutes?
Group chats you can just link to in a ticket instead of having to paste and reformat from a large email conversation? Priceless!
Markdown is not necessarily required. Most good email clients supported something like it, like actually displaying something like _this_ as italics or * bolded *. It's like saying "but your app doesn't do XML". Yeah well but it does JSON.
Off topic, but this astounds me.
Not trying to be elitist (I'm genuinely curious), but what is it about threads that throws them off?
They seem unrelated to software. I would have thought "non-tech" people would also understand them.
One guess is that there's the mental effort in keeping track of these threads (even when they're literally right in front of you in the interface.
Maybe it's the fact that they're just so used to the whole email chain with 15 levels of quoting old emails that is so common in many companies. Many many people are mentally immobile and unprepared to switch to anything else, once they're used to something. Lifelong learning is not something that is common in every job, like it is in software development.
Again you can't really ask me because I find threading totally awesome.
I have been recommending it right and left to people who don't need federation in their chat system. If there was a clear gateway to federation -- enabling a Matrix room as a Zulip Stream, for instance -- I would enthusiastically recommend it for everyone.
I get you. But also:
- Email doesn't retain context very well. If I dig back through my email I might have all of the emails in a thread, or maybe not.
- Likewise, I can't send someone a link to a previous emailed conversation so it makes for poor documentation. I can forward an individual email, but not the comment in context.
- Email is not easy to index or post up for reference. You can't link it from a wiki or other documentation for example.
An internal mailing list with archiving would solve many of these issues and might be the best option, but it's a slightly different solution.
I didn't realized they removed the email piece... seems like a downgrade. Particularly for projects where you have fairly casual participants.
I like using Slack and we use it heavily with my team, but I agree it has issues.
Meanwhile, we've been using mailing lists for established open source projects for years for all of these reasons.
There isn't really much else I don't like about it, I never stop being amazed by how great the keyboard navigation is and how much the "river" of messages improves usability.
I'm intrigued by the Guest option. Do you think it's a good way to communicate with the clients during longer projects?
But yeah for groups you need a mailing list with an archive. It's still better than most IM apps IMO.
> It's still better than most IM apps IMO.
Yes, but you are trading one set of limits for another.
It's a bit surprising that at this point we haven't standardized on something better than essentially IRC versus email.
(Ok not surprising, frustrating)
The necessary conditions are (1) one needs to learn it. Too many features are making UX non-intuitive. (2) fast connection to e-mail server (3) ms exchange on the server, some features only work there.
Looking at the sieve website it seems quite a few desktop and web mail clients do have support for it either out of the box or as an add-on. So I would say that having this functionality is more on the "common" side than "borderline unique".
Sieve might be supported by many email clients, but is pretty much nonexistent in corporate email.
Actually, if someone points me to one hosted email provider that does support it, I'd be glad - I was wondering about trying it out but nobody supports it.
Not sure but unlikely. It works in Exchange for 20 years now, that RFC was written in 2008.
> having this functionality is more on the "common" side than "borderline unique".
The complete UX makes it borderline unique. Available out of the box, has a nice GUI, and is reliable in practice.
I'm just a dumb machine operator that uses Outlook at work, Fastmail for myself, and Gmail because I'm an idiot too, and really can't tell the difference.
Outlook also has been chasing the flat look fad which is against usability. Most of the others are too so it is hard to fault them, but I still wish they would have the guts to say this fad is wrong...
Once they are all running and you are used to the ui quirks they all work well enough.
I've used Outlook in several organisations over the years, and start time has always been in the order of 5-10s.
Install Thunderbird and use it for a week. You'll be able to tell the difference very quickly.
A fair point. As someone who has used both Outlook (professionally) and Thunderbird (personally) for decades (IIRC, the oldest message in my Thunderbird email store is from 1996), calendaring in Thunderbird isn't as robust as in Outlook and some of the other weaknesses you mention are absolutely valid.
However, I'd say that many of the advantages of Outlook that you mention are more related to better integration of Outlook into Exchange back ends than to the Outlook client.
If Exchange had better IMAP support and appropriate plugins for Thunderbird, Thunderbird would be vastly superior to Outlook in most respects.
As it is, Thunderbird is already vastly superior to any web-based MUA, including OWA.
Edit: Clarified Outlook/Exchange integration vs. Outlook as client.
On the other hand, yes, Outlook Web Access is hilariously bad. It's hard to understand how Microsoft flubbed it so bad considering that their consumer outlook.com has a radically better webmail. Different teams, obviously, but you'd think they would have shared notes.
All in all, it feels a lot to me like Microsoft had a really good MUA in 2003 and hasn't done much with it since, while Mozilla had a not-quite-done-yet MUA in 2003 and hasn't done much with it since. Both feel bolted together out of spare parts but in a way that's subjectively a bit different.
I asked our biz dev guy who had been trained as a lawyer what to do and he told me to the same thing my accountant does with my taxes: email an encrypted PDF as an attachment and share the password by a separate channel.
Even with the best organization (old content deleted), I don't want to wade through the conversations about it or all the other noise. Chat is temporal, the discussion about something like "should x be updated" is immediately irrelevant after the decision is made.
Slack search for <insert error name here> is high-value in historical context that's tough to replicate elsewhere. All at once, you learn if anyone's ever asked about the error before, and if so, see the conversation on resolution.
Email is far worse, in fact, because:
* Everyone has a unique view
* Unless there are lots of cc-everyone style emails, you might not even have anything to find. (And cc-everyone sucks for 100 other reasons.)
* You can't find anything predating the start of your employment
The biggest issue with searching both chat and email is the absence of a result doesn't help: it's possible it was a private chat, or an email chain that you weren't a part of, but there's no way to tell.
(Side note: A very locked-down wiki isn't any better, but that's a conscious decision rather than default.)
Many companies use Outlook groups. Those are mailing lists.
The important part is we know why a decision was made. Chat logs are not a good archive because there is too much to sort thought that isn't relevant. Better than nothing, but what is really needed is an effort to document why in a place the right people will find it when they need to know.
That said, none of my employers have ever made effective use of this. I don't think open communication is an instinct that most people have.
Chats have the same problem: they aren't searchable by people who weren't in them.
Also, even if I am part of the channel, there is no way I can search and locate what I want without knowing the right keyword to search for. Sure, the information is all there, but that only ads to the frustration. Search interfaces in Slack & all are very limited / too broad.
That sounds horrible and very fragile.
> I now need to have a long conversation with legal. How will the service provider handle the content (discussions, screenshots, code snippets) that my team will upload?
Yet you suggest using email where it basically goes (or can be coerced to go) across the internet in plain-text where anyone can read it?
I know of at least one large company that forcibly deletes emails older than N months, as part of their legal retention policy. (I'm assuming it means non-retention to limit exposure to lawsuits.)
That would be problematic for persistent documentation.
I speak as someone who worked for a company where email got archived and then deleted after 6 months, and currently works at a company where everyone only uses Slack, and Slack is purged after 30 days.
They're gonna notice real quick the next time they get sued by somebody clueful enough to subpoena that goldmine.
If not, you are very lucky that you are being sued by people with incompetent attorneys.
The alternative to having a document retention policy is to just have employees delete things in an arbitrary manner. It's not just CYA for leaving inconvenient doc lying around, it's also to ensure the proper retention in the event of a preservation order or public records request.
Some companies go way further than others. One place I worked included "notes of a personal nature (eg, birthday cards)" in the retention policy and let us keep them for a week or two before destruction.
This sets a general policy of deleting documents/emails/etc after $X days. This is really a CYA policy to purge old conversations if a big lawsuit comes down asking for document retention in relation to some scandal, and if its older than $X days you're covered since your standard legal process was followed.
Attorneys who sue or investigate people for a living want everything forever, and those who get sued want to delete email before it arrives.
Email is a great way to get in trouble, as people tend to say dumb things, even about things that they have nothing to do with!
Actually, forced deletion - if users are aware of it of course - is likely to sanitize everyone's practice. Email ain't a backup tool.
That's symptomatic of people doing the most silly things and then blame the failures on their tools.
It can even serve as real-time communication for #random and other such work-adjacent channels.
The advantage over just copying everything to a mailing list is that most conversations aren't worth archiving, so having conversations be opt-in after the fact keeps the signal-to-noise ratio much higher than it would otherwise be.
We're still a very small platform, but since we're completely bootstrapped and grew 34x year-over-year in the past year, we're not going anywhere. :-)
Adding a distribution list to an email thread is almost exactly like choosing a Slack channel to type into, except you no longer have the mess of needing to share and re-share messages and threads across channels. You can just add multiple distribution lists.
You can also subscribe and unsubscribe from distribution lists and set up filters for them, which is basically like joining and leaving Slack channels based on your interests, except it gives you much more control over what you want to read and when.
After a archive-worthy discussion in email, you forward the thread to "firstname.lastname@example.org". The script will parse the email chain and generate a static web page hosted on a local server.
Unfortunately there isn't any such thing as "forwarding an email thread", at least not currently. If you hit the forward button in your email client it will only forward the last email in the thread, which sometimes contains the entire thread as quoted reply text, but only in situations where each person has only replied to the most recent email in the thread. Some email clients also truncated the quoted reply text after a certain number of messages, and it's not generally parsable.
Our email archival product uses a G Suite add-on for this reason, which provides the same benefits as OAuth but works on a thread-by-thread basis. I think Outlook extensions work the same way, but I'm not 100% sure on that.
Actually technically Gmail does have a little known "forward thread" button that's hidden in one of the dropdowns, but it doesn't work that well. (Which you'll see if you try it on any longer thread.)
Mailing lists have for years offered mailing list archives that you can read directly in your client, exactly as if the messages had been hitting your inbox from the beginning. The bigger problem with email is that messages are not as easily addressable, unlike links on the Web.
You can format email messages for display on the web and generate permalinks for each message. E.g. look at what we do for https://www.prettyfwd.com. I haven't yet added a JS snippet to autoscroll to a specific message if you pass it in the UUID for that message as a URL parameter, but it's been on my TODO list for a while.
Example thread, where each message is formatted for the web and has a UUID: https://www.prettyfwd.com/t/5XVkc401RiCTO9hwsSRziQ
The other problem with most mailing list archives is that they look terrible and have poor readability, poor SEO, and generally terrible lighthouse scores. Whereas I think we score perfect 100s across the board, albeit only 99 on mobile perf because we don't prerender.
Everything you have in your archives will be taken out context, misinterpreted, used against you in court.
That's too-sweeping a statement :
1. Privilege attaches only to communications in the course of seeking legal advice.
2. Privilege is waived — and thus the emails are discoverable by adversaries and admissible in court — if people outside the decision-making group are in the conversation.
3. Privilege doesn't attach if the lawyer is functioning as a business executive or -advisor.
4. Privilege won't apply if the conversation is determined to be part of a crime or fraud.
All that said: If a lawyer is involved in the conversation, then the company's litigation counsel will almost-automatically withhold the emails from being produced to an adversary and will list them on a "privilege log." That will often set up an ancillary court fight over whether the emails should be produced to the adversary. In that ancillary fight, the judge might end up reviewing the emails "in camera," i.e., without the adversary seeing them, to decide whether the privilege applies — and depending on the content of the withheld emails, having the judge read the emails could do as much damage to the company's case as anything.
In the early days of the Ethereum community a lot of open coordination was done on reddit and a threaded forum hosted on Vanilla Forums. Initially for privacy and convenience, Skype, gitter, Discord, and Telegram began to take hold, and later became the primary place for open, public discussions and some decision-making as well.
Threaded forums were still used but not central. It was a difficult era (but a lot of work still moved forward)! There emerged a kind of opacity due to ability to put attention on real-time threads, and IMO sometimes key voices were missing because they could not weigh in effectively.
What changed the dynamic was the introduction of Discourse for the critical https://ethresear.ch discussions (set up by Virgil Griffith), and later https://ethereum-magicians.org (something I worked on). I was pushing for threaded at the time because of experiences I had here on Hacker News, reddit, and Slashdot. The person I collaborated with, Greg Colvin, wanted discussions like the threaded emails he was used to from the IETF and c++ communities.
We each knew from long experiences dealing with coordinating on tech issue remotely that the quality of the message is the medium.
From those successful experiments / re-introductions, many teams then began to adopt and host Discourse instances. Later, DeFi picked it up for their governance / coordination discussions. Of course, real-time never went away, with more gravitating toward Telegram and Discord. But tracing the emerging thinking, hashing out differences on what to do, and re-activating stale discussions improved a lot.
Threaded discussions are a core part of the community and work again.
1. In-person meetings and real-time calls have been a major part of the work. There is an agenda and very good notes are taken during these sessions (https://github.com/ethereum/pm). The calls have been essential for coordinating in a more formal setting and to get a feel for when consensus is achieved on a particular topic or proposal.
What threaded forums later added was the ability for others to get involved in the discussion, particularly those who are not core developers or not able to attend.
2. Another important medium has been GitHub issues (e.g. https://github.com/ethereum/EIPs/issues/2315). Proposals are submitted as a PR and, earlier in the evolution of the governance process, many people would comment on them. These were not ideal due the flat nature of the format.
What generally changed on GitHub issues in recent years was the encouraging of commenters to go to an external forum thread (https://github.com/ethereum/EIPs/issues/2315#issuecomment-63...), leaving editors and authors to work out structural and other basic issues about a proposal in GitHub PR comments.
If nothing else I'd love to hear your feedback on what the most important features were and how you'd see a product like this evolving.
I've built products just fine using verbal communication nearly exclusively.  We don't need to create some sort of panoptic archive of every conversation ever had to get things done. If people miss things, they miss things. We can catch each other up on the parts that truly matter.
Forgetting and repetition can be negative, but they can also be highly positive. We don't have to carry with us the weight of every word ever spoken about a project.
 The main exception being index cards with a few words on each. https://williampietri.com/writing/2015/the-big-board/
So they advocate for putting the important information in a separate context, that also allows for more thoughtful conversations.
> If you go on vacation [...] Often your only option is to declare chat room bankruptcy which means missing out on important discussions and big decisions.
So what? That's what vacations are for. The whole point is to miss things. It's good for both the person and the organization to miss things. "The graveyards are full of indispensable men."
There's some unstated motivation behind the post. But whatever it is makes no sense to me. The options I can think of fall in a range from absurd to self-defeating.
>> If you go on vacation [...] Often your only option
>> is to declare chat room bankruptcy which means missing
>> out on important discussions and big decisions.
> That's what vacations are for. The whole point is to
> miss things.
A big part of coming back from a vacation is catching up. Vacations can feel a lot better when it is easier to get back in the groove when you get back.
There are chat/messaging systems that make catching up much easier than Slack. I really like Zulip, for example.
> That may be an effect of vacations, but that is not their driving purpose
That all depends. A confucian official was apparently required to take a two year mourning period following the death of his father. I have read the theory that one purpose this practice may have served (intentionally or not) was ensuring that no one could usurp too much power.
More recently, I have read that some bank employees are legally required to take a certain amount of vacation, with an explicit justification being the idea that if you are using your position in the bank to engage in a lot of financial fraud, you may find it more difficult to keep the fraud going while on your legally-mandated vacation.
Somewhat harder to do now that we are all WFH.
The article is right that the problem is when the information doesn't want to be deleted. Now you have to do extra work. (Specific example; a long time ago, I figured out how to get Github to notify me on Slack when a code review was assigned to me. It is not easy to find in the UI and took me a while to set up. I wrote down the instructions in Slack... and that helped people that were reading it then, but it doesn't help me tell someone how to do it that asks me today. Should have written a runbook!)
Remembering to persist information is always something you have to do, and it's not specific to Slack. Your shell history is useless to your coworkers. Your design discussions is useless to someone that just joined the team today.
slack originally stood for: searchable log of all communication and knowledge
but then in practice, i saw message retention locked down to 30 days or less, which kinda defeated the point.
other modern tools, like trello, also seemed to have gaps when it came to logging/searching/archiving what happened. trello is fantastic for organizing "what needs do", "who do", and "when done"... but in my experience is pretty terrible for "what happened" and "why". this is fine i think at smaller scales, but once complexity starts to scale up, it can be a nightmare. it's hard enough fighting issue hysteresis (reoccurring issues and bugs that drag on for years) when there's good historical views and explanations.
Slack seems to be even worse because unlike email, you don't really have subjects or thread beginnings, just continual flow of chatter.
But indeed the lack of organisation of any kind makes it harder for chats.
I think it's exactly the opposite?
People like it because, except for the free plan, you can find anything that was ever discussed.
Overall, I think search is a bad knowledge base management tool. It proves the positive quickly (search for "foo", see "here's how to use foo"), but never lets you prove the absence of documentation (search for "foobar", nothing comes up, search for "foo bar", nothing comes up, search for the previous codename "barbaz", nothing comes up... did you forget something, or is there just no documentation/discussion? you'll never know. the result is that people stop reading documentation.)
If you want a chat nightmare, try microsoft teams. That quickly became one of the most painful parts of one of my previous workplaces.
I've found that Slack's discoverability is severely limited because it seems to prioritize low-effort input. Here's what I mean: in a busy channel, Slack makes it so easy to reply in a linear chain. Unrelated messages get interleaved. Following a train of discussion can be difficult.
In contrast, I very much like how Zulip organizes threads. It allows content to be organized both up-front (at posting time) and over time. This feels very natural to me.
I do this all the time at work. I didn't say that I can expand and read through all the results in a few seconds, that part takes time. But comparing that to something like teams, which would often freeze for me when going back in a convo history, let alone something like asking people individually, slack has been great for finding internal knowledge.
It helps that Slack's search is actually pretty good imo, and usually quite fast.
But yeah -- it can't be your only tool. If you don't have a better system for long-form documentation, you're gonna lose a lot of important stuff.
I like the idea of a time-limited channel. You can only reply to it during the meeting, and up to 15 minutes after. Theoretically it would force everyone to communicate succinctly and not drag meetings on indefinitely over the course of a day.
Alternatively, have a channel that only allows one message per hour. Call it #deep-thought. You’ll really need to think about what to say before you write it down.
It's meant to replace chat and meetings with something designed to be connected with at your convenience, and then publishes the decisions and how they were reached to wherever your source of truth is (or we can act as your source of truth).
To me this points out a gap in our software for knowledge archival. The closest concept Slack has is "pinning" a message to a channel, which has very limited use for this. Really what you want is to be able to have a conversation with someone in any manner (casual or formal meeting) and be able to easily extract the conclusions and decisions made into a different location, ideally through an easily discoverable UI in the software already being used.
In an ideal world my chat software has knowledge of the projects I'm working on (through some protocol to something else that acts as a source of truth) and I can select a message/file upload in chat and tell it to archive it against a project. It can easily fill in the details for me about who made this decision and when. Ability to effortlessly organise information arising from a connversation should a priority I think, this might remove the need for having seperate software depending on how "deep" you think a conversation is going to be.
This is what was said about GMail when it first came out - you need folders, without folders you can't keep organized, etc.
Turns out indexing and mechanisms to make use of that indexing (labels, advanced sorts, filters) work better than folders.
Persistent chat that can be labelled, indexed, searched and filtered is amazing for work related chats, or any chat that becomes part of a long running context.
We do this where I work, and it works well, mostly - as long as people use the tags.
1) length -- most emails are significantly longer than any single chat message
2) context -- email threads are saved (and indexed) in the context of their thread.
With chat, you really don't get ether, so it's significantly more difficult. You can never really know what a message is a reply to. Responses can come fast or slow. Individual channels can have multiple conversations happening, if not simultaneously, then at least over time.
> as long as people use the tags
I mean, that's the difficulty with any system... getting people to use it. If your team can be disciplined about the tags, then I'm glad that works for you. I not sure it would work well in many other contexts.
I've tried a few different options over the years, from archiving/indexing IRC chat logs, to bug trackers, to wikis, to email, to Slack, to Notion, etc...
Almost anything can work if you're disciplined. My problem has always been getting the rest of the team on board.
> 1) length -- most emails are significantly longer than any single chat message
Agreed. The beauty of a chat, rather than an email thread, is that each message contains (or should) a single point. Which means the chat thread is more of a sequence of the following kinds of responses: Yes, and; Yes, but; No, and further; No, but. This makes for a better conversation, and makes it easier to process. How many times have you asked two questions in an email, only to have someone respond to just the last one?
>2) context -- email threads are saved (and indexed) in the context of their thread.
>With chat, you really don't get ether, so it's significantly more difficult. You can never really know what a message is a reply to...
This is a matter of implementation, not technical capability. A decent context is achieved through proper use of tags and chronological ordering. Better threading can be achieved through a protocol implementation of a reply-id capability, which most chat systems have (XMPP, Discord, etc.), coupled with GUI presentation of messages in a threaded view.
>...Responses can come fast or slow...
True of any asynchronous channel, email or chat.
>Individual channels can have multiple conversations happening, if not simultaneously, then at least over time.
I see this as a feature, not a bug. With tagging a chat message can be part of several different conversations at the same time, even across channels. Which conversation you are presented with depends on which tag you are viewing.
>I mean, that's the difficulty with any system... getting people to use it. If your team can be disciplined about the tags, then I'm glad that works for you. I not sure it would work well in many other contexts.
In my experience, this is often the biggest hurdle in implementing any revolutionary system (as opposed to evolutionary) that makes a big change in how people do things. For messaging, there are systems with a reminder feature similar to most email client's behavior when there's no subject. For instance, "This message has no tags. Messages are required to have at least one tag, and should have between 2 and 7".
You need management to force the issue though. An approach I've used in the past is to find a competitor or two using the technology, and use business/financial FOMO as a motivator.
Also, if you do a typo in an email..it's there forever. A typo in a chat can be fixed in many systems.
In a desire to be fair, I will add two reasons to use email:
1) If you are doing CYA. Email can't be changed, and is routed through a number of servers, possibly leaving log fingerprints. Email also has bcc. Anything that is important you can bcc to a second friendly party to prove you sent it, or to a personal email account (do this with trade secrets, or heaven forbid - classified - and you should get what you deserve, and I don't mean in a good way). If you want a paper trail, don't use chat.
2) If you are sending a document. Most businesses have virus scanners built into their email server software. A document is typically sent, retrieved, and saved somewhere. Though, if a document will be referenced often by many, neither chat nor email are best. Use a wiki, or something similar.
I'm not one to defend slack, but there's nothing inherently temporary about slack. And searchability > manual categorization.
Also, your "database", singular? Was the answer something like 10 times? Would that scale?
That's the crucial point here.
UIs need to help users to find the appropriate tags, often tagging is either included implicitly, which leads to forgetting or clunky, which leads to aversion.
Every single discussion happening on Slack or Discord will probably be lost in a year or two and is impossible to find unless you happen to be already aware of it.
Developers should not use these platforms for anything with any value. This is not the way to share information.
It's the fact that slack and discord are essentially walled gardens that do not allow for third-party indexing. Therein lies the problem.
If public discord servers were indexable you'd have no issue with it.
But I'm picking my battles at this point in time. And the lack of indexing is the most critical flaw and one I think is immensely damaging to technical communities on those platforms.
Mozilla Hubs springs to mind but there are many more. It's become the norm. It's crazy and more people need to speak out if we're not going to lose a big chunk of a generation's tech knowledge.
I use it on a daily basis to discover the reasoning for things that happened before my time. I've never known anyone else who does this, and I've never understood why.
It's a weird way to try to save money, imo. Down the line it just leads to confusion and repeat work.
They also underinvest in documentation, with the same result.
YMMV, of course. But my mileage was pretty terrible.
My current job has both Basecamp and Slack. Most of the work discussion happens in Basecamp, which is fine. However, the search is pretty awful, so it's hard to get a quick and relevant response back when trying to find out more info about a given setting, feature, piece of code, or whatever else. There's a lot of extra digging involved with Basecamp's search results.
Every bug or feature request was a ticket. Tickets sometimes had quite long discussions.
The advantages were:
* Permanent, so you thought about what you wrote.
* Public, same effect.
* Sequential, so it was very rare for people to reply over each other.
* Goal-oriented, you wanted to move towards resolution, which was then archived forever.
* Opt-in for following, so you had some control over your attention.
* Available, so you could search and see old attachments etc etc.
* Safe, Local, easily self-hosted and backed up.
* Customizable, e.g. easy linking to the repo even if you change repos.
The more things moved to various forms of the all-consuming Jirapoly, the attention sink of Slack, the anarchy of mail+chat, the less useful and (importantly) the less productive these conversations became.
Think of all the knowledge and employee-time locked away in the scrollback of a chat based community forum.
Better to have chat for informal community discussion, but when someone asks a question that others in your community might find useful in the future, politely direct them to post it in a more permanent (read: accessible via google search) medium.
1) Community member asks question.
2A) Answer is already in documentation, which can be easily linked to.
2B) Can be answered in-line, with an action item to add clarification/more details to the docs.
This feels like a pretty scalable solution for the most part. If there are still recurring questions you might want to look at the discoverability/layout of your docs, but usually I've found that other community members start linking each other to docs if the same question comes up again and again.
The irony is that the company happens to be the world's largest platform for easily findable/joinable permanently archived conversations. Go figure.
This was much better than Slack + github + email + Confluence + Teams + file shares + SharePoint -- no one knows where anything is or which chat system a conversation was on. Searching Slack is a fool's errand.
I attribute the failures of these systems to be their reliance on the pattern of centralised SQL+httpd+templated crud+js vs federated standardized exchange+text.
In modern web apps the client is embedded in the app by its very nature, and so the proprietary nature of each system makes community contribution impossible.
I disagree with the notion that "live chat is for the things that can get lost." If the chat platform you're using has advance search features, announcement channels, and message pinning you can easily find information you're looking for and, in my personal experience, this is usually faster than searching through emails. Despite their major privacy concerns, Discord has an amazing search implementation that I wish more developers would take inspiration from.
Perhaps my view is influenced in part by my young age and by the culture of the company I work for, but I've always felt that people around me waste valuable time formulating emails to try to capture all edge cases of the reply. And usually this doesn't work, so multiple follow up emails over the course of an hour or even multiple hours are needed for something that could have been solved over text chat in mere minutes.
These are only useful if the chat content is suitable for search. Searching human conversation is much different from searching content crafted for long term usage.
Also, there is the problem of what to search for. Many meaningful discussions may be lost in conversations that do not explicitly mention the topic but build upon the context.
Great many ideas can be expressed in a few words and these may not be searchable.
Slack is an attempt at legitimizing and organizing stream-of-consciousness. It has short feedback loops and therefore cannot communicate deep research, novel concepts, nor well-cited evidence.
This is the wrong way to bring the tools of the consumer to the enterprise. Nobody asked for this chat tool - Slack is something sold to somebody who doesn't want to worry about something, not somebody who wants to do something well with low attrition.
Over time, our usage of Threads quickly decreased. If decisions needed to be made, we had a meeting to cover it. Meetings always had a few days notice with a written agenda and problem context so that everyone could think through their ideas beforehand. The end of a meeting usually resulted in a decision, which would then get documented in Notion for posterity. The documented decisions and reasoning would be circulated for approval by everyone that was a part of that meeting to verify that nothing of importance was missed. Once everyone approved, the decision was locked in.
As our process developed, we found that the need for written back-and-forth on decisions was less necessary. Instead, when we identified that an issue needed to be solved, we identified the key components of the problem, gave everyone some thinking time, and knocked it out over the course of a call. We rarely need to revisit the decisions since we write out the reasoning afterwards.
I still love the concept of having a tool specifically for asynchronous discussion. However, I think these tools assume that the conversation is the important part when in reality, the only part that matters is the decision and the reasoning. If you can get your team to document those, you'll be just fine.
<- your comment never goes here
> > > > person 1 original message paragraph 1
> > > person 2 first response to paragraph 1
> > person 1 response to person 2 first response
> person 2 response to 1's response
<- your comment goes here (the context is still paragraph 1, anything about this goes here not some place else)
> > > > person 1 original message paragraph 2
> > > person 2 response to paragraph 2
> > person 1 response to above
> person 3 response to above
<- your comment about p2 goes here
> > > person 2 elaborates
> > 1 responds
> 3 responds
<- your comment on p2's elaboration goes here
<- if it cant fit the 3 previous topics it goes here.
It was probably either in his interview on The Knowledge Project or a recent episode of his own podcast. Probably the former since the latter usually focuses on what other people are doing instead of his own company.
If it's important, it needs to have a URL.
Your issue tracker works, assuming you're not constantly changing your tracker. SharePoint may work but is super clunky for this purpose. Confluence or Notion or something work just fine.
Email doesn't work by itself. With some mailing-list interface on top it may, but that seems like you're stretching a bit. IM/IRC/Slack/whatever chat also don't work for this purpose.
I always think: if I want to put a link to this project's design docs, maybe some meeting notes, so new hires can come up to speed on what we're trying to do, I want it to be a URL that makes some kind of human sense, and I want the format to be conducive to communicating the right details.
Announcements you want everyone to see go in 'Updates' So if you finished a feature or are starting work on a feature, or have a doc to show everyone...
Everyone working on that project will have notifications turned on for the projects 'Updates' channel and will read everything on it.
All general chat about the project and also responding to and chatting about stuff in 'Updates' channel happens in chat channel.