I've mostly stopped reading technical mailing lists
utcc.utoronto.ca
utcc.utoronto.ca
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.
...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.
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.
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.
There's plenty of evidence to suggest the limit for him was not 1 or 2.
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.
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.
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?
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.
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.
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.
Ideally the 'archive' is that stuff which is unclear or poorly documented gets updated in the documentation, so it doesn't come up again.
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.
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).
Perhaps one could also programmatically generate a list of missing articles by looking at code and implementations.
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 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.
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.
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.
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.
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.
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.
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.
IIRC there were no options where the +number and label disagreed -- they didn't have "+1 Spammy" or "-1 Insightful".
Sounds like upvote/downvote in a subreddit...?
The end result is a post which is higher quality rather than just a competition for the hottest hottakes.
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.
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.
Well, the user's agent is the correct place to put the user's filters.
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.
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 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.
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.
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.
This could be accomplished by having different mailing lists for each major topic area (perhaps utilizing the + for topic aliases).
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 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.
Sadly, the good Opera is long dead, and most email clients are (over)simplified to single-level threads.
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.
This is one place where AI might be helpful. It will never get tired of answering the same basic questions over and over again.
I would love to discover such 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.
And mailing lists are a cesspit mostly.
For some reason I seem to have less and less time.