There's other benefits like cross linking with #123 format, @mentions, labels, thread state (open/closed/locked), diff view for pull requests, etc, etc, things that email doesn't have. :)
Mail has all of these, except labels and thread state, and I think that's desirable. Keeping an issue tracker up to date is time consuming and ultimately impossible to get right. Case in point: Nixpkgs' issue tracker. As for your other points: - You can include URLs to mailing list archives, or even just message IDs, which you can look up in public-inbox[1]. - Mentions are called Cc in email. - Diffs are how changes are generally communicated over email[2]. [1]: https://spectrum-os.org/lists/archives/ [2]: e.g. https://spectrum-os.org/lists/archives/spectrum-devel/87eewn9g8q.fsf@alyssa.... Meanwhile, there are lots of advantages to email. Here are some (but not all) of them: - There are lots of different email clients available, so people can use whichever one meets their needs. GitHub has to cater for the novice and advanced users all at once, whereas with email these use cases can be handled by different clients well suited to their specific tasks. For example, I'm writing this email from Emacs, which is a much more pleasant composition interface than a text field in a web browser, and this makes a big difference when you deal with a lot of different threads. And if you prefer writing in a text area in a web browser, you can do that too. - Email has proper threading, not flat conversations like GitHub has. Ever tried to follow a NixOS RFC, or even worse, a Rust one? Because of its support for proper arbitrary-depth threading, long, detailed conversations are much easier to follow over email. - I don't need to supply Git hosting to every potential contributor, and nor do they have to find their own, because no hosting is required so send a patch over email. It's also a much easier flow to teach somebody who's new to Git. You don't need to know what a branch is, what a fork is, or to sign up for an account anywhere.
The attached screenshot shows how email makes things more difficult. It's would be PITA to configure all my devices for this list.
Ah, yes, this is unfortunate. Thank you for raising it. Rejecting HTML mail was a decision I made for a few reasons: - public-inbox doesn't support it. - Patches would be mangled if pasted into an HTML-generating composer. - It's been the source of several major security bugs in mail clients, because it's such a complex format. Now, given it would be good for Spectrum if people who did not know or care about the difference between HTML and plain text mail were able to ask questions and get support, I do think that probably I should relax this for the discuss@ list (but not devel@, where not mangling patches is important, and people can be expected to be a bit more technical). discuss@ could just discard HTML parts, and that would still prevent exposing other people to HTML mail, without forcing people to manually disable it in their clients. But, despite all of its many advantages, I know there are people who for whatever reason don't want to use email, and that's why we have a Hyperkitty. If you prefer reading and writing messages in a web browser, that's what Hyperkitty is there for. You don't have to use a mail client if you don't want to. Unlike, with GitHub/GitLab, nobody is forced to use any particular way of interacting with the discussions. That's one of the best things about mailing lists. ;)
Let me try hyperkitty; it may be the only way for me to use the list.
I hope it works well for you. If there's anything I have configured poorly about it, please let me know and I'll try to make it better if I can.