1. 25
  1.  

  2. 16

    Email is a widely implemented, federated, decentralized protocol. This inherently makes it closer to the internet that I want to be using. It’s worth emphasizing protocol, and not user interface. That means that I don’t need to force other people to interact with it the way I do.

    On top of that, I find that I really dislike dealing with juggling and testing patches through pull requests. The experience just kind of feels clunky. I’d rather just pipe the email to patch(1) from my editor, test things out, comment on it, and if I like it, apply it with git am. But then again, I’ve met very few web UIs that I enjoy using.

    I’ll take pull requests on github – code is code – but if you send me pull requests on github, don’t be surprised if it takes an email or two to for me to remember to review it.

    1. 12

      It’s worth emphasizing protocol, and not user interface.

      I feel this is the kind of mindset that makes all these systems doomed to be relegated to comparatively small corners of the internet, rather than being the mainstream. At the end of that day what people really care about is Getting Stuff Done™ and not some fairly abstract argument about some protocol or the nature of the internet. Regardless of the validity of that argument, actually getting stuff done is just more important.

      There’s loads of comparatively simple improvements that could be made to email (or IRC for that matter) which would vastly improve the UX. A good start might be adding a simple way to do basic typographical formatting which doesn’t bring in all of HTML/CSS, but people be like “nonono, plain text monospaced 78 column wrapped (or 76? 74? 72?) without attachments is the One True Way™ to send emails!” So the UX sucks. And thus few people use it.

      I think this lack of pragmatism and “hacker conservatism” is really unhelpful and ultimately self-defeating. What we really need is a good look at email and the pain points people are running in to, and solve them in a way that makes it all less painful. This might require a compromise or two. This will, of course, never happen. I mean, we still haven’t solved bloody email wrapping problems after 40+ years even though the solution is simple and straightforward.

      1. 4

        But on the other hand ‘just get stuff done!’ leads to all sorts of negative side effects. One ought not just do things — one should do the right things, the right way.

        1. 4

          I think the solution to that is to start building protocols/applications/systems/specifications that do things the right way and allow people to get stuff done. Simply put, if the vast majority of people do things “the wrong way”, then there’s probably something wrong with “the right way” that prevents them from using it.

          Most people just aren’t very idealistic when it comes to these kind of things. I think that’s okay because there’s a lot of things in the world to be idealistic about, and you can’t be about everything.

      2. 3

        On top of that, I find that I really dislike dealing with juggling and testing patches through pull requests.

        I think the article is pretty clear that Github and Github-style pull requests are not the only alternative (and probably not a great choice).

      3. 10

        tl;dr: I personally eagerly await the day I don’t have to think about e-mailing patches.

        1. 5

          Even if you get the manual steps right there’s always the chance that your e-mail will be rejected due to over zealous spam filtering.

          Oh yeah. It’s especially fun when your mail ends up on the mailing list fine, but gets rejected by some important maintainer’s mail server (usually gmail). A few of my freedesktop.org patches were delayed because of this. Thankfully, they migrated to GitLab :)

          1. 4

            HTML email in practice is HTML generated by a visual editor that will take your thoughts and silently mangle them with arbitrarily chosen invisible markup. The more you edit, the worse it gets behind the curtain. The most popular HTML email editors (Outlook!) produce notably shitty HTML full of proprietary markup. HTML email clients (Outlook, Notes, web clients like gmail, etc) are remarkably bad at faithfully rendering standards-compliant HTML. HTML emails are extremely antagonistic to the mailing lists used by OSS projects, that have to inject footers into complex MIME structures, and archive messages on web pages. Reading HTML emails requires you to load images and trackers from someone’s remote server. HTML email is inappropriate to most purposes besides marketing. And in the end, all of it is noise that almost never contributes any meaning to the message. HTML email is a pox. People who aren’t trying to contribute to OSS projects should ALSO disable it in their mail clients.

            I am saying this as web developer who codes dozens of HTML emails sent to millions of addresses every month.

            Yes, let’s talk about lowering barriers to contributing to OSS projects, but this is very much the wrong place to start.

            1. 9

              Reading HTML emails requires you to load images and trackers from someone’s remote server

              You can read HTML email without loading external assets; I think almost all major email clients do so by default?

              HTML email is inappropriate to most purposes besides marketing.

              Adding bold text is appropriate usage, or including a table (more or less impossible without HTML email, unless everyone uses monospaced fonts, which most email clients don’t), or including a <pre> tag (again, need monospace text). These are really normal things people want for good reasons.

              Is a full-blown HTML/CSS renderer a best solution for this? Not really, but it’s the only thing we have at the moment. Perhaps if we all focused on writing a specification and implementations of text/html-lite or text/markdown or something else which solves the problem instead of complaining about “HTML email is never useful” the state of affairs might be better.

              1. 1

                You can read HTML email without loading external assets;

                But can you? Not if the content is in the images.

                I think almost all major email clients do so by default?

                It’s a mixed bag. Most desktop clients default to this. Most mobile clients don’t. Most humans flip the default so they can read what they are sent.

                unless everyone uses monospaced fonts

                Everyone used to when emails were text. :)

                Perhaps if we all focused on writing a specification and implementations of text/html-lite or text/markdown

                I actually think this is an excellent idea.

              2. 3

                Do you think there’s room for formatted text in email in general? There’s no way things are gonna change in the email world, I’m just curious to see other people’s opinions on this.

                1. 4

                  I was careful not to speak in absolutes, and of course, as soon as I submitted my screed here, I had to email someone SPF and DKIM records for their domain and wished for a moment that I had an HTML table to format them reasonably, so they wouldn’t get mangled by the recipient’s client. :)

                  HTML is great for marketing emails, and not just spammy BS, but lots of automated professional communications that are formatted to make it clear what’s most important in the message.

                  In general, email chat between humans is only hurt by HTML. But I’d never say never.