I've mostly stopped reading technical mailing lists(utcc.utoronto.ca)
utcc.utoronto.ca
I've mostly stopped reading technical mailing lists
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/MailingListsNoMoreReading
84 comments
I think this is a great observation. I find it indeed hard to dwell on anything because I'm interested in so many things, and to specialize in one of those enough so you could call it dwelling would be tantamount to giving up on many others, which I'm not prepared to do. I feel between a rock and a hard place in that respect.
"Most people don't dwell anywhere, I suspect."
...And I suspect you're correct. And for reasons the author of the story gives (I've also dropped almost all my mailing lists).
If I consider myself as dwelling anywhere specific then it has to be HN for reasons it's a 'filtered' gateway to just everything that I would find interesting—and my interests are diverse. That HN can effectively filter out what I (and seemingly many others) consider to be internet dross and junk yet still provide enormous diversity makes it a very effective gateway.
...And I suspect you're correct. And for reasons the author of the story gives (I've also dropped almost all my mailing lists).
If I consider myself as dwelling anywhere specific then it has to be HN for reasons it's a 'filtered' gateway to just everything that I would find interesting—and my interests are diverse. That HN can effectively filter out what I (and seemingly many others) consider to be internet dross and junk yet still provide enormous diversity makes it a very effective gateway.
> No-one, not even the smartest human, can dwell in more than a few places at once because to dwell in a place is as much about the people and emergent social structures there as it is about the tech.
John von Neummann was fine 'dwelling' in several dozen places. I get why it's hard to admit that outliers several standard deviations above exist.
John von Neummann was fine 'dwelling' in several dozen places. I get why it's hard to admit that outliers several standard deviations above exist.
While there are certainly outliers, the OP is making a different point, and I’ll see if I can align it with yours.
von Neumann was primarily active in mathematics and physics. He published 150 papers. He moved subfields but he did so on timescales of years.
He too could only dwell in a place or two at a time; he was skilled and fortunate to be able to move between dwelling places over a career that spanned decades.
Polymaths are primarily declared polymaths only at the end of a career with the benefit of hindsight. At any given moment they are temporary specialists.
von Neumann was primarily active in mathematics and physics. He published 150 papers. He moved subfields but he did so on timescales of years.
He too could only dwell in a place or two at a time; he was skilled and fortunate to be able to move between dwelling places over a career that spanned decades.
Polymaths are primarily declared polymaths only at the end of a career with the benefit of hindsight. At any given moment they are temporary specialists.
Your extrapolating your own experiences to someone much more intelligent, hence why it's so difficult to believe.
There's plenty of evidence to suggest the limit for him was not 1 or 2.
There's plenty of evidence to suggest the limit for him was not 1 or 2.
And I could say you are overassigning individual agency to someone whose output is mostly a consequence of their environment, and how would we ever know who was correct?
Broadly speaking, I've found two kinds of mailing lists: help-focused, and develop-the-next-version-focused.
Help-focused mailing lists lead to quick boredom and burnout for anyone who isn't deeply invested in the growth of the underlying project, e.g. core maintainers who use the questions to improve the project documentation, or who is otherwise paid to respond, e.g. professional support.
Development-focused mailing lists have a strong tendency to turn into bikeshedding. Everybody who joins the mailing list is entitled to voice their opinion, everybody who subscribes to the mailing list is forced to listen to that opinion, and moderators have little power (outside of bans, which are rarely employed due to reputational risk to the moderator) to coerce the topic of discussion back on track to a more productive place. So core maintainers are incentivized to move development discussion to a more private forum, which is hidden from you.
Eventually, I realized that what I actually wanted was (a) use boring, battle-tested tech, where I typically don't need minute-by-minute updates since any such updates are focused on extreme edge cases that probably don't apply to me, (b) subscribe me to feature-focused + security-focused release notes that I can skim on the relatively uncommon occurrences that there is actually a new feature/security release, (c) subscribe me to bug-focused release notes on bugs that I've explicitly opted-in to be notified on, because I've encountered those bugs, (d) a private forum to discuss day-to-day development on the projects that I'm actually working on (and that my colleagues are actually working on). Everything else - straight to /dev/null.
Help-focused mailing lists lead to quick boredom and burnout for anyone who isn't deeply invested in the growth of the underlying project, e.g. core maintainers who use the questions to improve the project documentation, or who is otherwise paid to respond, e.g. professional support.
Development-focused mailing lists have a strong tendency to turn into bikeshedding. Everybody who joins the mailing list is entitled to voice their opinion, everybody who subscribes to the mailing list is forced to listen to that opinion, and moderators have little power (outside of bans, which are rarely employed due to reputational risk to the moderator) to coerce the topic of discussion back on track to a more productive place. So core maintainers are incentivized to move development discussion to a more private forum, which is hidden from you.
Eventually, I realized that what I actually wanted was (a) use boring, battle-tested tech, where I typically don't need minute-by-minute updates since any such updates are focused on extreme edge cases that probably don't apply to me, (b) subscribe me to feature-focused + security-focused release notes that I can skim on the relatively uncommon occurrences that there is actually a new feature/security release, (c) subscribe me to bug-focused release notes on bugs that I've explicitly opted-in to be notified on, because I've encountered those bugs, (d) a private forum to discuss day-to-day development on the projects that I'm actually working on (and that my colleagues are actually working on). Everything else - straight to /dev/null.
I'm finding the majority of activity that would have happened on email lists is now in Discord. Personally I dread opening it - my CPU fan spins up and I'm confronted with a thousand new messages and a lot of distracting fluff. To fully keep up with a community I'd have to scroll hundreds of messages, clicking on each channel, as opposed to simply scanning the subject line in an email and reading the 1% of interest.
Yeah, as an old-timer (started coding int he 80's), I find it more difficult to find the information I'm looking for in general, but especially on Discord, where the questions and replies come with much higher volume, and the signal/noise ratio seems lower. Trying to search past discussions to avoid asking something that's already been answered simply takes too long. Maybe I just feel the need to read each in the hopes I don't miss something?
I generally liked mailing lists back in the day when people took the time to craft very specific questions and responded with succinct answers. The results seemed more easily searchable to find relevant threads, which I would feel good about reading in detail, or skipping entirely.
I dunno... maybe there are just way more people asking questions or participating nowadays (regardless of whether it's in a forum, Discord, or Github), so the volume of information is naturally way up, or maybe it's our cultural shift to "more of everything in less time" (so people aren't averse to searching first and posting after not finding vs. asking something previously answered), but the end result for me is a feeling of trying to find the interesting conversations in a party held in a packed stadium vs. a party held in someone's living room.
I generally liked mailing lists back in the day when people took the time to craft very specific questions and responded with succinct answers. The results seemed more easily searchable to find relevant threads, which I would feel good about reading in detail, or skipping entirely.
I dunno... maybe there are just way more people asking questions or participating nowadays (regardless of whether it's in a forum, Discord, or Github), so the volume of information is naturally way up, or maybe it's our cultural shift to "more of everything in less time" (so people aren't averse to searching first and posting after not finding vs. asking something previously answered), but the end result for me is a feeling of trying to find the interesting conversations in a party held in a packed stadium vs. a party held in someone's living room.
Yes on platforms like Discord there's a _lot_ of noise in the form of sometimes-relevant one line comments, not succinct technical writing. For those really at the coal-face, e.g. full time project members and people learning new stuff, instant messaging works well. For a mid-forties developer like me who's keenly aware of their limited time and resources, I need the overview. Some communities manage this well, e.g. OpenStreetMap provides a weekly summary. Participation and information are both _way_ up but I think the noise is really symptom of instant messaging.
This.
Honestly the most effective tool I ever used to navigate a "conversational space" was trn, which, solely with the keyboard, you could follow threads (as a tree) and truncate uninteresting ones, block idiots, search, etc. All later ones have been slower and more irritating.
Honestly the most effective tool I ever used to navigate a "conversational space" was trn, which, solely with the keyboard, you could follow threads (as a tree) and truncate uninteresting ones, block idiots, search, etc. All later ones have been slower and more irritating.
As a vim user that would be lovely. A short lived dream of a keyboard-centric discord has been killed by their ToS - third party clients are not allowed. Email is clunky, but it's decentralised and I can choose my client!
I found trn a very bad tool.
There was no way for example to do what the back button in a browser does without instituting a search through an unbounded number of messages and IIRC finicky use of the arrow keys during the search while consulting the "tree view" in the upper right corner of the screen. Doing the analog of the back button was easy only when the current message is a reply to the message you want to get back to.
Trn was optimized for the speed at which the user could consume (textual) information, but worse than the web at allowing the user to hone in on the one or two pieces of information (text) that the user most wants to know (even assuming a hypothetical world in which search engines do not exist).
Most people find learning new things and new points of view to be pleasurable (and the fast the new things and new points of view are consumed, the greater the pleasure), and I am no exception, but my experience has been that using the internet to chase that pleasure for its own sake does more harm than good. Trn was better at producing the pleasure than the web was because information could be kept coming at a higher rate than by using the web for the same amount of mental effort.
For example, when a person is done reading a web page there is some mental effort in deciding which page to go to next, e.g., which link to click. Yes, trn has keystrokes that say, "I'm done with this message, show me the next one" and "I'm done with this subtree, show me the next one", but I found it tempting to keep hitting the space bar, which yielded an experience in me of being constantly presented with new information ("stimuli") without having to make any decision or do any significant mental work, much like watching TV yields.
I am going to guess that unlike me, you do not worry about adverse effects from your spending time on the internet taking in a constant stream of information rapidly presented; am I correct about that?
There was no way for example to do what the back button in a browser does without instituting a search through an unbounded number of messages and IIRC finicky use of the arrow keys during the search while consulting the "tree view" in the upper right corner of the screen. Doing the analog of the back button was easy only when the current message is a reply to the message you want to get back to.
Trn was optimized for the speed at which the user could consume (textual) information, but worse than the web at allowing the user to hone in on the one or two pieces of information (text) that the user most wants to know (even assuming a hypothetical world in which search engines do not exist).
Most people find learning new things and new points of view to be pleasurable (and the fast the new things and new points of view are consumed, the greater the pleasure), and I am no exception, but my experience has been that using the internet to chase that pleasure for its own sake does more harm than good. Trn was better at producing the pleasure than the web was because information could be kept coming at a higher rate than by using the web for the same amount of mental effort.
For example, when a person is done reading a web page there is some mental effort in deciding which page to go to next, e.g., which link to click. Yes, trn has keystrokes that say, "I'm done with this message, show me the next one" and "I'm done with this subtree, show me the next one", but I found it tempting to keep hitting the space bar, which yielded an experience in me of being constantly presented with new information ("stimuli") without having to make any decision or do any significant mental work, much like watching TV yields.
I am going to guess that unlike me, you do not worry about adverse effects from your spending time on the internet taking in a constant stream of information rapidly presented; am I correct about that?
But that's because trn was a "threaded news reader" not a "USENET archive search console". It was a very good tool for its intended purpose which, as you mention, was to consume a flow of news. Compare it to an email client or to other real-time chat fora. Also, it was a medium meant for participation, not just passive consumption. The client helped you find current topics and reply.
Generally, nobody expected a newsgroup message archive to exist much less for searching of stale messages to be a normal activity. The client tools and most servers were meant to buffer just a useful fringe of traffic to allow people to follow the flow while engaging and disengaging from the groups in async bursts. We would sit at the terminal and participate for a session, then walk away.
Back in the heyday of trn and USENET in general, it would be considered odd for people to hoard old messages, necropost on old threads (other than if there was some running in-joke to perpetuate in a certain group), or to be constantly online and obsessively responding with low latency throughout the whole day. Reply chains would often have multi-hour to multi-day latency, and higher volume groups were usually from more concurrent users and threads rather than more rapid messaging in a single chain.
Generally, nobody expected a newsgroup message archive to exist much less for searching of stale messages to be a normal activity. The client tools and most servers were meant to buffer just a useful fringe of traffic to allow people to follow the flow while engaging and disengaging from the groups in async bursts. We would sit at the terminal and participate for a session, then walk away.
Back in the heyday of trn and USENET in general, it would be considered odd for people to hoard old messages, necropost on old threads (other than if there was some running in-joke to perpetuate in a certain group), or to be constantly online and obsessively responding with low latency throughout the whole day. Reply chains would often have multi-hour to multi-day latency, and higher volume groups were usually from more concurrent users and threads rather than more rapid messaging in a single chain.
OK, let me refine my statement: trn prove a poor tool for me compared to Slashdot, HN or Stack Overflow.
Yes, same for slrn and (for mailing lists) mutt. It only went down from there in terms of effectiveness (PHP web forums, Reddit, Twitter, Discord, also HN).
Sure wish all that was searchable and archived. The forums were not as interactive, but the value is off the charts higher.
I like Discord, but I now have a new problem, it crashes every time my computer goes to sleep. This has caused me to miss important messages, and catching up and use the app less and less overall. I basically only get messages when I reboot my laptop (rare), before the first sleep.
The foremost use of a technically oriented public communication space is
1) Access to experienced persons with a depth of knowledge that exceeds your own
2) Whatever good feelings one gets from staying informed about technology and helping others with issues
3. Archiving the knowledge and the solutions contained within the space
In #3 mailing lists fail splendidly.
* I have never been able to easily follow a archived mailing list thread (why do the reply links bounce around and never are in chronological order?).
* they tend to be rarely searchable from the web.
* If one does not know the people on the list and their reputations and bona fides, evaluating the accuracy of information is difficult
* They are scattered all over the place and are un-findable unless you know exactly where to look
For the reasons above any sort of web forum or reddit-like platform is preferable for posterity as long as the information remains accessible on that platform.
1) Access to experienced persons with a depth of knowledge that exceeds your own
2) Whatever good feelings one gets from staying informed about technology and helping others with issues
3. Archiving the knowledge and the solutions contained within the space
In #3 mailing lists fail splendidly.
* I have never been able to easily follow a archived mailing list thread (why do the reply links bounce around and never are in chronological order?).
* they tend to be rarely searchable from the web.
* If one does not know the people on the list and their reputations and bona fides, evaluating the accuracy of information is difficult
* They are scattered all over the place and are un-findable unless you know exactly where to look
For the reasons above any sort of web forum or reddit-like platform is preferable for posterity as long as the information remains accessible on that platform.
> I have never been able to easily follow a archived mailing list thread (why do the reply links bounce around and never are in chronological order?).
The ease or difficulty really comes down to the client you use. If you use a email client that can import an archive file of the list and display messages in proper threaded order. The other option is to use a NNTP gateway service and read the threaded discussion. Gmane used to provide it. public inbox[1] is another service that may work.
[1] https://public-inbox.org/README.html
The ease or difficulty really comes down to the client you use. If you use a email client that can import an archive file of the list and display messages in proper threaded order. The other option is to use a NNTP gateway service and read the threaded discussion. Gmane used to provide it. public inbox[1] is another service that may work.
[1] https://public-inbox.org/README.html
I’ve been involved with technical documentation a lot by now, and think the only actually working solution for archiving and passing on knowledge is something like a Wiki, combined with something like GitHub discussions, where individual discussions can lead to change requests or new articles. That way, discussions of the topic could lead to changes on the canon.
I do agree with the idea of wiki is the right way, but I think most orgs overestimate to an extreme degree how much work a "simple wiki" (my words) really takes to be useful.
One of the disadvantages of a mailing list that is actually a surprise feature is the lack of content curation; as pedantic as the wikipedia edit wars might be, having tried to maintain a wiki for one of my work places, I understand why they happen, even when you have a well documented and followed structure and content guideline that everyone is aware of. Generating consistent and accurate content, and curating said content, is really a full time job, and for technical content neither item is something I'm comfortable sourcing to a group that isn't also able to contribute to content on their own in a meaningful way, as this can really harm the value of such a wiki.
I think the tooling is less important than the dedication to developing a structure, enforcing the structure, and curating what gets into the documentation very hard. Mailing lists kind of avoid this because they neither propose to be curated no require someone to decide "today I will write X and Y articles", the interest and the discussions define the direction of the content creation. Great for getting data out there, but not great at being searchable or meeting user needs for relevance.
One of the disadvantages of a mailing list that is actually a surprise feature is the lack of content curation; as pedantic as the wikipedia edit wars might be, having tried to maintain a wiki for one of my work places, I understand why they happen, even when you have a well documented and followed structure and content guideline that everyone is aware of. Generating consistent and accurate content, and curating said content, is really a full time job, and for technical content neither item is something I'm comfortable sourcing to a group that isn't also able to contribute to content on their own in a meaningful way, as this can really harm the value of such a wiki.
I think the tooling is less important than the dedication to developing a structure, enforcing the structure, and curating what gets into the documentation very hard. Mailing lists kind of avoid this because they neither propose to be curated no require someone to decide "today I will write X and Y articles", the interest and the discussions define the direction of the content creation. Great for getting data out there, but not great at being searchable or meeting user needs for relevance.
The main work with wikis, is keeping them up to date.
Worse than no documentation is wrong documentation in my experience.
So if there is a vibrant community, than solid ressources like the Arch Wiki can get created and maintained ( but even there I encountered out dated, or wrong information).
Worse than no documentation is wrong documentation in my experience.
So if there is a vibrant community, than solid ressources like the Arch Wiki can get created and maintained ( but even there I encountered out dated, or wrong information).
I Try very hard to explain why we don’t document facts on our wiki, but concepts, with links to facts. We aim to maintain a single source of truth of what should be, and have automated systems to tell us what is. Want to know what ip server “lon-rds14” should be? Ping it. DNS is driven from the ip mgmt tool, job done. Check the auto populated cmdb which will tell you the current interfaces on a given host to tell you what ip it really is.
Want to know where on the network it is? Search the portmapper, which tells you (through switch labels) where the host should be, and through mac/ip/dns where is actually is (cmdb also has the lldp entry - duplicating data that automatically updated is fine)
On our work wiki (20k users), different departments copy and paste information from one page to another so it’s in “their” area. Even worse one department locks down its area so it’s hidden to those outside the department!
Want to know where on the network it is? Search the portmapper, which tells you (through switch labels) where the host should be, and through mac/ip/dns where is actually is (cmdb also has the lldp entry - duplicating data that automatically updated is fine)
On our work wiki (20k users), different departments copy and paste information from one page to another so it’s in “their” area. Even worse one department locks down its area so it’s hidden to those outside the department!
I've pondered how one could set up conditions in documentation. For example display [collapsed] code in the document that implements the functionality there described. If the exact code is no longer found in the source the article or section gets a warning banner, a [collapsed] div view and the wiki bug tracker displaying the issue.
Perhaps one could also programmatically generate a list of missing articles by looking at code and implementations.
Perhaps one could also programmatically generate a list of missing articles by looking at code and implementations.
To be clear, a Wiki as it is isn’t the best possible tool to gather knowledge about a specific topic in general, even if it works for the Wikipedia. Kind of like how git isn’t perfect for projects other than the Linux kernel.
I agree that dedication is vastly more important than tooling, but simultaneously you need a medium that is both simple to use and suited to preserve and accumulate knowledge; somewhat of a middleground between a long PDF document and a Slack channel with 10k messages. At this point, I’m pretty sure it must be easy to get new topics out there, then hone them step by step into something useful for the future.
I agree that dedication is vastly more important than tooling, but simultaneously you need a medium that is both simple to use and suited to preserve and accumulate knowledge; somewhat of a middleground between a long PDF document and a Slack channel with 10k messages. At this point, I’m pretty sure it must be easy to get new topics out there, then hone them step by step into something useful for the future.
> For the reasons above any sort of web forum or reddit-like platform is preferable for posterity as long as the information remains accessible on that platform.
Web forums force everyone to use one UI provided by forum operator, while technologies designed around conversations (mail, netnews (RIP), IRC, Matrix and others ...) allow everyone to choose their preferred clients/UI. That itself is (for me) web forum disadvantage outweighing most other aspects.
Web forums force everyone to use one UI provided by forum operator, while technologies designed around conversations (mail, netnews (RIP), IRC, Matrix and others ...) allow everyone to choose their preferred clients/UI. That itself is (for me) web forum disadvantage outweighing most other aspects.
Mailing lists don't have to suck or be unsearchable. See sourcehut: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<000001d97d57$ca...
#3
Ideally the 'archive' is that stuff which is unclear or poorly documented gets updated in the documentation, so it doesn't come up again.
Ideally the 'archive' is that stuff which is unclear or poorly documented gets updated in the documentation, so it doesn't come up again.
I am not sure all GNU mailing lists are archived, but the ones I read are very well searchable and threads well explorable in the browser. I follow along daily digests and Thunderbird displays threads nicely. I tag some or move them to my archives in Thunderbird. If I cannot find something, I check in the browser.
For me, the biggest problem with mailing lists is that most are extremely unwilling to ban people — I understand this as a principle, but there are several lists I was on where a significant proportion of the posts were one person, arguing with everyone. Slowly people left, and the list died.
I’d love to see an option in mailing list confits that would, at least, make it easy to enforce people can’t be more than say 5% of posts — this could obviously be overriden by admins, but would give a base where no one can swamp the list.
I’d love to see an option in mailing list confits that would, at least, make it easy to enforce people can’t be more than say 5% of posts — this could obviously be overriden by admins, but would give a base where no one can swamp the list.
Public groups are a good place to get to know someone's online personality.
But the real work seems to get done on private invite-only groups, which might be on the same, or different, media.
For example I'm involved in a community that uses skype groups as a channel. There are public groups, and there are private groups that only bring in people who have proved to be well behaved, and useful (and willing).
This mimics real life. We have layers - the get-stuff-done folk have back-channels to keep things moving even if the public space is functioning poorly.
But the real work seems to get done on private invite-only groups, which might be on the same, or different, media.
For example I'm involved in a community that uses skype groups as a channel. There are public groups, and there are private groups that only bring in people who have proved to be well behaved, and useful (and willing).
This mimics real life. We have layers - the get-stuff-done folk have back-channels to keep things moving even if the public space is functioning poorly.
I want peer reviewed lists-- your post will in theory burn the time of 1000 people or whatever. Yet the first person who reads it might see holes in it that make it a waste of time to read. So instead, have it go to a couple people first.
Better posters could do this themselves (at least for new threads), but its the people who don't care much about the quality of their posts that need it the most.
I think the challenge is that it'll only work if there is a high enough density of sophisticated participants that can understand that a reviewers role isn't to agree or not, but to help make the time spend reading it by all the other readers as well spent as it can be. But where it could work, it could be a big improvement. -- think of all the posts that the author would skip when someone just points them to where it was discussed before.
Better posters could do this themselves (at least for new threads), but its the people who don't care much about the quality of their posts that need it the most.
I think the challenge is that it'll only work if there is a high enough density of sophisticated participants that can understand that a reviewers role isn't to agree or not, but to help make the time spend reading it by all the other readers as well spent as it can be. But where it could work, it could be a big improvement. -- think of all the posts that the author would skip when someone just points them to where it was discussed before.
> Yet the first person who reads it might see holes in it that make it a waste of time to read. So instead, have it go to a couple people first.
Sounds like upvote/downvote in a subreddit...?
Sounds like upvote/downvote in a subreddit...?
That's more of a popularity contest than peer review. A reviewer could give you feedback like "I can't figure out what you're talking about could you add citations for FIZBUZZ and FOOBAR?" or "What you're suggesting appears to be the same as this 2013 proposal. If what you're proposing is different or if you think the idea will work this time could you explain?"
The end result is a post which is higher quality rather than just a competition for the hottest hottakes.
The end result is a post which is higher quality rather than just a competition for the hottest hottakes.
> understand that a reviewers role isn't to agree or not
Humans are universally terrible at doing this.
IMHO the only hope is to give them two voting axes, so they can placate their lizard-brain's "downvote to disagree" impulse but still apply a separate but positive expository-quality rating. If you only collect the latter kind of rating it won't work.
TL;DR: in addition to thumbs-up/thumbs-down, give people poop-emoji/gold-star. I would hand out a lot of poopy-thumbs-up votes.
Humans are universally terrible at doing this.
IMHO the only hope is to give them two voting axes, so they can placate their lizard-brain's "downvote to disagree" impulse but still apply a separate but positive expository-quality rating. If you only collect the latter kind of rating it won't work.
TL;DR: in addition to thumbs-up/thumbs-down, give people poop-emoji/gold-star. I would hand out a lot of poopy-thumbs-up votes.
The fact multi-axis voting has not taken off really has made the internet a worse place.
+2 Insightful!
Slashdot's system came close, but it only did half of what's necessary.
IIRC there were no options where the +number and label disagreed -- they didn't have "+1 Spammy" or "-1 Insightful".
IIRC there were no options where the +number and label disagreed -- they didn't have "+1 Spammy" or "-1 Insightful".
It's amazing that the popular mailing list manager Mailman doesn't seem to have the feature of user-defined filtering. You should be able to send a command to the list robot not to send you messages that match certain criteria.
If you embroil yourself in some debate you don't want, you will still see the subsequent posts, as you continue to be Cc:'d on the debate. CC's reach you directly, bypassing the robot.
But the filter would at least not show you newly started discussions which match some pattern.
Furthermore, it should be easy to move or synchronize such rules between mailing lists (even on different servers, run by different orgs).
Of course, you can always filter locally in your MUA or possibly MTA.
If you embroil yourself in some debate you don't want, you will still see the subsequent posts, as you continue to be Cc:'d on the debate. CC's reach you directly, bypassing the robot.
But the filter would at least not show you newly started discussions which match some pattern.
Furthermore, it should be easy to move or synchronize such rules between mailing lists (even on different servers, run by different orgs).
Of course, you can always filter locally in your MUA or possibly MTA.
> If you embroil yourself in some debate you don't want, you will still see the subsequent posts, as you continue to be Cc:'d on the debate. CC's reach you directly, bypassing the robot.
This is where client side filtering comes in. Mail and News clients come with sophisticated filtering capabilities. For example, if you keep getting CC'd in a flame war type thread, you could filter replies based on the From header, the Subject header, and/or even checking for certain terms in the message body.
This is where client side filtering comes in. Mail and News clients come with sophisticated filtering capabilities. For example, if you keep getting CC'd in a flame war type thread, you could filter replies based on the From header, the Subject header, and/or even checking for certain terms in the message body.
This is one of my most disliked parts of the email model. I generally have an MTA running and IMAP server where I set rules such as blocking mailing list threads and use my MUAs as dumb clients to fetch from the IMAP server. Setting the rules on the MTA is a bit of a pain but it works and keeps my setup portable.
> Of course, you can always filter locally in your MUA
Well, the user's agent is the correct place to put the user's filters.
Well, the user's agent is the correct place to put the user's filters.
From purely and efficiency point of view, filter which removes events should be as high up the chain as possible. As close to the source as possible.
Say that the mailing list robot is processing an email from somebody and it turns out that every single mailing list subscriber is blocking that email for one reason or another. The mailing list robot can drop it in the bitbucket. No mail servers need to be contacted.
In this situation, it would be possible for the mailing list to do something interesting: it could prevent that message from making into the list archive, like it never happened. That is not possible with user filtering. If nobody receives the message due to downstream user filtering, the robot has no way of knowing that.
Effectively the list-side user defined filters could act as a vote of whether a message is actually accepted by the mailing list and made available in its web archive. If the current subscribers don't accept a post, then the list of such doesn't accept the post.
Say that the mailing list robot is processing an email from somebody and it turns out that every single mailing list subscriber is blocking that email for one reason or another. The mailing list robot can drop it in the bitbucket. No mail servers need to be contacted.
In this situation, it would be possible for the mailing list to do something interesting: it could prevent that message from making into the list archive, like it never happened. That is not possible with user filtering. If nobody receives the message due to downstream user filtering, the robot has no way of knowing that.
Effectively the list-side user defined filters could act as a vote of whether a message is actually accepted by the mailing list and made available in its web archive. If the current subscribers don't accept a post, then the list of such doesn't accept the post.
> My current mail reading environment is not well suited to situations where a large amount of the volume is uninteresting to me and I'm picking through it for the small number of interesting discussions of interesting issues.
I don't have this problem somehow. I sort the mailing lists into their own folders, where they are viewed as a thread. An entire uninteresting thread appears collapsed into one line, no matter how many messages belong to it, and whether new ones are coming.
The mailing lists are not super busy.
I don't have this problem somehow. I sort the mailing lists into their own folders, where they are viewed as a thread. An entire uninteresting thread appears collapsed into one line, no matter how many messages belong to it, and whether new ones are coming.
The mailing lists are not super busy.
There's just no reason to use a mailing list when forums, chats, pull requests and issue trackers exist. They're clunky and hard to use and terrible UX compared to the alternatives. Its much easier to filter on what you actually want to see with modern tools.
But most forums these days are shitty compared to what we had a decade or longer ago, when it comes to being accessible and searchable. If we were using classical forums everywhere, I might agree, but with the new JS-only crop of forums, I feel delighted, when a community has an active mailing list instead.
And chats don't really serve information archival or storage functions well. Especially not proprietary ones like Discord. Maybe some like Zulip, if there is some extension or so, to make content well searchable from a search engine. But that is still only a maybe.
PRs and issue trackers, yes, yes, but only if you got capable people moderating them, not people who think, that employing a github bot to auto close issues is a good idea, when questions remain unanswered. Also one cannot paste GPL licensed code on Github issues any longer with a good conscience, because of code laundering by MS. So that is also no good solution any longer.
> There's just no reason to use a mailing list when forums, chats, pull requests and issue trackers exist.
One thing that modern tools lack that classic tools had was an index view that allowed you to quickly navigate to the comment/message you wanted to read. They also lack an easy marker to show whether you have already read the message. Both of these features were in the email and new client I used in the mid to late '90s. These features are missing in forums, chats, pull requests, and issue trackers that I have to use today, so I end up having to navigate to pages to see whether they've been updated and I have to spend a lot of time scrolling to find the update within the page.
> They're clunky and hard to use and terrible UX compared to the alternatives.
Having to repeatedly check the same page and scroll a lot to even find what one is looking for is a lot more clunky and more difficult to use compared to the classic interfaces available a quarter century ago.
One thing that modern tools lack that classic tools had was an index view that allowed you to quickly navigate to the comment/message you wanted to read. They also lack an easy marker to show whether you have already read the message. Both of these features were in the email and new client I used in the mid to late '90s. These features are missing in forums, chats, pull requests, and issue trackers that I have to use today, so I end up having to navigate to pages to see whether they've been updated and I have to spend a lot of time scrolling to find the update within the page.
> They're clunky and hard to use and terrible UX compared to the alternatives.
Having to repeatedly check the same page and scroll a lot to even find what one is looking for is a lot more clunky and more difficult to use compared to the classic interfaces available a quarter century ago.
With the right email client, the efficiency of mailing lists for asynchronous longer-form discussions is unmatched (except possibly for Usenet – they are very similar). The crucial parts are auto-sorting into mailing list-specific folders, threaded display, newest-on-bottom, and keyboard navigation.
The only think that email lacks that nntp has is the ability to easily find messages from before you subscribed to the list (or were CC'd). With email, you could download a list archive and import it in your MUA, but with NNTP, you can just subscribe to a group and pull up messages as far back as you want (up till the oldest message on the server).
Right, for mailing lists I used to ask some old-timer to send me their mbox archive of the list.
While all MUA sucks UI/UX for most web forums even worse - much higher response time, and a lot of mouse clicks for navigation (instead of familiar keyboard shortcuts). Some sites do support shortcuts but they differ from site to site while with MUA you need to learn them only once for all maillists.
I agree that requirement to subscribe to a maillist is an entry barrier which doesn't exists for web forums but once you're are subscribed it is faster to skim messages in a mailbox.
I agree that requirement to subscribe to a maillist is an entry barrier which doesn't exists for web forums but once you're are subscribed it is faster to skim messages in a mailbox.
I wish NNTP was still alive and widely used - it is easier/faster to subscribe to a newsgroup than to a maillist and once you've subscribed you can see old messages in your client and reply to them (not only new messages like with a maillist).
I think people prefer mailing lists over nntp due to a number of reasons:
1. It's easier to set a mailing list up compared to creating a new newsgroup or setting up an on-premise NNTP server (is NNTP as a service even a thing?)
2. Most people have access to email clients (either web based or local applications) compared to NNTP clients.
Personally, I think it would be much better if people use NNTP instead of mailing lists, but doing so would require somoene to maintain the NNTP server and handle account creation for posting access.
1. It's easier to set a mailing list up compared to creating a new newsgroup or setting up an on-premise NNTP server (is NNTP as a service even a thing?)
2. Most people have access to email clients (either web based or local applications) compared to NNTP clients.
Personally, I think it would be much better if people use NNTP instead of mailing lists, but doing so would require somoene to maintain the NNTP server and handle account creation for posting access.
https://gitlab.com/mailman/hyperkitty is a great improvement in this area
> My current mail reading environment is not well suited to situations where a large amount of the volume is uninteresting to me and I'm picking through it for the small number of interesting discussions of interesting issues. In a forum, I could ignore entire topic areas and most of the threads, focusing only on some specific ones of interests; in my current mailing list environment, I drown and stop reading.
This could be accomplished by having different mailing lists for each major topic area (perhaps utilizing the + for topic aliases).
This could be accomplished by having different mailing lists for each major topic area (perhaps utilizing the + for topic aliases).
> In the beginning I had unkind descriptions of these sorts of questions, but I've come to be more sympathetic to them, especially the questions that come from people abroad who may not have English as their first language. The unfortunate fact is that projects aren't necessarily well documented and their documentation probably is dauntingly hard to read for people who aren't fluent in technical English, and people have work to get done (using those projects).
I am lucky to have English be my primary language. If most of the world's documentation was in another language like Spanish, I can certainly see myself struggling to RTFM and resort to posting on a forum with my best effort at using Spanish to explain the context of my technical bug and request for help.
I am lucky to have English be my primary language. If most of the world's documentation was in another language like Spanish, I can certainly see myself struggling to RTFM and resort to posting on a forum with my best effort at using Spanish to explain the context of my technical bug and request for help.
English isn‘t my native language, but the language I am most comfortable having technical conversations in. I struggle to express computer science topics in my first language.
I talked to many who share that sentiment. Computer science, programming languages, documentation, and discussion forums tend to be anglocentric. I learned in English, and most technical terms are English.
A loop is a loop. There is a word for it in my native language, but it sounds very weird to me to use it in a technical context. Almost nobody uses the native term. Everybody just says "loop".
There are even many words that do not really have a translation. There isn‘t a good translation for "release" in German, when used as a noun.
I talked to many who share that sentiment. Computer science, programming languages, documentation, and discussion forums tend to be anglocentric. I learned in English, and most technical terms are English.
A loop is a loop. There is a word for it in my native language, but it sounds very weird to me to use it in a technical context. Almost nobody uses the native term. Everybody just says "loop".
There are even many words that do not really have a translation. There isn‘t a good translation for "release" in German, when used as a noun.
Example in a totally different context: There's lots of Go terms that are Japanese, and don't have an English word. They just are that word: https://en.wikipedia.org/wiki/List_of_Go_terms
The ancient Opera Mail had excellent support for infinitely nested threads, and ability to mute any subtree of the replies. This was marvellous for dealing with mailing lists.
Sadly, the good Opera is long dead, and most email clients are (over)simplified to single-level threads.
Sadly, the good Opera is long dead, and most email clients are (over)simplified to single-level threads.
The state of contemporary email clients is quite sad. Apparently the demand for high-quality clients is not high enough.
I wonder if it is because we got nicer. RTFM, etc is considered rather rude now. Which is great because people used to be very rude to newbies, creating barriers to entry, but i guess it is also going to decrease signal to noise ratio.
The rule I often see enforced for asking questions is "show us what you've done so far to solve your own problem".
Which is much more reasonable and, more importantly, actionable. Even if no code is shared and it’s just a rough train of though of how the asker is approaching the problem, that’s enough to infer both intent and what solving this problem means for this person.
Exactly. There are so many benefits and zero downsides.
Even if someone follows with "RTFM" anyway, it doesn't automatically create a rude culture so much as it rudely informs you of the etiquette for participating in a helpful culture.
Even if someone follows with "RTFM" anyway, it doesn't automatically create a rude culture so much as it rudely informs you of the etiquette for participating in a helpful culture.
You can say RTFM more nicely, e.g. "You're asking some very basic questions that are answered in the documentation, or in the archives of this email list" but bottom line some people are just lazy. They want the answer, not more work for themselves.
This is one place where AI might be helpful. It will never get tired of answering the same basic questions over and over again.
This is one place where AI might be helpful. It will never get tired of answering the same basic questions over and over again.
Barriers to entry aren't necessarily a bad thing. They weed out people who aren't willing to invest the minimum necessary effort. 95% of the complaints about mailing lists, forums, discord, wikis and the like revolve around leeches who aren't willing to...RTFM
I stayed on them to help the new folks out, and then to improve the documentation so I have less questions to answer.
I've found two types of people on email lists: those who never read the documentation and go straight to the list with questions; those who do read it and point out deficiencies or suggest improvements. The former always seemed to far outweigh the latter, so improving the documentation doesn't do much to reduce the number of questions.
Having documentation also means you can just point the former folks at it (or copy-paste) instead of writing the same thing over and over again.
Seems like a natural progression of a person's interests. When I started reading HN in ~2009 almost everything on the front page was new to me and I spent a ton of time reading articles and comments. Now, I've had almost 15 years of working and reading and studying and the only things that I don't have at least some passing familiarity with are extremely technical or news or political things that largely don't interest me. I spend a lot less time on HN now than I used to and I don't think it's because the site got worse, just because my interests have moved past what the site offers.
This feeling is also a good sign that you're now pursuing mastery. There is no content being produced for people like you. It's now up to you synthesize new stuff.
As an incidental observation, technical mailing lists could be a goldmine for training LLMs about software engineering practice in the real world. I wonder if these end up in any of the common corpuses used for model training.
After double digit years in software development, terms keep confusing me and often the ease with which they are introduced often puzzle me. Like map, set, list, array, object, subject, collection and switch. The way every other language uses them in a slightly different way is confusing for English natives, let alone foreign languages. It is not only documentation that is lacking, it is also the way every other new kid on the block implements the same thing in a completely different way.
Maybe there's a lesson on efficiency of group communications, including maintaining strictly high signal-to-noise and rules enforcing on-topic discussion.
I would love to discover such forums.
I would love to discover such forums.
The post was specifically about mailing lists as opposed to things like forums.
I would love to find out about high-signal tech mailing groups. Even if they're niche tech or non-software or specific language or if I need to translate them. Bonus points if they're not currently perceived as bleeding edge getting all the attention.
I would love to find out about high-signal tech mailing groups. Even if they're niche tech or non-software or specific language or if I need to translate them. Bonus points if they're not currently perceived as bleeding edge getting all the attention.
Mailing lists should be a thing of the past. Even email itself as an infrastructure has degraded too much to be an adequate solution for being used by open source projects.
Me too. I rather spend ny time on useful things, like writing code, fixing code, arguing on issues, PR's and wiki"s.
And mailing lists are a cesspit mostly.
And mailing lists are a cesspit mostly.
I still read them but I have to police writing to them. That seems to keep the S/N ratio higher.
Unfiltered stream is just a very bad mode of communication, as correctly described in the other linked post by the author, forums are much better, pity that some projects persist in in using this poorly designed tech
Is there any point posting quotes in titles without the person's name? Especially quotes like this that doesn't give any information
Me too, it really is a shame because it really is a great way to keep up with what is happening.
For some reason I seem to have less and less time.
For some reason I seem to have less and less time.
Most people don't dwell anywhere, I suspect. I wouldn't feel too bad about pulling back - it actually sounds exhausting. Maybe one day you'll rejoin a particularly important space, and focus on really being part of that group long-term.