Hacker News Reader

Comment by mumblemumble | Hacker News Reader

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.

View on HN

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.

Now I'm sad.

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.

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)

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.

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.

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.

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

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

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

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.

Most things I've seen require/enforce S/MIME.

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.

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.

Reply on news.ycombinator.com