Unfortunately, Chris describes exactly what I’ve used to do also, namely be subscribed to a firehose of technical mailing lists, at it’s peak up to ~350 mailing lists at once; now I’m down to about a handful, especially for niche projects. These days I’ve switched to following Lobsters links and directly following various authors blogs RSS.
However, I still think that email is (technically) superior to “forums” (which these days means Discourse), because anyone is free to choose his user-agent and implement whatever filtering or archival workflow one wants. With Discourse you can’t… (Although it has support for emails, that is broken, or at least was broken a few years ago.)
Also forums, at least for me, didn’t solve the high-volume issue, as for example I’ve tried following the Rust users Discourse forum, and it was as “bad” (in terms of follow-ability) just like other users mailing list. Both had high-volume (sometimes low-quality) traffic.
Perhaps what we are missing are low-volume and/or high-quality mailing lists focused on particular topics.
The flip side of being able to choose your own client is that other people can too. The FreeBSD lists are increasingly difficult to follow because people read them on the web and reply with things that then don’t have the thread ID metadata, so it’s impossible to see where their reply fits in a long thread and the threads end up being displayed as a set of disjoint threads. In contrast, LLVM’s Discourse doesn’t have this problem and also doesn’t have the problem that someone replying to a five-year-idle thread (e.g. a new person asked a question, it was answered, and the answer is now wrong after API changes and the next person wants help) is referencing context that a load of subscribers don’t have.
The biggest win for LLVM was that the project had a large set of lists with overlapping audiences. C++ things might need to go to the libc++ and clang lists, but then some people would hit reply all and have their replies bounced from the lists they were not on. It’s much easier to follow a set of tags and have threads gain tags once people realise a particular audience would care about something.
Indeed, a “forum software” (mainly Discourse) might be much better equipped to handle long-form threaded communications between multiple people; while also supporting things like proper Markdown and code snippets. However, most of the problems you’ve described stem mostly from not respecting best practices (use proper quoting, use proper email clients, etc.), which forums seem to properly enforce.
In fact, I agree that perhaps emails aren’t the best solution as “forums”, however they have something that no forum software has: flexibility.
Picking on Discourse (because it’s the dominant software in this area):
can I have one account and use that for all my communities? (not with Discourse, but yes with emails;)
can I have the same settings (user preferences) applied to all my Discourse accounts? no; I have to manually tweak each user-preference (time-zone, notifications, theme, etc.) across all my communities;
can I have an archive of all my interactions in a certain community (or even across all)? no; to my knowledge I can’t easily export all the threads I’ve been involved in a certain community; and even if it would be possible I would have to manually do it;
can I use an alternative user-agent as opposed to the standard one (i.e. the web-based UI)? no; although as said I could use email-based workflow but that was broken, specifically due to the fact that Discourse didn’t actually understand the List-* header purposes;
So, perhaps in terms of direct usability Discourse is a better choice, but it completely fails in other respects.
Perhaps we need an email-like protocol specifically for this purpose? Perhaps the Discourse team could propose one? (Although Discourse is a business, thus it’s perhaps against their incentives to do so…)
can I have one account and use that for all my communities? (not with Discourse, but yes with emails;)
I use the log in with GitHub option, so effectively yes.
can I have the same settings (user preferences) applied to all my Discourse accounts? no; I have to manually tweak each user-preference (time-zone, notifications, theme, etc.) across all my communities;
That’s definitely missing from the web site, though I believe the app does better.
can I have an archive of all my interactions in a certain community (or even across all)? no; to my knowledge I can’t easily export all the threads I’ve been involved in a certain community; and even if it would be possible I would have to manually do it;
It’s possible to export everything from an instance, I don’t know if you can export all of your threads. Sounds like something that would be useful though. Have you tried raising a feature request?
can I use an alternative user-agent as opposed to the standard one (i.e. the web-based UI)? no; although as said I could use email-based workflow but that was broken, specifically due to the fact that Discourse didn’t actually understand the List-* header purposes;
From what I can tell, everything that the Discourse app and web app use is exported over their REST API, so you could in theory. I don’t know if there are other clients that do this. Note that your other requests could also be done by writing some code that calls their API.
Regarding feature requests, since I don’t use Discourse, I don’t think asking for any features would be fair (or helpful for me)…
I did at one time try to convince the developers to properly handle List-* headers and completely failed, thus I gave up… (The issue was, as I remember, that they did add some List-* headers, but also added the To: me@example.com header, which basically broke the mailing lists conventions, and thus labeling efforts.)
Regarding the “app”: is there a “desktop app”? I’m not so much into “mobile”, and anyway I kind of hate that everything nowadays has an “official app”… Is there some choice in “apps”, or is there only a single “blessed one”?
I wonder if it’s the UX of mail clients vs other things that’s a contributor. I can’t think of why this is a problem since mailing lists also have topics within them. Maybe the time is ripe for people to gather and come up with best practices for this type of email use case in this day and age?
The UX of mail clients is definitively a major issue for high-volume mailing lists…
I have extensive “experience” into this with GMail, and if it weren’t for the “mute” option I would have renounced using mailing lists much sooner. Also, sticking with GMail here, creating and maintaining filtering rules is almost a complete madness, so much so that at one point I’ve written my own Racket-based DSL to generate (and import) GMail rules via their XML format. However, besides basic labeling, GMail is useless in this regard, which is the main reason I’ve ditched it a few years ago.
I since use Thunderbird for “normal” emails, but not for mailing lists… Because Thunderbird also seems to be useless in this regard…
I had some success with notmuch, which allows quite advanced labeling workflows, but that seriously lacks a proper UI.
Thus, at the moment I do my mailing list consumption via GMail, and any serious searching via notmuch. But all in all, I would say I’ve completely abandoned mailing lists…
Unfortunately, Chris describes exactly what I’ve used to do also, namely be subscribed to a firehose of technical mailing lists, at it’s peak up to ~350 mailing lists at once; now I’m down to about a handful, especially for niche projects. These days I’ve switched to following Lobsters links and directly following various authors blogs RSS.
However, I still think that email is (technically) superior to “forums” (which these days means Discourse), because anyone is free to choose his user-agent and implement whatever filtering or archival workflow one wants. With Discourse you can’t… (Although it has support for emails, that is broken, or at least was broken a few years ago.)
Also forums, at least for me, didn’t solve the high-volume issue, as for example I’ve tried following the Rust users Discourse forum, and it was as “bad” (in terms of follow-ability) just like other users mailing list. Both had high-volume (sometimes low-quality) traffic.
Perhaps what we are missing are low-volume and/or high-quality mailing lists focused on particular topics.
The flip side of being able to choose your own client is that other people can too. The FreeBSD lists are increasingly difficult to follow because people read them on the web and reply with things that then don’t have the thread ID metadata, so it’s impossible to see where their reply fits in a long thread and the threads end up being displayed as a set of disjoint threads. In contrast, LLVM’s Discourse doesn’t have this problem and also doesn’t have the problem that someone replying to a five-year-idle thread (e.g. a new person asked a question, it was answered, and the answer is now wrong after API changes and the next person wants help) is referencing context that a load of subscribers don’t have.
The biggest win for LLVM was that the project had a large set of lists with overlapping audiences. C++ things might need to go to the libc++ and clang lists, but then some people would hit reply all and have their replies bounced from the lists they were not on. It’s much easier to follow a set of tags and have threads gain tags once people realise a particular audience would care about something.
Indeed, a “forum software” (mainly Discourse) might be much better equipped to handle long-form threaded communications between multiple people; while also supporting things like proper Markdown and code snippets. However, most of the problems you’ve described stem mostly from not respecting best practices (use proper quoting, use proper email clients, etc.), which forums seem to properly enforce.
In fact, I agree that perhaps emails aren’t the best solution as “forums”, however they have something that no forum software has: flexibility.
Picking on Discourse (because it’s the dominant software in this area):
List-*header purposes;So, perhaps in terms of direct usability Discourse is a better choice, but it completely fails in other respects.
Perhaps we need an email-like protocol specifically for this purpose? Perhaps the Discourse team could propose one? (Although Discourse is a business, thus it’s perhaps against their incentives to do so…)
I use the log in with GitHub option, so effectively yes.
That’s definitely missing from the web site, though I believe the app does better.
It’s possible to export everything from an instance, I don’t know if you can export all of your threads. Sounds like something that would be useful though. Have you tried raising a feature request?
From what I can tell, everything that the Discourse app and web app use is exported over their REST API, so you could in theory. I don’t know if there are other clients that do this. Note that your other requests could also be done by writing some code that calls their API.
Regarding feature requests, since I don’t use Discourse, I don’t think asking for any features would be fair (or helpful for me)…
I did at one time try to convince the developers to properly handle
List-*headers and completely failed, thus I gave up… (The issue was, as I remember, that they did add someList-*headers, but also added theTo: me@example.comheader, which basically broke the mailing lists conventions, and thus labeling efforts.)Regarding the “app”: is there a “desktop app”? I’m not so much into “mobile”, and anyway I kind of hate that everything nowadays has an “official app”… Is there some choice in “apps”, or is there only a single “blessed one”?
Regarding the REST API: that’s not a standard.
I only subscribe to one mailing list (TZinfo) and I prefer to catch up on it from time to time using the web archive.
It is a bit weird that mailing lists are declining while outfits like Substack are pushing “newsletters”. I guess it comes down to monetization.
Newsletters are more like blogs with a mailing feature built-in. Mailing lists are more like forums.
I wonder if it’s the UX of mail clients vs other things that’s a contributor. I can’t think of why this is a problem since mailing lists also have topics within them. Maybe the time is ripe for people to gather and come up with best practices for this type of email use case in this day and age?
The UX of mail clients is definitively a major issue for high-volume mailing lists…
I have extensive “experience” into this with GMail, and if it weren’t for the “mute” option I would have renounced using mailing lists much sooner. Also, sticking with GMail here, creating and maintaining filtering rules is almost a complete madness, so much so that at one point I’ve written my own Racket-based DSL to generate (and import) GMail rules via their XML format. However, besides basic labeling, GMail is useless in this regard, which is the main reason I’ve ditched it a few years ago.
I since use Thunderbird for “normal” emails, but not for mailing lists… Because Thunderbird also seems to be useless in this regard…
I had some success with
notmuch, which allows quite advanced labeling workflows, but that seriously lacks a proper UI.Thus, at the moment I do my mailing list consumption via GMail, and any serious searching via
notmuch. But all in all, I would say I’ve completely abandoned mailing lists…