If it will matter after today, don't talk about it in a chat room(critter.blog)
critter.blog
If it will matter after today, don't talk about it in a chat room
https://critter.blog/2021/01/12/if-it-matters-after-today-stop-talking-about-it-in-a-chat-room/
328 comments
There is really only one fundamental problem with email: its mechanism for managing who takes part in the conversation is all wrong for team communication. The symptoms of this problem are myriad: reply-all storms, cya-by-cc, replying to a 5 month old email rather than starting a new thread, fyi forwards, etc.
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.
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.
I hate it when I'm emailing someone with a deliberately long response and by the time I send, the thread has already gone on and I have to re-merge it.
The obvious solution here is to not merge the whole thread into your email, instead including only the parts of the message that are directly relevant.
I’d like to see email clients offer a nice one-click “rebase on top of latest” button.
Dang. I never thought of email like that, but I wonder if email+git+UI would help for complex conversations.
Sounds a little bit like Google Wave.
Wave seemed to me to be an unimaginative copy of other threaded comment implementations. The indentations seemed to waste valuable space on each page. Allowing anyone to edit anyone’s post seemed insecure. If I hadn’t known it was Google, I would’ve thought it to be a bad college project.
> Allowing anyone to edit anyone’s post seemed insecure.
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.
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.
There’s a difference between interjecting “What he was trying to say is...” and changing the words he used; those weren’t his words.
Now I'm sad.
You should look at the git mailing list. They actually send patches via email using the git format-patch and git send-email commands and have complex discussions around some of the patches.
It kind of does: https://public-inbox.org/README.html
It's used for LKML (and many other lists) archives: https://lore.kernel.org/lists.html
(but it's read-only, there's no rebasing, people still use old-school e-mail clients)
(but it's read-only, there's no rebasing, people still use old-school e-mail clients)
If it is worth the wait, announce your response or make a list of notes from which you can build the long response after things calm down.
Some of these are solved by things like a corporate NNTP server or mailing lists, right?
Not really, because it still doesn't give people sufficiently fine-grained control over demands on their attention.
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.
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.
What’s the difference between that sort of topics and news groups or mailing lists (with archives)? If I want information on something, subscribe; if I don’t want information, unsubscribe: I can always follow/search the archive (or read digests)
The archive on NNTP is a first-class artifact that you can interact with in your newsreader via NNTP. You can do things like reply to old threads.
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.
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.
IMAP and Exchange support archives and subscriptions.
It's a second level of organization/subscription so that you can have more fine-grained control over how much you get spammed.
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.
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.
In a newsgroup, you don't get sent anything. You can go to the group and see what's new. If there's a particular thread you're not interested, tell your news client to ignore it; if there's one you're particularly interested in, tell your news client to watch it:
https://superuser.com/questions/458136/thunderbird-watch-or-...
https://superuser.com/questions/458136/thunderbird-watch-or-...
But the solution is exactly the same: create a new mailing list or newsgroup under the sort of circumstances where you’d add a topic to a forum or a channel in a Slack workspace. Open source projects, for example, will have foo-announce, foo-user, foo-devel, etc.
Or use digests, mail filters/folders and a convention for tagging message subjects.
Or use digests, mail filters/folders and a convention for tagging message subjects.
So, that's the top level. The 2nd level would be more analogous to individual email threads within those groups.
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.
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.
Well, whether they’re good or bad UX depends on assumptions about whether the second-level categorization is more meaningful organization-wide or on a user-by-user basis.
when you subscribe, you then get sent everything.
1. Killfiles
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.
1. Killfiles
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.
But isn't that how the typical chat works? Where's the difference? At least that's similar to how the channels in my company are organized. The only difference might be that there's faster feedback in a chat and this leads to shorter posts/messages. But I haven't really used any forum software in the past decade, so I don't know if they don't have similar notifications and unread status icons on threads today.
The problem with chat is the interruptive, thoughtless nature of it. In a large organization, you want durability that you won't get from chat.
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.
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.
... why ... not ... just mute it? Also Slack's entire business model builds on storing chat for long and it has a not too bad search. (Though I hate it, because it's slow. But GMail is slow too. Even Thunderbird is, probably because it touches IMAP or whatever for just displaying what I'm currently typing.
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.)
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.)
I have found Slack search at work just sucks. Whenever I tried it gives wrong priority to results. Plus questions and replies are too short and search can not pickup on context.
Sounds like the approach taken by zulip. Check it out, it's a cool paradigm
Some of them. In a previous job this was actually the solution my department ended up using - one box running Mailman, with various lists set up for things like special groups, people who need to receive alerts on specialized systems, stuff like that.
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.
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.
I can't speak to how good or effective it is, but the issues you mentioned are, I think, why the rust-lang community communicates through Zulip (instead of email, IRC, etc).
There are many problems with email, not just one. Sure, we have SPF, DKIM, DMARC and S/MIME, but they're not used by most people. Especially the most important one, S/MIME (to encrypt your messages/ keep them private).
All but the last are used by everyone as it is basically impossible for mail to be accepted reliably from an email server that doesn't have those set up correctly.
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.
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.
I'm surprised if that's actually true. I would guess that most peoples' personal and work email accounts are managed through providers like Google or Microsoft, which do enforce all of those security protocols.
Their business products definitely don't enforce S/MIME by default (which is prohibitively difficult with external contacts anyway), and they recommend to set up the things like SPF and DKIM. They usually don't host your DNS so they can't do it for you (though they do tell you exactly what to set and provide a checker to see if you did it right!)
SPF, DKIM and DMARC are mandatory if you want to interact with the big email providers. In practice, you really want to set these up.
Most things I've seen require/enforce S/MIME.
What's wrong with mailing lists?
Idk about the company you work at or projects you watch but most people know how to use mailing lists.
Slack and all its clones are based on the chat room model, which structurally has the problem described in this article (and many others for productivity, such as wasting attention). Fundamentally, the chatroom model pioneered by IRC is poor for asynchronous communication because you can't sustain temporally overlapping conversations in a channel.
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!).
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!).
I get that you're just trying to get your software out there, but your modern features that email doesn't support are just wrong.
>shared history 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.
>markdown formatting 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.
>Image previews 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
>emoji reactions 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.
[1] https://begriffs.com/posts/2020-07-16-generating-mime-email....
>shared history 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.
>markdown formatting 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.
>Image previews 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
>emoji reactions 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.
[1] https://begriffs.com/posts/2020-07-16-generating-mime-email....
This. I mean I get that there are various different chat or chat/email hybrid solutions nowadays that are competing with each other.
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.
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.
> 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
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.
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.
Just because they're unrelated to software does not mean that everyone will understand. I can't really tell you what makes them hard for people, I can only guess.
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.
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.
We've been using self-hosted Zulip for about 18 months now, and it's exactly what our company needs.
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 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.
Same here. If you like email, Zulip is what you need.
You can also use something janky like matterbridge to link with other things (poorly). Depends on your use case for federation.
https://github.com/42wim/matterbridge
https://github.com/42wim/matterbridge
Zulip really hits the sweet spot for a communication tool. Especially with large amounts of users communicating across many different threads. The FHIR community "chatroom"[0] is a Zulip server and is indispensable for communication and knowledge building across thousands of users.
[0] https://chat.fhir.org/#
[0] https://chat.fhir.org/#
I signed up for that to see what Zulip is like, but there are only 19 messages visible if you do that, so I shouldn't have bothered. It seems nice, I guess.
New users on Zulip instances get 20 unread messages by default – I guess you marked one read. The full history is available to you.
From looking at the tour slides, a list of threads in the current chatroom (which Zulip calls "topics") does seem nice. I have often wished I could get Slack's all-new-thread-messages view filtered by channel.
Zulip sounds a lot like a modernized bulletin board/forum. It’s interesting how we keep coming back to the same ideas again and again.
> just fucking use email.
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 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.
Basecamp does this well, especially version 2, which integrated with email. With version 2 you could have topics in Basecamp which you could post directly do or email and it was searchable and linkable. It was even possible to post messages which were optionally emailed to clients, with their response becoming part of the thread history. Really the best of both worlds. Unfortunately they removed the email feature in Basecamp 3 (and my company upgraded) so we can't do that anymore, but older projects retain their history.
Yeah, basecamp is pretty good at this. It is a pretty solid tool for building projects where having communications and documentation is intermixed is important.
I didn't realized they removed the email piece... seems like a downgrade. Particularly for projects where you have fairly casual participants.
I didn't realized they removed the email piece... seems like a downgrade. Particularly for projects where you have fairly casual participants.
Mailing lists is the answer.
- Achievable
- Searchable
- Linkable
- Asynchronous
- Accessible
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.
- Achievable
- Searchable
- Linkable
- Asynchronous
- Accessible
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.
I've commented this too much in this thread, but it's important: Zulip solves all this, has other advantages and a fast and extremely usable interface.
Is there anything in particular you don't like about Zulip?
The UI looks a bit outdated, but it's so fast and usable that I don't mind the aesthetics at all. It had some annoyances like the inability to move topics, bit AFAIK they solved that with the latest release.
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.
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.
Thanks for the reply!
I'm intrigued by the Guest option. Do you think it's a good way to communicate with the clients during longer projects?
I'm intrigued by the Guest option. Do you think it's a good way to communicate with the clients during longer projects?
Yeah, I've used that and it worked well (though I haven't used it extensively). As long as clients don't get confused by the UI, it's great, but it might take a bit of onboarding due to the different UI (though in its core it's just "Slack, but everything is a message thread").
[deleted]
This is why most replies include quotes.
But yeah for groups you need a mailing list with an archive. It's still better than most IM apps IMO.
But yeah for groups you need a mailing list with an archive. It's still better than most IM apps IMO.
Yes, but quotes are pretty limited in usefulness, particularly since different clients quote email differently and threads can get shredded quickly.
> 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)
> 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)
We have IMAP URLs that address some of this.
Many organizations seem to use Outlook/Exchange and configure Exchange to make it difficult to use other mail clients (not enabling imap, not enabling caldav support so that a separate calendar and email client need to be used unless you use exchange, etc). Outlook is truly awful as a mail client and it would make one want to use anything else.
I've been using Outlook for 20 years or so, and I generally like it. Lots of features, some of them are borderline unique. For instance, I wonder which e-mail clients allow to create complicated rules that are then running on the mail server as opposed to that client?
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.
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.
That feature of course needs support server-side, but Thunderbird does have a Sieve add-on (in case sieve is enabled/available on the server).
I don't use it myself, since I prefer to edit the sieve filter file directly instead of using a GUI for it, but the option is there.
I prefer to right-click on e-mail and "create rule from message" from context menu. Also, the feature doesn't require any steps to configure, install or enable, it just works out of the box.
Unlike the Outlook+Exchange combination Sieve is an actual open standard (RFC 5228 & RFC 5804 & co) though that can be implemented by all mail servers and mail clients. Or is the Outlook+Exchange feature based on the same?
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".
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".
Exchange rules configured through Outlook are omnipresent.
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.
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.
I recently switched some of my email addresses to Migadu. I haven't tested it yet but they apparently offer Sieve support.
> Or is the Outlook+Exchange feature based on the same?
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.
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.
Is it really that bad?
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.
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 takes to long to start up in the morning. If it could start instantly I'd walk into the conference room on-time, but instead I'm several minutes late. Now that I'm working from home it needs to get the chat client started instead, but the the end result is the same, if I'm not running early I'll be late to important early morning meetings. (my early morning meetings are with India, so they will quickly assume I'm not joining at all and head to their supper - timezones are such that the best time for everyone is my breakfast and their supper)
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.
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.
There is something very wrong with your Outlook and/or Exchange install if it takes "several minutes" to start.
I've used Outlook in several organisations over the years, and start time has always been in the order of 5-10s.
I've used Outlook in several organisations over the years, and start time has always been in the order of 5-10s.
For me it takes less than 2 seconds to start up fully. Not sure what is wrong with you guy's computers. Maybe you need an SSD or more RAM.
Took about 10 seconds. Using a mobile workstation with an SSD and 32GB of RAM. Maybe I should go for 64GB? :D
Outlook starts faster for me than Slack.
>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.
Install Thunderbird[0] and use it for a week. You'll be able to tell the difference very quickly.
[0] https://www.thunderbird.net
Install Thunderbird[0] and use it for a week. You'll be able to tell the difference very quickly.
[0] https://www.thunderbird.net
I'm a Thunderbird user, but I don't really think that there's a clear winner in that comparison. Outlook has features that Thunderbird has been missing for over a decade, like reliable send-in-background (and other database operations in background unlike Thunderbird that likes to interrupt you to ask permission) and a far more mature calendar product.
>I'm a Thunderbird user, but I don't really think that there's a clear winner in that comparison. Outlook has features that Thunderbird has been missing for over a decade, like reliable send-in-background (and other database operations in background unlike Thunderbird that likes to interrupt you to ask permission) and a far more mature calendar product.
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[0], including OWA[1].
[0] https://en.wikipedia.org/wiki/Email_client
[1] https://en.wikipedia.org/wiki/Outlook_on_the_web
Edit: Clarified Outlook/Exchange integration vs. Outlook as client.
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[0], including OWA[1].
[0] https://en.wikipedia.org/wiki/Email_client
[1] https://en.wikipedia.org/wiki/Outlook_on_the_web
Edit: Clarified Outlook/Exchange integration vs. Outlook as client.
I tend to really harp on send-in-background because I view it as a core feature of an MUA, but as far as I know it's still hidden behind an about:config flag in Thunderbird because it has an excessive number of known bugs, and it's been this way for many years. Another ongoing pain with Thunderbird is the inability to switch between HTML and plaintext when composing a message. Outlook lets you do this, in Thunderbird you have to copy the message, discard it, start a new one in the right mode and paste.
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.
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.
Outlook.com and the current version of OWA in Microsoft 365 are nearly the same. What are you still missing? (If you’re on-prem still, you’re probably running a much older version)
In terms of experience using the product, I feel the Fastmail client handily beats both outlook and gmail.
I agree, it's the user experience I notice the least. It doesn't get in my way at all, and I don't recall it changing or if it has the changes have been so mild and consistent I haven't noticed.
It’s the worst. Unless you have to use any of the other ones.
So you're saying you'd rather lose all the productivity benefits of a solution that's not instant messaging than use Outlook? Powerful stance!
I worked at a B2B startup that had chronic problems w/ team members sharing documents in way that our customers thought were insecure. These were some of the biggest companies the world.
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.
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.
There are various services like WireDoc, ShareFile, etc, or even Mozilla's deprecated Firefox Send that canonized this (encrypt on one channel, share the password on a separate channel).
Email isn't searchable by people who weren't on the threads. In an org that uses IM well (they exist!) the chat system actually becomes sort of like a wiki, except a lot more helpful.
If someone told me "that is documented in the chat channel, just search", my response would be "ok. So it's not documented."
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.
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.
Eh, for the golden path, sure (say, having a service documented).
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.
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.
And email solves that? Or you are suggesting both chat and email do not solve the issue?
Yes, I'm saying neither chat nor email solve this issue.
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.)
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.)
Mailing lists exist.
Mailing lists are not heavily used outside of free software. In the corporate world I’ve never had a project provide a mailing list to be used for discussions.
Tools exist even if you don't use them.
Many companies use Outlook groups. Those are mailing lists.
Many companies use Outlook groups. Those are mailing lists.
Not in the sense that they’re searchable / archived on a listserv.
They are. Are you thinking of distribution lists?
Your point is valid, but not exactly correct. I don't want to know just what was decided, but why. Often I will come back to "should x be updated" again and again. Knowing the factors in the last decision is very important. More than once I've pushed to update x and had someone say "we can't for good reasons that I forget". Often I've spent weeks redoing the discussion before someone remembers/discovers why we can't do the update and we all go "whoa, I'm glad we didn't do that". Other times we discover/remember why we couldn't update and they are for reasons that no longer apply and so we do the update. Still other times we never discover any reason why we shouldn't update. Last sometimes we discover why we shouldn't have updated after it is too late and we have a mess to undo while backing out the update.
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.
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.
While I fully agree about the need to record reasoning, my approach is to summarize and put it in either wiki or a ticket. Future me doesn't want to read a long chat or email thread (whether it was one I was involved with or not), and I assume no one else does either.
That's just not true, Slack in particular is quite searchable. Anyway, weren't we talking about email, which is even less searchable?
Except you can only find stuff by spelunking with search, hoping you hit on the right set of keywords and then scrolling through a jumbled mess of hits. Wikis are organized and have navigation. Also being at a company that uses email and Slack, I will say it is very very rare that anyone actually uses Slack to search for conversations they weren't in. Email has other weaknesses of course but in general I agree with the point that Slack is actually worse in many use cases.
Mailing lists (aka Google Groups if you're on GSuite) allow retroactive access.
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.
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.
> Email isn't searchable by people who weren't on the threads
Chats have the same problem: they aren't searchable by people who weren't in them.
meanwhile https://lkml.org/
Chats have the same problem: they aren't searchable by people who weren't in them.
meanwhile https://lkml.org/
[deleted]
One cannot search channels one is not part of. Don't forget channels. Not everything happens on #general and #random.
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.
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.
>the chat system actually becomes sort of like a wiki
That sounds horrible and very fragile.
That sounds horrible and very fragile.
Absolutely, it is. It's still miles above every single corporate wiki I've tried to use. Your milage may vary.
So, you're worried about this
> 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 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?
For email that conversation probably has taken place already. Also, lots of larger orgs have internal mail servers where this isn't even remotely true.
Orgs have internal chat servers too.
They aren't talking about internal chat. The article suggests trying out several third party SaaS discussion forums like Discourse/Carrot/Basecamp. It's unlikely most orgs have internal servers for these services. GP is pointing out that using these third party SaaS discussions forums is usually a nonstarter unless its first been pre-approved by legal (whereas email is almost certainly already approved).
> The real answer is: just fucking use email.
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 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'm willing to bet money that for every company that deletes emails older than some age also deletes Slack messages, and deletes then sooner.
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.
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.
Our email has a 90 day retention window, and Slack is permanent. We're the largest in our industry.
Isn't that just a company policy? At some-point, the lawyers will get clued-in and require that even on Slack and other company-wide chat there be a limited retention window!
Cool! Where should I send bet money?
Do the people who wrote the email policy know that Slack is permanent? That sounds like the kind of thing that could easily be not-understood by legal.
Yeah this policy mismatch definitely seems like a "nobody in legal has noticed yet".
They're gonna notice real quick the next time they get sued by somebody clueful enough to subpoena that goldmine.
They're gonna notice real quick the next time they get sued by somebody clueful enough to subpoena that goldmine.
Have your Slack chats been subpoenaed yet?
If not, you are very lucky that you are being sued by people with incompetent attorneys.
If not, you are very lucky that you are being sued by people with incompetent attorneys.
[deleted]
That sounds like a pathological case. How many companies actually do that?
Many, at least in the US. It's not just companies, government agencies also have similar needs due to sunshine and open-access laws.
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.
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.
That's weird, my company has the opposite policy. Nothing can be deleted. Employees can delete emails on their side, but the server keeps a copy of every email indefinitely in a "vault". That's for legal purposes apparently.
Most Fortune 500 companies have a document retention policy that every employee needs to read the generic training video/documents on when getting hired and agree to.
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.
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.
Also depending on industry you may by law need to delete things.
Usually that varies by legal department.
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!
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!
If they do store persistent documentation in emails, the problem lies somewhere between the chair and the keyboard.
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.
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.
The legal retention policy itself looks persistent. How is it documented?
Use Zulip. It solves all the problems that email has and also enables a bunch of other things you never knew you needed, like a sane model for browsing messages.
It can even serve as real-time communication for #random and other such work-adjacent channels.
It can even serve as real-time communication for #random and other such work-adjacent channels.
One problem/feature with email is that that new collagues do not see historical conversations. While the typical chatroom is searchable.
Trying to have sensible conversations in an enterprise email client, where 90% of the messages are just garbage is basically impossible for me.
I'm not sure what you mean by the universal availability of the email. It has the same deploy/configure/security issues any other tool has. It's even worse, because you can send email to "outsiders" unless certain rules are in place. The UX is bad and depends on email clients.
Those emails are only available to the users participating in them, and in some places are automatically deleted after a certain amount of time. The point of TFA is knowledge capture, and email isn't transparent enough for sharing knowledge.
We made FWD:Everyone (https://www.fwdeveryone.com) for this exact problem. It works via a Gmail add-on, so you can upload an email thread after it's over without having to grant OAuth access to your inbox. It makes these threads taggable and searchable within your company, and formats them to make them look beautiful.
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. :-)
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. :-)
Hi Alex! Glad FWD:Everyone is still going strong. I'm still waiting for it to become the dominant way of presenting email correspondence in media, like embedded tweets :)
Enter team aliases and topic-based distribution lists.
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.
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.
This gives me an idea. What about setting up an archiving script?
After a archive-worthy discussion in email, you forward the thread to "[email protected]". The script will parse the email chain and generate a static web page hosted on a local server.
After a archive-worthy discussion in email, you forward the thread to "[email protected]". The script will parse the email chain and generate a static web page hosted on a local server.
> After a archive-worthy discussion in email, you forward the thread to "[email protected]". 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.)
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.)
> Unfortunately there isn't any such thing as "forwarding an email 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.
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.
> 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.
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.
You don't want a bot to archive it. You want a human (or an AI smarter than what exists today) to create a summary.
Everything you have in your archives will be taken out context, misinterpreted, used against you in court.
Everything you have in your archives will be taken out context, misinterpreted, used against you in court.
Is this the part where we pretend your organization doesn’t already use something like a ticketing service, wiki, etc? I find it hard to believe you don’t have any sort of tool to post information already. If it’s true, run.
I just love well thought out emails. They can provide a lot clarity and be the basis for great discussions.
Talk to your lawyer on this too. Our lawyer said emails with the lawyer in the conversation will have client attorney privilege, is not court admissible. I dont know about IM.
> Our lawyer said emails with the lawyer in the conversation will have client attorney privilege, is not court admissible.
That's too-sweeping a statement [0]:
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.
[0] https://www.nolo.com/legal-encyclopedia/attorney-client-priv...
That's too-sweeping a statement [0]:
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.
[0] https://www.nolo.com/legal-encyclopedia/attorney-client-priv...
I can't agree with this essay more.
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.
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.
I should also add two more important pieces to this:
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.
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.
Hey James, I'm building something along the same lines (I don't mean to be too spammy, so there's a link in my profile). It sounds a lot like what you're describing, but is being built from the ground up with this use case in mind.
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.
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.
Thanks for all the work you’ve done for ETH! It has enriched my life greatly, and I am so excited to see where things go post-EIP1559 and 2.0!
You're welcome! I've only played a small part in this amazing phenomenon, mainly DevOps and community-organizing. But it has been amazing to do anything to help.
I find this somewhat incomprehensible. Why the bias for seeing and archiving everything? The implicit model, which is right there in his title, is "talk", which is not naturally archived.
I've built products just fine using verbal communication nearly exclusively. [1] 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.
[1] The main exception being index cards with a few words on each. https://williampietri.com/writing/2015/the-big-board/
I've built products just fine using verbal communication nearly exclusively. [1] 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.
[1] The main exception being index cards with a few words on each. https://williampietri.com/writing/2015/the-big-board/
I think the basis of the article is that a lot of people use Slack as a storage of sorts for things that should be archived. That certainly aligns with my experience - I've worked in teams where I've asked for a document or credentials for something and have been told "It's on Slack, search for it".
In my reading the point of the post is that it's important to have a record of the important things (like why did we decide to do X, or to do it in this specific way), and that putting such discussion in the same context as things that aren't important to record makes it very hard to filter out the important bits later on if needed.
So they advocate for putting the important information in a separate context, that also allows for more thoughtful conversations.
So they advocate for putting the important information in a separate context, that also allows for more thoughtful conversations.
That's a plausible interpretation, but the notion that "important=anything that matters for longer than 1 day" still makes no sense to me. And I also disagree that it's a priori important to have a record of important things. It's nearly tautological, and even if it weren't, there are some strong embedded assumptions about how to build software that at best need close examination.
It seems you disagree, which is fine. But that is very different from the blog post being incomprehensible.
I understand the words just fine. It's the motivation I find incomprehensible. In particular:
> 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.
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's what vacations are for. The whole point is to miss things.
> 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.
> 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.
You're definitely correct about bank employees. I know people who've been required to take vacations as a matter of policy, and fraud prevention is how they explained it.
No, the purpose is to give people time to do what they think best. For them to no longer have the demands of the organization paramount. That is, to miss things.
Talk was not naturally archived in the past, but I would not assume that today. There is no longer anything that is an intimate object, pretty much anything can have a microphone and some type of wireless connection. Is your desk phone at the office listening to you even though it's on the hook? Technically it can. What about your smart TV?
> I find this somewhat incomprehensible. Why the bias for seeing and archiving everything? The implicit model, which is right there in his title, is "talk", which is not naturally archived.
Somewhat harder to do now that we are all WFH.
Somewhat harder to do now that we are all WFH.
I have always thought that Slack is designed to make information go away, and that's why people like it. Email never goes away unless you archive the thread. If you have a bunch of things that are going on, you open your inbox and realize just how behind you are, every time you open it. Slack, conversely, scrolls up and always looks the same. If you miss something, the world moved on without your input, and you feel the same.
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.
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.
amusingly, my understanding is that the original goal for slack was to be an archive.
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 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.
Doesn't slack have full history if you pay for it? We use Teams and I regularly find myself searching for stuff I remember I was sent months ago.
It does and today I just learned that there are some companies that don't store all messages sent. Slack works great at my company, I can search for things a year or more back and even write messages to myself as a form of note taking.
My company has slack archives going back ten years. They imported everything from the old chat system.
[deleted]
I don't know of any productivity tool that handles archiving well. You can store done tasks in some way, but all the context is lost. Over time, it's annoying even on a small - individual - scale.
I think Azure DevOps handles context pretty well. I can look at old tasks and see associated commits, conversations, and related work.
yeah, the info is there and you can do the same with most tools, but it often requires a lot to extract it. how well organized is it? how hard is it to go from line of code to complete discussion around when it was last changed?
Well, a real paid slack instance doesn't go away. All the public free slacks do.. The whole fact that Slack charges a lot for the privilege of keeping history beyond a couple of months, proves that it's worth a lot to many people.
Yes, but as gmail has illustrated, that just shifts the problem. Where before your problem was "It got deleted". Now the problem is search pulls up too many things.
Slack seems to be even worse because unlike email, you don't really have subjects or thread beginnings, just continual flow of chatter.
Slack seems to be even worse because unlike email, you don't really have subjects or thread beginnings, just continual flow of chatter.
You can make threads in slack. The implementation is a bit weird but (as of last time I used it circa 2018) it did the job sufficiently. For features which required more focused discussion from a sub-team over a longer period of time there was a pseudo-room feature (I don't remember what it's called though)
I don't really have this issue with Gmail. It works a lot better than O365 search with the same amount of mails in it (I recently migrated everything over).
But indeed the lack of organisation of any kind makes it harder for chats.
But indeed the lack of organisation of any kind makes it harder for chats.
I'm confused. What are the differences between Slack and email? Both are generally displayed on a relatively small list where new messages eventually cause old messages to be hidden. Those hidden messages are still accessible if you try, both with similar processes (assuming you're using an email client with text search like Gmail).
Corporate Slack retention is typically measured in days, while email retention is measured in years.
> I have always thought that Slack is designed to make information go away, and that's why people like it.
I think it's exactly the opposite?[0]
People like it because, except for the free plan, you can find anything that was ever discussed.
[0]: https://slack.com/pricing
I think it's exactly the opposite?[0]
People like it because, except for the free plan, you can find anything that was ever discussed.
[0]: https://slack.com/pricing
I have a paid Slack plan and while I can find specific threads where I remember a lot of the details, I've never found anything that I didn't personally participate in.
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.)
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.)
This is exactly why at my org, slack is one of the de-facto sources of truth. And it's awesome. I can often find the solution to a specific, niche problem that someone else discussed 4 years ago in a few seconds. Assuming your org pays for whatever it is that allows full archival, it's a great way to capture org-specific, tribal knowledge that you won't find on google, but that nobody will take the time to add to an internal wiki or something accessible beyond their immediate team.
If you want a chat nightmare, try microsoft teams. That quickly became one of the most painful parts of one of my previous workplaces.
If you want a chat nightmare, try microsoft teams. That quickly became one of the most painful parts of one of my previous workplaces.
In a few seconds? Wow. I'm a very fast reader and probably need at least 15 seconds to wade through a busy Stack Overflow page.
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'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.
cmd+k > copy and paste error message > (few seconds pass) > results appear in slack search
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.
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.
Teams is built by boomers, for boomers
From my experience, the mark of a well-run Slack is the ability to find old, valuable information. You're right that it's not always easy, but you can get a LOT further with 1) well-defined channels 2) good use of pinning 3) good use of "saving" messages for yourself.
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.
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.
My experience with Slack is the opposite. Scanning through my list of channels, I'll see some channel I don't recognize, and it will still be pinned at the top unread message 4 months ago when someone added me for some reason.
Despite the “asychronous” claim, you have to keep a steady eye on it and reply in realtime or the conversation will move on without you. Anyone who takes the time to ponder and respond thoughtfully with context and explanation will find that they’re too late.
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.
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.
There's a Slack plugin for time-limited channels from Postlight https://dashforslack.com/
I'm building a collaborative, timeboxed collaboration tool called AsyncGo at https://asyncgo.com. We are pre-launch but have a prototype, and if anyone here would like a demo or has any questions I'd be happy to answer.
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).
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).
The one Discord server I participate in has channels that only allow one message every 15 minutes or so. I think the userbase is roughly divided in two groups: people who are online all the time and people (like me) who check in a few times a day. It's easier to participate in the slowed-down channels.
"Snapchat"-like, in the workplace.
I think part of the problem is not all conversations are obviously 'short and shallow' or 'long and broad'. What starts out casual might unearth something that needs going into deeper, and going in deep on something might not have results worth documenting yet.
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.
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.
I know that AI is a pile of buzzwords, but.... is this something we could train AI to do reasonably well? A flow like "click button and highlight conversation start/end" and it picks out the relevant messages and tries to generate a set of takeaways? (and allows user to edit them before saving).
AI (or some primitive concept of...) could be useful in some aspect, perhaps for sugggesting tags or categories the information looks like it could belong to. Actually extracting the "facts and takeaways" sounds very hard but then I'm not a linguist so maybe there are methods.
I disagree with this article.
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.
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.
I don't know about that. There are a few large differences between chat and email, so it's not a great comparison.
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
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.
These are great points, though I disagree with all of them as reasons to prefer email over chat.
> 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.
> 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.
Exactly, I completely reject the premise of this article. In the last hour I searched the "alerts" channel to see how many times our database had high CPU in the last year.
I'm not one to defend slack, but there's nothing inherently temporary about slack. And searchability > manual categorization.
I'm not one to defend slack, but there's nothing inherently temporary about slack. And searchability > manual categorization.
That doesn't seem enough to reject the premise of the article, which explicitly calls out that chats are great for both "Low-stakes status updates" and "Swarming around red alerts or outages", a high CPU alert that was just a notification is the former, a high CPU alert that people discussed and fixed is the latter.
Also, your "database", singular? Was the answer something like 10 times? Would that scale?
Also, your "database", singular? Was the answer something like 10 times? Would that scale?
"as long as people use the tags"
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.
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.
The sheer volume of information that Chat holds makes it hard to search. The noise to signal ratio is higher than on channels with lower throughout (e.g. documentation products). Chat doesn't let you send one message and craft it over time, like a mission statement, proposal, or architecture guide. It has a fundamentally different character.
And some chats are worse than others. Teams does this so poorly it brings my battlestation to its knees trying to do simple text search.
I can find useful discussions from 10 or 20 years ago because they were crawled and archived. IRC, Usenet, web message boards, mailing lists...
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.
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.
The key here is not the format of communication, since you've listed email chains, chat, and forums in one list.
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.
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.
I would still have some issues. I do find IRC archives much, much less valuable than more structured sources.
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.
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.
While I enjoy slack at work (not without reservations, but overall I like it), I definitely agree slack/discord are terrible for communities. I can't imagine how much discussion that even I participated in almost 15 years ago is still quickly available, would now be lost to the ether of discord and slack.
This is desirable. I like that my discord conversation will be gone in a few years. They serve little purpose being archived anyway. Old IRC logs are a horrible thing to search for help anyway. Much better just picking a forum/reddit post on the same issue which will be better sorted.
The problem is that for many communities there is only the Discord. Quite technical communities - building projects they obvious feel will have longevity.
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.
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 just don't see this being as much of an issue as is stated here. I find that over the years its easier and easier to find info. Github issues, reddit, or stackexchange have huge wealths of info that are expanding rapidly.
I'm talking about communities with very little other material footprint. Nearly all discussion is on ephemeral platforms. There are no other knowledge bases to refer to.
It’s probably an unpopular opinion, but the best online technical discussions I’ve ever seen in a company were done in Bugzilla.
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.
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.
Nice I haven't seem bugzilla for a while now, it looks good maybe we can use to replace Jira. https://bugzilla.mozilla.org/home
Slack has fantastic search. It has good filtering, sorting, and pagination, and has the right degree of fuzziness.
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.
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.
I second this, I am actually able to find tons of important communications on Slack that happened years ago at my work. Perhaps it is not well understood by many? I somewhat agree with the author, but what is the alternative to Email or a Chat Application?
A product that does threaded conversations. Yammer did this pretty well, shame it never really took off for businesses
That's encouraging. I haven't had the same experience yet, but I haven't worked for someone who pays for full search history.
Every Slack plan has full search history, so really you haven't worked for someone who pays for Slack. Like, I get that it is expensive, but it's weird to run your company on a product trial.
Yep :)
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.
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.
I have struggled for years to find things that I know exist within Slack. I specifically (as a test) set up my email to forward all mail to a specific address in to Slack (https://slack.com/slack-tips/send-email-to-slack) and found more often than not that Slack could not find something when searching for it.
YMMV, of course. But my mileage was pretty terrible.
YMMV, of course. But my mileage was pretty terrible.
I would do this at my last job, which was very Slack-heavy. I would even bring up any weird dev issues or bits of info that I came across that sometimes only mattered to me at the time, but it turned out to be helpful when I would search for those things months (or even years) later.
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.
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.
Well, Slack search experience could be done better. I prefer to see search results and selected thread with search keyword in the same view. It is annoying to keep going to every thread in the results and going to search bar again if that is not I was looking for.
It sounds like the author was mostly thinking about INTERNAL discussion, but I think the real tragedy is in using chat like Slack for your public customer community forum.
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.
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.
My experience so far with companies that operate in this manner, has been something like:
1) Community member asks question.
2A) Answer is already in documentation, which can be easily linked to.
Or
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.
1) Community member asks question.
2A) Answer is already in documentation, which can be easily linked to.
Or
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.
This is one of the things that drove me nuts at my last company. I had been remote all along, which meant I was left out of many discussions. Chat was my lifeline, because it was the only thing both I and others on the team used. When everyone went remote, we had an opportunity to make a change for the better, but instead nothing at all changed. Meetings were done via video chat instead of in person, but they were just as un-findable and ephemeral as before. If you mapped out the lines of communication before and after, there'd be no difference. In person vs. online matters far less IMO than ephemeral and closed vs. open and permanent.
The irony is that the company happens to be the world's largest platform for easily findable/joinable permanently archived conversations. Go figure.
The irony is that the company happens to be the world's largest platform for easily findable/joinable permanently archived conversations. Go figure.
I haven't yet seen anything better than NNTP (the protocol of Usenet) and a decent news client, which used to mean tin on Unix and MT-NewsWatcher on MacOS. We used to have patches and CVS commit messages on code review groups and fork discussions seamlessly into dev groups. Mailing list email to NNTP gateways allowed ready collab with workers outside the group. Common NFS share allowed easy joint work without huge amount of code & build duplication. And it was possible to just grep every message in the News spool.
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.
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 don't know, it is quite easy to search a well indexed chat for keywords in order to find important information.
Yeah, I think the real solution here is: let's make chat permanently archived and searchable. I find it more useful searching through Slack for old conversations around a topic than searching Confluence for the same.
But aren't these both pretty terrible tools or storing information?
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.
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.
Usually - but the cases where this is both well implemented and stores infinite history, or even very long history, is vanishingly rare.
Sounds like people are trying to asymptotically approach email functionality without actually using email. I do agree that chat stuff has a place, but it seems like the new functionality is just being copy-and-pasted from current email functionality.
I disagree with the conclusion of the article. Using this logic, one could say that you shouldn't speak about long term projects during voice call meetings. I agree that the quality of conversation drops when speaking over chat, but I would also say that communication increases. In my opinion, the increased communication more than makes up for the decline of message quality. I also feel that the author of this article is focused on Slack and Teams. Teams or a poorly implemented slack group can feel very disorganized, so I can see how the author came to the conclusion that they did.
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.
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.
> advance search features
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.
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.
200% agree. First time I've ever really felt young on HN before. People still waste time with internal email?
When we were first growing our team out remotely, we really tried to emphasize this style of thinking. All decisions and larger discussions would need to be written down so the conversation could be easily referenced for long-term context - we chose Threads for this purpose. Any quick questions or one-off communication could live in Slack. Any documentation needed to live in Notion.
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.
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.
I don't know what to call it but some kind of training course, a spec or some other conditioning seems needed to get the best out of email. If the participants know 10 basic things like how and where to insert their responses and do not add 100 graphical signatures to each mail it gets 1000 times more wonderful and enjoyable. Long form doesn't become all that desirable that way. (It seems forums played a major role teaching how to quote to and gmail did a good job making it impossible.) Even on HN we rarely see quotation go on for more than one level.
<- 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.
<- 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.
Interestingly, outlook supports changing colors to help with inline replies and putting your name at the start of your online reply. I am the only person I have ever seen use that feature. Outlook.com no longer has the option.
I forget which podcast it was on, but Automattic's CEO (Matt Mullenweg) talked about how they use blogs internally for much of their communication, so there's a huge searchable archive of information back to the early days of the company. People occasionally write posts to collect useful information that's fallen too deep.
It was probably either in his interview[0] on The Knowledge Project or a recent episode of his own podcast[1]. Probably the former since the latter usually focuses on what other people are doing instead of his own company.
[0] https://fs.blog/knowledge-project/matt-mullenweg/
[1] https://distributed.blog/podcast/
It was probably either in his interview[0] on The Knowledge Project or a recent episode of his own podcast[1]. Probably the former since the latter usually focuses on what other people are doing instead of his own company.
[0] https://fs.blog/knowledge-project/matt-mullenweg/
[1] https://distributed.blog/podcast/
We call the internal blogs "P2s". You can make one yourself even. :) https://wordpress.com/p2/
The way I've always heard this is:
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.
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.
Slack messages all have URLs. They work both in the browser (once you're authenticated) and in the clients.
Or, discuss in chat but make sure to end with a summary email detailing the relevant decisions. Maybe include a link to the chat so you can find it in the future.
How often does that actually happen?
Funny thing, I've worked places where emails were deleted after 30 days but Slack was forever.
Your admin can set retention per channel or per organization.
We use Discord, and have 2 channels for each game we're workin' on. 'Updates' and 'Chat'
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.
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.
I have to agree with this. When we started using MS Teams, it worked really well to replace person to person chats, email etc..
But since it's become commonplace, it's become a crapbucket of stuff that I can't find anything back in. I have too many channels, too many teams (and you can't opt in to channels like you can on Slack, you have to join them all). And the search function is even worse than Outlook's. It's all just too unstructured. Even if I search for someone's name plus a keyword I know it's there it can't find it back for me.
Such an app (not just Teams) is just not the right tool for everything related to communication, even though Microsoft is pushing it as exactly that.
A forum though is too '2000' for me. I would see more in a managed wiki, provided people can stomach working in a structured way. Enforcing that will be an issue but it will result in a beautiful oracle of information. I've seen it happen before (and I've seen it fail many more times, sadly).
But since it's become commonplace, it's become a crapbucket of stuff that I can't find anything back in. I have too many channels, too many teams (and you can't opt in to channels like you can on Slack, you have to join them all). And the search function is even worse than Outlook's. It's all just too unstructured. Even if I search for someone's name plus a keyword I know it's there it can't find it back for me.
Such an app (not just Teams) is just not the right tool for everything related to communication, even though Microsoft is pushing it as exactly that.
A forum though is too '2000' for me. I would see more in a managed wiki, provided people can stomach working in a structured way. Enforcing that will be an issue but it will result in a beautiful oracle of information. I've seen it happen before (and I've seen it fail many more times, sadly).
Slack isn't a bunch of chat rooms, it's a database disguised as a bunch of chat rooms. I've never had a problem pulling up some random conversation from three years ago as long as I remember the general topic.
In that regard it's no different than using email, everything is indexed and you're just searching a different database.
In that regard it's no different than using email, everything is indexed and you're just searching a different database.
Twist (https://twist.com) solves this problem entirely. Instead of chat rooms where everyone chats about everything, it organizes discussions around tasks. Each task gets its own chat room. When you work on task X, you chat in task X's chat room. If you work on multiple tasks, you have multiple rooms, one per task. When you come back to a task, you just open the task's room and continue where you finished. When the task is finished, that conversation is pretty much over. It's a get things done product. No useless chatting and conversations don't overlap. Go use Twist!
I really hope the word e-mail is replaced with something else (like 'memo') and a new paradigm is introduced around the concept of offline discussions, like forum board or stack-overflow.
The purpose of such a system would be to save discussions and understandings in discussions for a long term.
I read Stack Overflow threads now and have a pretty good idea about the thought process from problem -> approaches -> solution, including solutions or approaches that were rejected.
Real-time chat is not a replacement of a meeting, because meetings have substantial outcomes and key decisions taken, that are usually recorded as Minutes of Meeting / Meeting notes.
The purpose of such a system would be to save discussions and understandings in discussions for a long term.
I read Stack Overflow threads now and have a pretty good idea about the thought process from problem -> approaches -> solution, including solutions or approaches that were rejected.
Real-time chat is not a replacement of a meeting, because meetings have substantial outcomes and key decisions taken, that are usually recorded as Minutes of Meeting / Meeting notes.
I actually think Zulip is an exception to this, because its Stream>Topic hierarchy encourages organized conversations.
At my org, we consider Zulip to be an archive of sorts, and make an effort (a small one, because Zulip's UX makes it natural) to organize our communication such that it serves as a source of information for a future date.
I wrote a whole article about this a while back:
https://monadical.com/posts/how-to-make-remote-work-part-two...
At my org, we consider Zulip to be an archive of sorts, and make an effort (a small one, because Zulip's UX makes it natural) to organize our communication such that it serves as a source of information for a future date.
I wrote a whole article about this a while back:
https://monadical.com/posts/how-to-make-remote-work-part-two...
Teams trying to enforce conversation threading in a (semi-)recent update pretty much put a halt to me and my coworkers using Teams for anything but voice for our morning sprints. Trying to follow even slow conversations in Teams is just way too much work, we instead chat on Telegram where chat works, you know, normally.
Luckily we were never in the habit of tracking anything through chat, we stick to our issue tracker, but I can absolutely imagine the frustration we'd have felt after that change had we relied more heavily on chat.
Luckily we were never in the habit of tracking anything through chat, we stick to our issue tracker, but I can absolutely imagine the frustration we'd have felt after that change had we relied more heavily on chat.
I’ve never been much of a fan of realtime chats.
Heck, I even had a personal policy of never scheduling regular meetings (they all needed to be “as-needed”).
However, I worked for a Japanese company, so regular meetings were a part of my life; whether or not I liked it.
I prefer “store and forward” communication (email is the classic form). Working for a Japanese company actually helped, there, as it was damn near impossible to have realtime chats with Tokyo.
If I use Slack that way, I do miss stuff in noisy channels, but I’ve learned to live with it (so have people I work with).
Heck, I even had a personal policy of never scheduling regular meetings (they all needed to be “as-needed”).
However, I worked for a Japanese company, so regular meetings were a part of my life; whether or not I liked it.
I prefer “store and forward” communication (email is the classic form). Working for a Japanese company actually helped, there, as it was damn near impossible to have realtime chats with Tokyo.
If I use Slack that way, I do miss stuff in noisy channels, but I’ve learned to live with it (so have people I work with).
How does this differ from spoken conversation?
There is never any expectation that spoken conversation might be archived/searchable/linkable-to-others.
Additionally in many locations (California), if that conversation is plausibly private (in person, in a hallway that isn't super busy or not in a cafe), it's illegal (albeit not perfectly) for it to be anything but ephemeral.
People can of course reproduce what they think you said in another form, but that is always open for debate and challengeable. For better or worse.
People can of course reproduce what they think you said in another form, but that is always open for debate and challengeable. For better or worse.
Not really related to the article but at my work they are testing deployment of 3 different systems. They were deployed at different times so X was first then followed by Y about 1 year later, then finally Z ~6 months after deployment of Y. Z is expected to be fully adopted and Y and X will be phased out, eventually.
Depending on when the person joined they tend to have a proclivity towards a specific chat application. The oldest person on the group used X almost exclusively. The newer group members tended to use Y and Z apps.
So you would get pings from all of these apps and the points describes in the article are amplified times three.
In order to reclaim some sort of sanity, I decided to just log off from X and Y chat platforms and only use Z. I figured if that person really wanted to get ahold of me then they would figure it out themselves that I only use Z. Also I did send out e-mails and set statuses on X and Y indicating my preference for Z.
I would say thus far it is a success. Haven’t had any complaints for the past 6 months :)
Depending on when the person joined they tend to have a proclivity towards a specific chat application. The oldest person on the group used X almost exclusively. The newer group members tended to use Y and Z apps.
So you would get pings from all of these apps and the points describes in the article are amplified times three.
In order to reclaim some sort of sanity, I decided to just log off from X and Y chat platforms and only use Z. I figured if that person really wanted to get ahold of me then they would figure it out themselves that I only use Z. Also I did send out e-mails and set statuses on X and Y indicating my preference for Z.
I would say thus far it is a success. Haven’t had any complaints for the past 6 months :)
I feel like most of these arguments can be made about in person meetings, too. Decision making needs to be documented somewhere regardless of the medium the conversation took place in.
Live chat could maybe be a good place for that to happen but then someone needs to transfer that information into a tool designed for it. Just like you would if you had a meeting in a physical office.
Now if the argument you want to make is that live chat is a bad place for those discussions to be had then that is different. Having worked at multiple fully-remote orgs with team members across many timezones and working different schedules I can agree live chat is not a great place for decision making to happen either.
We use RFCs for async decision making when live chat, zooms, or in-person meetings aren't possible. It is slower since you are often waiting for a response until the next day, but I also find that the waiting time can be quite productive for other tasks and gives everyone more time to think about an issue.
Live chat could maybe be a good place for that to happen but then someone needs to transfer that information into a tool designed for it. Just like you would if you had a meeting in a physical office.
Now if the argument you want to make is that live chat is a bad place for those discussions to be had then that is different. Having worked at multiple fully-remote orgs with team members across many timezones and working different schedules I can agree live chat is not a great place for decision making to happen either.
We use RFCs for async decision making when live chat, zooms, or in-person meetings aren't possible. It is slower since you are often waiting for a response until the next day, but I also find that the waiting time can be quite productive for other tasks and gives everyone more time to think about an issue.
To me or seems that the author is more frustrated with how his team communicates during a sprint than the tool being used.
If you need to discuss something in thorough detail in a sprint, which is on the sprint backlog, it is done during refinement.
If a discussion is about a work item/pbi/user story it is discussed not in Slack or Teams, but under the item's discussion board. Jira, base amp and azure DevOps all support this.
The symptoms of poor communication or following a proces cannot be deslt with be changing from Slack to email.
People needs to be educated it seems as where communication must go.
Emails are not for work items under a sprint. Imo. Neither is Slack. You don't discuss wotk items in a chat, you do that in it's appropiate platform where the item livets.
Slack is not email. Should not be used as such. Slack is for "hey, where is that vacation spreadsheet" and not "should this feature be with bootstrap or vanilla HTML?"
The latter is work. It is discussed where work lives. Work does not live in Slack.
Good luck
If you need to discuss something in thorough detail in a sprint, which is on the sprint backlog, it is done during refinement.
If a discussion is about a work item/pbi/user story it is discussed not in Slack or Teams, but under the item's discussion board. Jira, base amp and azure DevOps all support this.
The symptoms of poor communication or following a proces cannot be deslt with be changing from Slack to email.
People needs to be educated it seems as where communication must go.
Emails are not for work items under a sprint. Imo. Neither is Slack. You don't discuss wotk items in a chat, you do that in it's appropiate platform where the item livets.
Slack is not email. Should not be used as such. Slack is for "hey, where is that vacation spreadsheet" and not "should this feature be with bootstrap or vanilla HTML?"
The latter is work. It is discussed where work lives. Work does not live in Slack.
Good luck
If you're into Cal Newport, he's got a new book coming out that seems related:
https://bookshop.org/books/a-world-without-email-reimagining...
https://bookshop.org/books/a-world-without-email-reimagining...
Cal Newport has a new book coming out every few weeks. Usually its 90% of the last one with a different target audience. :)
Alternatively, in a tool that allows multiple channels, create a channel for the specific issue and invite the relevant people into it.
The problem in the essay isn't chat rooms, it's having ONE chat room for all discussions. Branch off into another chat/channel and title that channel for the specific issue being discussed.
The problem in the essay isn't chat rooms, it's having ONE chat room for all discussions. Branch off into another chat/channel and title that channel for the specific issue being discussed.
Okay, but what about real time search history? That’s not mentioned as a key. feature in the article.
That’s the whole point of not worrying about these lines without sufficient thought.
Being able to query the past instanteously via live chats is vital.
I see live transcripts via iMessage and live chats as a huge benefit — your thoughts in real time, basically, shared externally without energy wasted verbally.
One of my biggest regrets is not pro-actively hitting aim support right before mass account deletion post mortem acquisition by Verizon.
Imagine scrolling back in time to your high school chats— one can easily use that context to go back in time like Mac OS time machine.
Put all of those time stamps in whatever format (t, chat service, message) on a visual calendar and you’ll be able to do much more with your data. Including attachments.
That’s the whole point of not worrying about these lines without sufficient thought.
Being able to query the past instanteously via live chats is vital.
I see live transcripts via iMessage and live chats as a huge benefit — your thoughts in real time, basically, shared externally without energy wasted verbally.
One of my biggest regrets is not pro-actively hitting aim support right before mass account deletion post mortem acquisition by Verizon.
Imagine scrolling back in time to your high school chats— one can easily use that context to go back in time like Mac OS time machine.
Put all of those time stamps in whatever format (t, chat service, message) on a visual calendar and you’ll be able to do much more with your data. Including attachments.
My hope is most of my youthful chats have been forever destroyed. It's not a season I'd like to revisit.
hitting aim support for what? afaik they weren’t holding onto aim chats. tho my memory is fuzzy here
There's a great rule of thumb for workplace communication mediums I saw long ago. It was something like this:
- Email: Not urgent. Expected response: ~1 day. - Chat: Somewhat urgent. Expected response: < 1 hour. - Text: Shit is on fire. Expected response: Immediate.
Building on the points OP makes re the problems thinking one line at a time in chat, in this little mental model there's a whole lot of daylight between email and chat. And there's lots of problems with email that make it not a great communication medium for semi-urgent things.
My sense is that we need a better primitive inside chat platforms to differentiate between "this is important and we need to have this discussion now" and something closer to email-ish pace.
- Email: Not urgent. Expected response: ~1 day. - Chat: Somewhat urgent. Expected response: < 1 hour. - Text: Shit is on fire. Expected response: Immediate.
Building on the points OP makes re the problems thinking one line at a time in chat, in this little mental model there's a whole lot of daylight between email and chat. And there's lots of problems with email that make it not a great communication medium for semi-urgent things.
My sense is that we need a better primitive inside chat platforms to differentiate between "this is important and we need to have this discussion now" and something closer to email-ish pace.
That's an interesting perspective. To me, if it's urgent, better be a phone call. I definitely don't see a text as urgent.
In my previous job I battled this a lot. While I really like slack in general, no one likes it when things fall through the cracks or important people miss out.
It actually bothered me enough that I quit my job and made Kitemaker (YC W21) which automatically watches slack conversations for mentions of work items and links them together. This linkage lets people working on something that there are discussions going on about it in Slack. You have your persistent place for writing things down (in Kitemaker) and can still use Slack. We have lots of plans for making it even more frictionless. Also works with Discord.
https://kitemaker.co
It actually bothered me enough that I quit my job and made Kitemaker (YC W21) which automatically watches slack conversations for mentions of work items and links them together. This linkage lets people working on something that there are discussions going on about it in Slack. You have your persistent place for writing things down (in Kitemaker) and can still use Slack. We have lots of plans for making it even more frictionless. Also works with Discord.
https://kitemaker.co
This article describes the problem with "hot" channels, like Slack or Zoom. Their information throughout is so high that it's hard to hold onto anything. That high throughout also makes them valuable for quick syncs and personal conversation. We run into trouble when we try to make it do more than it was built for.
"Cold" channels (e.g. documents, tickets) are where important information should go. A single piece of information can be developed and solidified over time. Cold channels are easier to search, easier to catch up on, and easier to onboard.
The problem is not with any one channel, but that we expect one channel to handle all types of information.
"Cold" channels (e.g. documents, tickets) are where important information should go. A single piece of information can be developed and solidified over time. Cold channels are easier to search, easier to catch up on, and easier to onboard.
The problem is not with any one channel, but that we expect one channel to handle all types of information.
There really needs to be some sort of mix between chat and a collaborative note-taking app.
How can we transform chats into a reasonable, permanent reference materials?
Maybe it would be possible to build a slack-bot that could identify which part of these threads are the most important, and even move them to a more permanent storage.
Or, slack channels could add functionality to allow users to vote for which messages are most pertinent, or should be moved to longer-term storage or a featured position for everyone.
I think there is probably value in these rapid fire IM's, but I feel the Mike's (the author's) pain. I skip over threads everyday because reading them never feels worth it.
How can we transform chats into a reasonable, permanent reference materials?
Maybe it would be possible to build a slack-bot that could identify which part of these threads are the most important, and even move them to a more permanent storage.
Or, slack channels could add functionality to allow users to vote for which messages are most pertinent, or should be moved to longer-term storage or a featured position for everyone.
I think there is probably value in these rapid fire IM's, but I feel the Mike's (the author's) pain. I skip over threads everyday because reading them never feels worth it.
Can a chat platform be built on SMTP, and what would be the implications of that? Has that been done? I think email has so many things going for it, and I wonder to what extent it has been rejected as a platform because it is too open.
Delta Chat
https://delta.chat
https://delta.chat
I think an interesting difference between chat clients like Slack and email is this.
With email every user must organize a single firehose of an inbox. Chat channels area already a default compartmentalization but beyond that, chat services default to shared organizational structures like channels and threads.
In email each user must manage the conversations themselves through labels or what have you. In successful chat systems, you can passively benefit from the organization of others. Mailing lists help but aren't enough in their current, aging incarnation.
It might be possible to disrupt the email space by recognizing and adopting these UX differences.
With email every user must organize a single firehose of an inbox. Chat channels area already a default compartmentalization but beyond that, chat services default to shared organizational structures like channels and threads.
In email each user must manage the conversations themselves through labels or what have you. In successful chat systems, you can passively benefit from the organization of others. Mailing lists help but aren't enough in their current, aging incarnation.
It might be possible to disrupt the email space by recognizing and adopting these UX differences.
I have noticed a similiar issue when I was searching for technical support with some applications, and eventually I had to make a Discord account, join a given server on it, and then search its backlog to find my answer.
The server was 'public' in that anyone could join it, but it will not be indexed by search engines, so I can't imagine how many other people were unable to find the solutions to their problems because they were spoken in a chat room and never posted on the 'public' Internet. Given the scale at which services like this operate (soon to be billions of users), this is a pretty big problem.
The server was 'public' in that anyone could join it, but it will not be indexed by search engines, so I can't imagine how many other people were unable to find the solutions to their problems because they were spoken in a chat room and never posted on the 'public' Internet. Given the scale at which services like this operate (soon to be billions of users), this is a pretty big problem.
I tried to follow the course using the backcountry map, but due to some Slack in the GPS, I ended up Discoursed. I fell, badly twisting my ankle, and was not able to Github and walk. Thus stranded in the middle of nowhere, I peered into my backpack. I only one Carrot left to eat, and to my utter dismay, I had left the Flarum gun at the Basecamp. Luckily, my cellphone's data connection somehow worked well enough that my E-mail client was able to clear the SOS message of the outbox after some 23 retries.
This sounds like it may be a people problem rather than a technology problem. If a problem is moving on without him on a messaging platform I don't know why his teammates wouldn't do the same on an email thread or a github issue. One-liners also don't have to be the norm and I myself have gotten plenty of page long responses when warranted. Channels and threads also work for me when it comes to skimming, and Slack has a solid search feature which manages to make locating things super easy
Opinionated article that doesn't land in my experience.
Slack search is awesome, allows links with previews, reminders, easy channel creations, bookmarking, threading to allow sub topics...
Better than email for the quick back and forth, better than voice that is harder to schedule and synchronic and doesn't keep records.
If it's really important, you should have a way to keep track besides the "quick communication" but that doesn't mean slack isn't a great tool by default. Just keep an eye on the data deletion policies.
Slack search is awesome, allows links with previews, reminders, easy channel creations, bookmarking, threading to allow sub topics...
Better than email for the quick back and forth, better than voice that is harder to schedule and synchronic and doesn't keep records.
If it's really important, you should have a way to keep track besides the "quick communication" but that doesn't mean slack isn't a great tool by default. Just keep an eye on the data deletion policies.
At Automattic we have not been using email for the past dozen years for internal communications. We replace email with WordPress.com/P2 plus IRC (moved on to Slack).
In our internal P2s we count 1 million posts (that might have been emails), 2.6 million comments (that might have been email replies) across 1,100 P2s (that might have been email silos).
We are active on Slack, but decisions are made on asynch P2s which are the source of truth.
In our internal P2s we count 1 million posts (that might have been emails), 2.6 million comments (that might have been email replies) across 1,100 P2s (that might have been email silos).
We are active on Slack, but decisions are made on asynch P2s which are the source of truth.
"Despite the “asychronous” claim, you have to keep a steady eye on it and reply in realtime or the conversation will move on without you."
For me, sync and async communication is a spectrum and chat (as it is used in the majority of companies) is more on the sync half of it.
I'm currently thinking about building a microblogging alternative to Slack, that will be more on the async side, not as much as email though.
For me, sync and async communication is a spectrum and chat (as it is used in the majority of companies) is more on the sync half of it.
I'm currently thinking about building a microblogging alternative to Slack, that will be more on the async side, not as much as email though.
This is one reason I built https://kontxt.io for enterprise. It instantly connects people to specific page-parts to have localized conversations directly on the source of internal and external websites and digital documents, so everything is where you need it, when you need it, and anyone that joins later has full context.
I definitely agree with this. The one thing that I hoped would prove useful from these programs vs IRC was the idea of a persistent, searchable, history. However my experience has been not great. Searching history often just brings up unrelated snippets of conversations I didn't have any interst in, in channels I never chatted in. It's just more clutter.
This argument has been going on for decades. Chat vs. threaded discussion vs. email. The best one for me is where the people I need to communicate are listening. The hard part is getting everyone to listen in the same place. It doesn't matter how good the UX is, if you need the CEO in the chat and she only does email, then email it is.
> Thinking one line at a time lowers the quality of the discussion. Knee jerk rapid fire responses become the norm.
I mean, this is also how talking in real life work. Chat is supposed to be the closest written replication of a verbal conversation. Rapid fire back and forth is how many discussions are supposed to happen.
I mean, this is also how talking in real life work. Chat is supposed to be the closest written replication of a verbal conversation. Rapid fire back and forth is how many discussions are supposed to happen.
[deleted]
This is actually about half of the business plan for companies like Slack. They want you to start using it on the basis it is ephemeral and then end up forced into paying for it because its just impossible for people to self-enforce that behaviour and not put information in there that needs to be retained.
I agree with the concern author is expressing. Usually, we do not start conversations leading to a decision/important, but it evolves into useful discussion. Onus is on us to move that convo/thread to GitHub issue & socialize it there. May be that is what author is hinting.
[deleted]
And if it matters after today, don't send it as an SMS, don't send it as an e-mail, don't talk about it over the phone, and if it matters that someone knows you went out to meet this or that person, don't bring your phone with you.
> I’m not saying live chat is useless. It’s great at some things:
> - Quick answers to quick questions
> - Low-stakes status updates
> - Swarming around red alerts or outages
Well OK, but the problem is that sometimes those things also matter after today. So in practice, it often does end up being better to just save everything in an indexable form, because you can't realistically decide in advance to every conversation whether or not it's going to be important. You can pretend to, you can put every conversation you're going to have in one of those bins -- but you'll just be pretending, you're not going to get the prediction right every time.
The second problem is that sometimes conversations fluctuate and change form, and it is not uncommon to have a good long-form conversation that needs to occasionally dip into quick questions and status updates. When the boundaries between your chat environments are too rigid, you can have the same productivity losses because people delay having important conversations or just avoid them entirely. This kind of categorization of communication often ignores that communication is extremely fluid. You can change between longform training and technical discussion, quick status updates and questions, and even affirmation multiple times during the same conversation.
Most people on HN already understand how much harm context switching and interruptions can be for productivity in programming. But the same can also be true in communication. If you're in the middle of a chat and there's a clear opportunity in-line with what you're already talking about to explain something or reach a decision, you are basically imposing a giant context switch if you say, "well, no, don't talk about it. Let's all schedule a meeting." Or even if you just say, "keep it in your head until you get back to your desk and then email me."
Sometimes that interruption is warranted, and sometimes it costs a lot of focus/productivity for very little gain. It's situational.
I'm not sure it's wise to have binary rules about how and where people on your team should communicate. A lot of the advice I see around team organization and management ends up being generally good advice but taken to the extreme, where it wraps back around to being a barrier to actually getting stuff done. Encouraging people to use email for longform technical discussion is a good idea, but I suspect that trying to make some kind of policy about may be a bad idea for most orgs.
> - Quick answers to quick questions
> - Low-stakes status updates
> - Swarming around red alerts or outages
Well OK, but the problem is that sometimes those things also matter after today. So in practice, it often does end up being better to just save everything in an indexable form, because you can't realistically decide in advance to every conversation whether or not it's going to be important. You can pretend to, you can put every conversation you're going to have in one of those bins -- but you'll just be pretending, you're not going to get the prediction right every time.
The second problem is that sometimes conversations fluctuate and change form, and it is not uncommon to have a good long-form conversation that needs to occasionally dip into quick questions and status updates. When the boundaries between your chat environments are too rigid, you can have the same productivity losses because people delay having important conversations or just avoid them entirely. This kind of categorization of communication often ignores that communication is extremely fluid. You can change between longform training and technical discussion, quick status updates and questions, and even affirmation multiple times during the same conversation.
Most people on HN already understand how much harm context switching and interruptions can be for productivity in programming. But the same can also be true in communication. If you're in the middle of a chat and there's a clear opportunity in-line with what you're already talking about to explain something or reach a decision, you are basically imposing a giant context switch if you say, "well, no, don't talk about it. Let's all schedule a meeting." Or even if you just say, "keep it in your head until you get back to your desk and then email me."
Sometimes that interruption is warranted, and sometimes it costs a lot of focus/productivity for very little gain. It's situational.
I'm not sure it's wise to have binary rules about how and where people on your team should communicate. A lot of the advice I see around team organization and management ends up being generally good advice but taken to the extreme, where it wraps back around to being a barrier to actually getting stuff done. Encouraging people to use email for longform technical discussion is a good idea, but I suspect that trying to make some kind of policy about may be a bad idea for most orgs.
The rule should be the same as meetings, which is that if something important is decided, some document or wiki page should get updated.
It's never the case that everyone who might need to know is in a meeting. You might hire someone next week.
It's never the case that everyone who might need to know is in a meeting. You might hire someone next week.
> Rule of thumb: If a discussion will matter after today, don’t have it in a chat room. Check out Discourse, Twist, Carrot, Threads, Basecamp, Flarum, or heck even GitHub issues.
I see; anything but e-mail! Gotcha.
I see; anything but e-mail! Gotcha.
Didn't notice the article author encourages people to e-mail him, right from the blog page. :)
> Anyone who takes the time to ponder and respond thoughtfully with context and explanation will find that they’re too late.
I think this is a reasonable point, however, is this really a problem with the medium itself?
I think this is a reasonable point, however, is this really a problem with the medium itself?
Slack is for low effort stuff, while e-mail is for never-ending barrage of status updates and notifications from all the systems you use.
...what is for important stuff then
...what is for important stuff then
Biggest use case for using chat rooms for technical discussions: I can search through archives a year later and find valuable nuggets of information.
Slack has a search function that works pretty darn well. Conversations or context never get really lost. I wish we used it more.
I like the concept of declaring bankruptcy on chats. I've done this on email more times than I'd like to admit.
I dislike the concept; take Anki the spaced repetition learning system as an example for comparison: you add in some flashcards around a topic you want to learn and remember, and it prompts you to work through the cards you are most likely to forget. One failure mode is that you don't bother checking it for a few days, and suddenly there's a ton of cards to work through and it's overwhelming and you don't want to or can't spare the time, the next day there's even more they pile up until you "declare bankruptcy" on them.
But your memory doesn't magically work better after declaring bankruptcy, if you imagine Anki is approximately correct about when you'll forget things then /not/ going through those cards means forgetting things you said you wanted to remember. That's a fundamental problem that should be addressed - you desire to remember more things than you have space in your life to sustainably commit to. Reset and restart is one way forward, but it's not a way out; presumably some of the things you wanted to remember are more important than others, and you're leaving it completely to chance which survive the reset and restart. If none are important then don't restart. If it's only for fun and that's not fun, it's not working well.
To bring it back to email, the idea is "if I declare bankruptcy, the important things will come back again eventually". Things other people think are important will come back - using other people's brains to track the tasks which aren't good at that and are busy with other things - while throwing out the computer which is extremely good at record keeping - so good it's showing you the overwhelming amount of information you /actually have/ personally requested, or organisationally been subscribed to. If it's too much for one brain then it's too much. If it's too much irrelevant or redundant, then the organisation systems or tools are broken.
If the response to that is to throw it all out and reset then it stays being too much, too irrelevent, too broken, indefinitely, for everyone. It's covering over the symptoms to avoid addressing the sickness. It's a trip to the ER to have your stomach pumped so you can go back to binge drinking from the firehose instead of going to rehab and making difficult changes, it's a part of our hoarding culture that's so widely supported in this thread, a part of the obesity crisis, information addiction, and panic in the face of mortality, and all those unrelated (but related really) things.
"If I just do everything, know everything, have everything, eat everything, keep records of everything, I'll maximise my life experiences and save myself from {unspecified future horror {eventually death}}".
There's an amount of work an employee can reasonably, practically, pragmatically do, and computer systems we have developed which are /completely incapable/ of helping us track and prioritise that, but /absolutely fantastic/ and overwhelming us with nonsense trivia and redundant messaging noise and tasks nobody is going to do that are socially unable to be dropped but are actually going to be kicked down the road until they don't matter. It's an awful system we've built where "declaring bankruptcy" on the messages we (individually or collectively) have to be involved in is a consideration at all. But if that is the way forward, it shouldn't be a guilty pleasure that you don't want to admit; evolution has an aggressive reaper function to cull all but the most fit, if we're going to adopt that, we should wholeheartedly do it openly and enthusiastically - any job which isn't worth remembering by brain can be wiped off the system after X days, no harm no foul. The combination of "too much" and "archived forever" is killer in the bad way.
(How many people have left their jobs just to trigger this reaper function? If it was overwhelming the employee, the next employee won't have to deal with it, fresh start for both leaver and position).
But your memory doesn't magically work better after declaring bankruptcy, if you imagine Anki is approximately correct about when you'll forget things then /not/ going through those cards means forgetting things you said you wanted to remember. That's a fundamental problem that should be addressed - you desire to remember more things than you have space in your life to sustainably commit to. Reset and restart is one way forward, but it's not a way out; presumably some of the things you wanted to remember are more important than others, and you're leaving it completely to chance which survive the reset and restart. If none are important then don't restart. If it's only for fun and that's not fun, it's not working well.
To bring it back to email, the idea is "if I declare bankruptcy, the important things will come back again eventually". Things other people think are important will come back - using other people's brains to track the tasks which aren't good at that and are busy with other things - while throwing out the computer which is extremely good at record keeping - so good it's showing you the overwhelming amount of information you /actually have/ personally requested, or organisationally been subscribed to. If it's too much for one brain then it's too much. If it's too much irrelevant or redundant, then the organisation systems or tools are broken.
If the response to that is to throw it all out and reset then it stays being too much, too irrelevent, too broken, indefinitely, for everyone. It's covering over the symptoms to avoid addressing the sickness. It's a trip to the ER to have your stomach pumped so you can go back to binge drinking from the firehose instead of going to rehab and making difficult changes, it's a part of our hoarding culture that's so widely supported in this thread, a part of the obesity crisis, information addiction, and panic in the face of mortality, and all those unrelated (but related really) things.
"If I just do everything, know everything, have everything, eat everything, keep records of everything, I'll maximise my life experiences and save myself from {unspecified future horror {eventually death}}".
There's an amount of work an employee can reasonably, practically, pragmatically do, and computer systems we have developed which are /completely incapable/ of helping us track and prioritise that, but /absolutely fantastic/ and overwhelming us with nonsense trivia and redundant messaging noise and tasks nobody is going to do that are socially unable to be dropped but are actually going to be kicked down the road until they don't matter. It's an awful system we've built where "declaring bankruptcy" on the messages we (individually or collectively) have to be involved in is a consideration at all. But if that is the way forward, it shouldn't be a guilty pleasure that you don't want to admit; evolution has an aggressive reaper function to cull all but the most fit, if we're going to adopt that, we should wholeheartedly do it openly and enthusiastically - any job which isn't worth remembering by brain can be wiped off the system after X days, no harm no foul. The combination of "too much" and "archived forever" is killer in the bad way.
(How many people have left their jobs just to trigger this reaper function? If it was overwhelming the employee, the next employee won't have to deal with it, fresh start for both leaver and position).
Conveniently Teams has both chat and threads.
The funny thing is - it's easier to search and look at context in discord than in outlook or on wiki.
You can create a specific room for a scoped discourse or dialectic.
I thought this was going to be about personal InfoSec ala Parler.
So there is no knowledge hub inside these companies or what ?
[deleted]
Why today?
use JIRA as an internal stackoverflow :D
In fact Atlassian have a module for this that plugs into Confluence which looks and feels a lot like SO. Trying to find the module name. It might just be called "Questions". I think this is the one we use [1]
[1] - https://marketplace.atlassian.com/apps/1217080/questions-ans...
[1] - https://marketplace.atlassian.com/apps/1217080/questions-ans...
that'll only work if the module name also makes confluence search usable
Yes, their search leaves a lot of room for improvement. I am only suggesting it for the folks that are already using it.
[deleted]
[deleted]
Chat will become the primary method of communication and will be where most work gets done. Other systems will exist sure eventually hackers will build tools for them to be interfaced with via chat clients. This has been happening for many years. Old people need to get over it and stop writing blog posts that basically sound like anti-email rants from 1998.
Maybe I am one of those "old people" but I don't understand how discord is better than more traditional forums or mailing lists for technical discussions. With a mailing list, forum thread, or GitHub issue, I can search and find something relevant to me from years ago. By contrast, discord seems so ephemeral: I have to hope I can be in the same place at the same time as the person who has the information I need. And it's a closed platform, so it's not searchable or indexable the same way as content on the open web. And if discord closes their doors, or changes their TOS in the wrong direction some day it might all just be gone from one day to another. I would be happy to understand why you think chat is a better tool for the job.
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.