Hacker News Reader

Comment by legerdemain | Hacker News Reader

The problem with "trying it with my team for one sprint" is that 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? Do our current customer contracts contain any clauses that complicate the use of external discussion sites? In the unlikely event that the service offers the option to host it locally -- who is going to deploy it, configure it, set up security and authn/authz around it?

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.

View on HN

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.

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.

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)

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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

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.

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

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.

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.

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

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/#

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.

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.

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.

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.

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?

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

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.

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)

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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)

Not to mention replies listed in threads. You have to move sent messages to the inbox to get this to behave correctly in TB.

Right click -> open message in conversation

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.

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.

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.

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

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.

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.

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.

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

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.

>the chat system actually becomes sort of like a wiki

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?

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

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?

Mozilla or EFF, your choice. :-D

Excellent, $25 sent to EFF!

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.

Have your Slack chats been subpoenaed yet?

If not, you are very lucky that you are being sued by people with incompetent attorneys.

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.

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.

Also depending on industry you may by law need to delete things.

What is CYA in CYA policy?

cover your ass.

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!

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.

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.

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

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.

This gives me an idea. What about setting up an archiving script?

After a archive-worthy discussion in email, you forward the thread to "archivebot@my-company-domain.com". 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 "archivebot@my-company-domain.com". 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"

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

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

Reply on news.ycombinator.com