As part of my work on Tenacity, I manage the sourcehut operations for the project. This includes the repository, the builds, the webhooks, and the mailing lists.

Sadly, the mailing lists don’t see very much use, and instead almost everything is discussed on GitHub or IRC. I’ve encouraged a lot of people to use them, particularly those who (for some reason) reach out to us via GitHub Discussions, but I never manage to convince them.

Now, I get it. Email is an old protocol, and most people don’t have the best experience with using it. I understand why you’d be intimidated by the idea of a mailing list at first — but that doesn’t mean it’s complicated. Email is the simplest form of communication, and anyone who actually tried using a mailing list would understand that immediately.

This post serves as a list of reasons to use email for public communication — feel free to redirect people to this page if they’re saying things similar to the ones I’ll go over. On the other hand, if you’ve been redirected here, someone probably wants you to use mailing lists.

With that out of the way, here are some arguments against mailing lists and git via email, and my counter-arguments.

The mailing list demands I use plain text email!

Yes, this is by design. HTML emails are objectively worse than plain text ones; they’re less secure, less accessible and not nearly as universal. By asking the software to “deal with it” and strip the HTML out of your email, you help normalize the use of terrible HTML emails. Here’s how to configure your client to use plain text email. If your client can’t do that, it’s bad. That’s not the list’s problem.

But my formatting! How will I express emotion?

Just because the email is plain text doesn’t mean the client can’t format it however it wants. Mozilla Thunderbird renders *bold* and /italic/ text, as well as _underlined_ (which I can’t demonstrate).

Even if not all clients format text, the meaning of *asterisks* is not lost on the reader. I, personally, frequently use special characters to emphasize parts of my email.

Can’t you just use a forum?

For all intents and purposes, a discussion mailing list is a forum. That being said, it has a major advantage over the traditional forum setup: You don’t need to create an account to participate in discussion. No one wants to create a random account for some forum just to ask one question. Many people have their gripes with GitHub and refuse to have an account there. All these people should not be ignored.

The git via email workflow is complicated!

Let’s say I want to update the on a project that isn’t mine. That’s a pretty simple task. Here’s how I would do it on GitHub:

  1. Press the ‘fork’ button, creating a new personal branch on my account
  2. Open my terminal, navigate to the repository, and update the remote to my new ‘fork’ on GitHub
  3. Make and commit my changes
  4. Push those changes to my newly-changed remote
  5. Go back onto GitHub, navigate to my repo, and press the Pull Request button
  6. Fill in the pull request, and send it off for review

In these six steps, we had to context-switch twice: GitHub to the terminal and back to GitHub. We’re also left with a remote that will be left unused, unless we plan to make more contributions.

Compare that to email:

  1. Make and commit my changes
  2. Find who to email, usually specified in the README of the project
  3. Configure git to send patches via email
  4. git send-email --to="<email>" HEAD^

Not only is it 2 steps shorter1, it requires zero context switching, and you’re not left with any branches or remotes you don’t need.

Git via email is measurably simpler, faster, and more convenient than the Pull Request workflow that seems to plague every software forge.

But I’m used to the PR workflow!

You must remember that there was a time before you got accustomed to Pull Requests. Try to recall your first contribution; you didn’t really know git all that well, you probably made a lot of mistakes, and you might’ve clicked a button you shouldn’t have. Regardless, you learned how to use git and the tools you were handed, making mistakes along the way, until you eventually became competent.

I’m not going to argue about which method is easier to learn first2, but refusing to learn and try out a different workflow because the current one “works for you” is willful ignorance.

If you have any arguments I haven’t gone over in this post, please let me know — either on my public mailing list or in private. I’d love to hear your opinion.

  1. Both of the methods assume that this is your first contribution to a repository. If it’s not, GitHub gets shortened down to 4 steps, while git send-email only has two. It couldn’t get much simpler than that. ↩︎

  2. Though you can probably guess my opinion on that matter ;) ↩︎

Permanent link to this article:

Start a discussion about this post by sending an email to my public mailing list! [archives]