Leaving python-dev behind
It was not all that long ago that Python began its experiment with replacing one of its mailing lists with a forum on its Discourse discussion site. Over time, the Discourse instance has become more and more popular within the Python community. It would seem that another mailing list will soon be subsumed within Discourse as the Python steering council is planning to effectively retire the venerable python-dev mailing list soon.
History
Back in 2018, both Fedora and Python were experimenting with Discourse instances; both
are quite active at this point.
Discourse is an open-source web
forum project that says it aims to "reimagine what a modern Internet
discussion forum should be today, in a world of ubiquitous smartphones,
tablets, Facebook, and Twitter
". But Fedora and Python currently
still have mailing lists
as well.
As part of the experiment for Python, the core-developer-only python-committers mailing list was switched to Discourse for a few months as a test. That was during the upheaval in the Python world that stemmed from Guido van Rossum's resignation as its benevolent dictator for life. The announcement of the experiment was deemed a bit of an overreach at the time, but the discussion of the new governance model for the language did largely happen in the Committers forum on Discourse.
These days, the python-committers list still exists, but it mostly receives announcements and the like; some discussions still take place there, but most, it would seem, are done on the Discourse site. There are plenty of other forums on that site, including two that overlap the main mailing lists where development discussions take place. The Core Development forum overlaps the function of the python-dev mailing list, while the Ideas forum serves the same purpose as the python-ideas mailing list.
Up until recently, there was no real indication that changes might be in
the works, but an April query
about PEP discussion that was posted to python-dev by Victor Stinner may have
been the first real public indication that changes were afoot. He asked
that new PEPs be announced on python-dev since he did not go to Discourse
often and several PEPs of interest had slipped by without notice because
they failed to be posted there. He also noted
that it is "sometimes hard to keep track of everything happening around
Python development
" in part because of all of the different ways the
project's developers communicate:
The discussions are scattered between multiple communication channels:Sometimes, I [am] already confused by the same topic being discussed in two different Discord rooms :-) It's also common that some people discuss on the issue, and other people have a parallel discussion (about the same topic) on the related pull request.
- Issues
- Pull requests
- python-dev
- python-committers
- (private) Discord
- Discourse
- (public) IRC #python-dev
He noted that there are some in-person events, too, that make it even harder
to keep up for those who cannot attend. Petr Viktorin replied
that PEPs should be posted to python-dev, "but not necessarily
right after they're published
". They may be discussed elsewhere
before coming to python-dev, for example.
The intent, Viktorin said,
is that PEPs should only be submitted to the steering council, of
which he is a member, "after
all relevant discussion took place
", which includes python-dev.
Choosing one
Jean Abou Samra noted that the split in the location for discussions is
confusing to him, so he asked
about any plans "to retire either Discourse or the mailing list and use a
unified communication channel
". Gregory P. Smith, who is also a
steering council
member, replied:
We feel it too. We've been finding Discourse more useful from a community moderation and thread management point of view as well as offering markdown text and code rendering. Ideal for PEP discussions. Many of us expect python-dev to wind up obsoleted by Discourse as a result.
That led to some predictable grumbling about Discourse and the problems with following a web-based forum in comparison to a mailing list. That divide comes up whenever changes of this sort are announced or discussed, but newer developers generally seem to be uninterested in learning the "joys" of participating on mailing lists. In part, that is because the relevance of email as a communication mechanism has fallen almost completely off the radar for many. But the writing seems to be on the wall—for Python at least. As Christopher Barker put it:
But if Discourse has been adopted, I guess it's time for us curmudgeons to bite the bullet and start monitoring it -- and frankly, this list (and python-ideas) should probably be retired, or turned into an announcement-only list -- having the current split is the worst option of all.
For discussions on the development of CPython, the python-dev mailing list has been the place to go for two decades or more. The mailing list page has archives going back to April 1999. In fact, one of the earliest messages archived is from Van Rossum asking whether the python-dev archives should be public or private. Obviously, "public" was the decision.
On July 15, Viktorin posted a message that would seem to be bringing that history to a close. On behalf of the council, he said:
The discuss.python.org experiment has been going on for quite a while, and while the platform is not without its issues, we consider it a success. The Core Development category is busier than python-dev. According to staff, discuss.python.org is much easier to moderate.. If you're following python-dev but not discuss.python.org, you're missing out.The Steering Council would like to switch from python-dev to discuss.python.org.
His message recognized that not everyone finds the Discourse forum software
running at discuss.python.org to be easy to follow and use either; it
contained several suggestions for alternate ways to interact with it, including
"mailing-list mode". The message was also soliciting feedback on whether a
permanent switch would "pose an undue burden to anyone
". A final
decision on the switch had not been made, so the council wants to ensure that it
is "aware of all the impact
".
No one has really raised any concrete problems of that nature, though Barry
Warsaw mentioned
the possibility of "accessibility or native language concerns
" for
Discourse. He also noted that he supports moving to Discourse, which
"might seem odd coming from me
"; Warsaw is one of the lead developers of the
GNU Mailman mailing-list
manager system and was a big part of the Mailman 3 effort. "Discourse is not without its issues, but then again, the same can be
said about email.
"
While there were posts with the usual negative opinions of web forums versus email, they were fairly muted. To an extent, it would seem that there is a generational change going on in the Python community; the older developers are either adapting, perhaps via mailing-list mode, or kind of just bowing out. For those looking for more information, mailing-list mode is briefly mentioned in the "Following Python's Development" section of the Python Developer's Guide. But mailing-list mode is not able to disguise one problem that Discourse discussions have: no threading. Ethan Furman said:
I follow each (sub)thread through to it's end, as it keeps a logical flow, but Discourse has everything linear which means that as I read it the conversation keeps jumping around, making it hard to follow.
Warsaw agreed that the lack of threading is problematic, but that feature has fallen by the wayside in today's discussions:
[...] I definitely prefer threaded discussions. Unfortunately though, much like top posting <wink>, I think that horse is out of the barn, what with other forums like GitHub being linear.
As might be guessed, based on the "wink", Warsaw had top-posted his reply. Viktorin noted that he has just had to accept the linear nature of Discourse discussions; things have changed and there is likely no going back:
[...] if python-dev was used by everyone, rather than almost exclusively by people who prefer e-mail (and presumably use threading mail clients), we'd get mangled threading anyway from all the non-threaded clients.I mean, I could grumble about threading and bottom-posting and plain-text messages and IRC all day, but realistically, I'm not likely to convince anyone who's not into those things already.
That's where things stand at this point. It seems likely that a final
decision to switch away from python-dev will be coming soon and that the
venerable mailing list will be reconfigured sometime thereafter, "eventually switching to
auto-reject incoming messages with a pointer to discuss.python.org
".
That will be a sad day for some—and effectively a non-event for (many?)
others. For those of us who cut our teeth on threaded, text-only,
bottom-posted discussions, it is completely mind-boggling that Kids These
Days (tm) do not see the advantages of such ... discourse—but that
seems to be
the way of things.
| Index entries for this article | |
|---|---|
| Python | Development model |
Posted Jul 20, 2022 16:17 UTC (Wed)
by q3cpma (subscriber, #120859)
[Link] (25 responses)
Posted Jul 20, 2022 16:42 UTC (Wed)
by michaelkjohnson (subscriber, #41438)
[Link] (1 responses)
Posted Jul 21, 2022 2:07 UTC (Thu)
by orib (subscriber, #62051)
[Link]
Posted Jul 20, 2022 17:05 UTC (Wed)
by amacater (subscriber, #790)
[Link] (22 responses)
There is space for everything - but only insofar as it's not ephemeral.
Posted Jul 20, 2022 17:15 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
Posted Jul 20, 2022 17:53 UTC (Wed)
by amacater (subscriber, #790)
[Link] (7 responses)
IRC logs are good and useful as long as they're kept - and can also be grepped, of course.
Fora and discussion tools are significantly less long-lived: Slack/Mattermost/Matrix/Discord?? and that's not to think of various other services built on XMPP that were commercialised or have just vanished. Digital dark ages, anybody?
Anything unthreaded - Heaven forbid. And no, there are some other areas where HTML and top-posting haven't caught on - supercomputing and the Beowulf list remains one of my favourites for focus and technical excellence.
Posted Jul 20, 2022 19:06 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (6 responses)
This is an important point. Mailing list message and IRC logs are really easy for people to archive on their own workstations, and they don't take up a ton of space by modern disk drive standards. My workplace, for instance, uses Slack, but I use it via an IRC gateway that logs everything. If I want to search for something, it is significantly faster for me to grep the logs on my IRC gateway box than to use Slack's search feature. I can also look for regexes or even do more complicated searches by whipping up a script.
Posted Jul 20, 2022 20:19 UTC (Wed)
by mattdm (subscriber, #18)
[Link] (5 responses)
It wouldn't be terribly hard to build archiving tools meant to preserve conversations in a way that is useful offline and does not depend on the forum software itself.
Posted Jul 21, 2022 2:07 UTC (Thu)
by michaelkjohnson (subscriber, #41438)
[Link] (1 responses)
Discourse makes its content easily searchable; non-javascript users get a readable, full-text dump of all the content instead of dynamic scrolling, and that's the view that is presented to search engines and script-blocking users. It's fine!
When I ported lots of Google+ communities into a new Discourse instance, search engines found the content very quickly and gave relevant search results. Google's bot has a relatively light impact on site load compared to the other bots (although Bingbot has improved recently), while still indexing new content quickly.
Besides the ".json", just crawling with a non-browser User-Agent will produce the full, non-incremental-scrolling view, which makes it even easier to create an archive. The sitemap (just add sitemap.xml to the base forum URL for the complete sitemap) would be an easy place to start, other than XML being the standard for sitemap...
Posted Jul 21, 2022 12:58 UTC (Thu)
by dskoll (subscriber, #1630)
[Link]
OK, that's cool. I've never used Discourse, but it sounds like decent software.
Posted Jul 22, 2022 1:24 UTC (Fri)
by mm7323 (subscriber, #87386)
[Link]
Posted Jul 22, 2022 5:28 UTC (Fri)
by comex (subscriber, #71521)
[Link] (1 responses)
Discourse's mailing list mode is not perfect – the biggest issue is that it doesn't notify you when someone edits their post – but it's good enough for most purposes.
(I wish there was a standard for editable email, for Discourse and similar software to use. It could just consist of a header that means "this email is a revision to the email with such-and-such Message-ID". Email clients supporting the standard would default to showing only the latest version of each email, but would have an option to show old versions. Old clients would just see all the revisions as separate messages.)
Posted Jul 23, 2022 14:08 UTC (Sat)
by anton (subscriber, #25547)
[Link]
Posted Jul 20, 2022 17:18 UTC (Wed)
by smoogen (subscriber, #97)
[Link] (11 responses)
I think email has gone the way of punch cards, and we are going through the usual 'planned' obsolescence of the older Techie generation. I remember multiple long lectures about how punch cards made for better programming because you had to think about what you were going to write maybe days in advance. I also thought to myself, why in the world would I ever want to spend days redoing punch cards because I decided to rewrite a routine when I could just open a terminal and type it out. I like email, I find it useful for my way of thinking. I also think its current form has an expiration date printed on it with not-so-future retirement stamped on it.
Posted Jul 20, 2022 17:53 UTC (Wed)
by pizza (subscriber, #46)
[Link] (10 responses)
Until a new fully-federated alternative is widely deployed, I don't see that happening, because email _still_ backstops, well, everything out there because it's the only communication channel everyone can rely on being there.
And any upstart federated communication solution is going to have to deal with the same problems that has made email so 'horrible' -- inevitably requiring the equivalent of robust filtering tools, trustworthiness scores for senders, etc etc. Oh, and no advertising/engagement-driven algorithms deciding what you should or shouldn't see.
Posted Jul 20, 2022 19:49 UTC (Wed)
by smoogen (subscriber, #97)
[Link] (6 responses)
> Until a new fully-federated alternative is widely deployed, I don't see that happening, because email _still_ backstops, well, everything out there because it's the only communication channel everyone can rely on being there.
I used to buy into that but in the last 5 years I have seen most of our new accounts coming from or fronted by gmail.com and distant second microsoft.com. The long tail of email servers being run by sysadmins get eaten up constantly by 'lets just outsource this to ...' At a certain point, there is only an illusion of 'fully federated' with those of us trying to keep it going dieing off over time.
And yes any new replacement will have to deal with all the problems that SMTP has solved.. but I have also come to the conclusion that the human brain enjoys reinventing the wheel more than learning why the last wheel failed.
Nurse has come and told me its time for my apple sauce.. so I am going to yell at the kids on that side of the home's lawn now.
Posted Jul 20, 2022 20:33 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
You inadvertantly made a critical point -- with email, you actually can choose who/what hosts it, and at any time, suck your data out and switch over to someone else's solution [1] because ultimately it's tied to the domain, not the provider. [2] It's not entirely friction-free, but critically you don't need the cooperation of your existing provider.
Try that with pretty much any other would-be replacement.
[1] Unless you've been using Exchange. *shudder*
Posted Jul 20, 2022 20:43 UTC (Wed)
by notriddle (subscriber, #130608)
[Link] (1 responses)
It's not federated, but, honestly, I think domain-name-based federation is a half-assed approach to data portability anyway. Domain names are rented for a limited time, so keeping a mailing list (which is tied to a domain name) running requires a chain of custody for a centralized legal organization or individual person to pay that bill, which is not a good fit for ad-hoc open source communities made up of five people living in three different countries. Anyone that won't or can't set up their own domain name instead leases one on "someone else's land," and since the age of a mail service is a good predictor for how long it'll live, people pick already-established players because they hope the past predicts the future. This, of course, cements the dominance of already dominant players.
In other words, I don't see the point of accepting all the complexity and the inertia introduced by "federation" if you aren't going to federate identities. Or, better yet, go for real P2P.
Posted Jul 22, 2022 14:18 UTC (Fri)
by mattdm (subscriber, #18)
[Link]
Posted Jul 25, 2022 16:06 UTC (Mon)
by Avamander (guest, #152359)
[Link]
Getting email right is in reality really difficult. Subtle things can topple the entire stack, how many can afford that with a thing they really use? "Not entirely friction-free" is an understatement in this context. I'm not saying it's not possible, it absolutely is. But the unfortunate nuance here is that it has been *made* difficult. Just just like people find using e-mail archaic at times, hosting it is that times ten for no good reason.
I've heard "oh but it's because email is complex", but that phrasing I don't agree with. If we take one of the most basic things, TLS, we can really see the stark contrast. In the "web ecosystem" we've got multiple webservers with ACME clients built-in, in the email world there's one (maybe two) projects like that and they're not finished. Point being, now imagine a full mail server that can get its own TLS certificates, update its own DANE, MTA-STS, DKIM (ARC) or even A and SPF records. Totally doable, but there's a resistance or an attitude that hinders most improvements (QoL included).
One can feel this resistance well once you do become a mailop. There are large email providers (e.g. Deutsche Telekom) that intentionally doesn't publish a SPF record, wow what "fun" it is to filter spam from @t-online.de. It's just one example of the mindset, there are many more and it has gotten us the monstrosity that is e-mail at this point in time. It could be much better, I really wish it were, but unfortunately right now I can only see monopolistic megacorporations really pushing things further.
Posted Jul 25, 2022 9:54 UTC (Mon)
by misc (subscriber, #73730)
[Link] (1 responses)
But both are US companies. And there is some trend in Europe on avoiding those due to GDPR, such as https://tutanota.com/blog/posts/dutch-schools-must-stop-u... or https://usefathom.com/blog/6monthsjail . I doubt it is going to grow fast or much (as the force that push to outsource are here to stay), but I also doubt Google will be able to fully comply with GDPR because a lot depend on the US government and their own business model.
And from a purely political point of view, I think the war in Ukraine and the sanctions from USA (and Europe) showed to a lot of countries that you shouldn't count too much on external technologies, so the push to not use US based SaaS is here to stay. The trade war between USA and others countries is IMHO also fresh in people minds, and the Trump presidency reshaped perceptions of risk wrt USA for at least a few more years (assuming nothing egregious happen by 2024 on that front).
I think that's also renewing interests in initiatives such as https://www.ngi.eu/ and I guess similar across the world (all those headlines on China, India pushing for their own risc-v processor, etc)
Posted Jul 25, 2022 10:58 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
My employer is a UK multinational (linkedin if you want to know who :-) and although we use Google Mail, I suspect it's physically and legally located in the EU or Britain.
Certainly, BigQuery has both European and US data silos AND THE TWO CAN'T TALK TO EACH OTHER. Causes me some grief as the company is migrating its legacy silos (US-based) to European silos, and as my job involves using both datasets, it's not pleasant ... :-)
Cheers,
Posted Jul 23, 2022 18:21 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
Yes, things like Matrix and Mastodon exist. But in the Real World, everyone is on Discord, Slack, Facebook, and Twitter, and this is only going to get worse as the proprietary services add features and optimize for "engagement." The new federation apps will slowly wither and die like their forefathers, and then someone will invent some new ones and the cycle will repeat again.
I would really like to be wrong about this, but unfortunately this is what I think is going to happen to every federated app in the future. There's only room in the tech world for one federated protocol, and it's HTTP.
Posted Jul 24, 2022 0:51 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
No, take away email and the only remaining federated messaging protocol is bog-stock SMS. And maybe the postal system.
HTTP is just a dumb data transport with a completely non-standard namespace (and no inherent semantic meaning for anything built on top of it)
Posted Jul 24, 2022 6:44 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
Pardon me, by the "tech world" I actually meant "the internet."
> HTTP is just a dumb data transport with a completely non-standard namespace (and no inherent semantic meaning for anything built on top of it)
Which is the reason it has endured. It's so unopinionated that it's easier to simply bend it to your will than to try and replace it. See for example the browser makers deciding they wanted more stuff in HTML, and forming the WHATWG when the W3C didn't want to play ball. But once you have such a malleable protocol, why would you need a second one?
Posted Jul 20, 2022 21:17 UTC (Wed)
by iabervon (subscriber, #722)
[Link]
For that matter, it seems like it would be easy and wise to have the forum replicated on multiple sites running different hosting software by encoding messages using RFC822 style to transfer them.
Posted Jul 20, 2022 17:12 UTC (Wed)
by q_q_p_p (guest, #131113)
[Link] (1 responses)
Posted Jul 21, 2022 22:37 UTC (Thu)
by hodgestar (subscriber, #90918)
[Link]
Posted Jul 20, 2022 19:57 UTC (Wed)
by mattdm (subscriber, #18)
[Link]
It effectively means "subscribe me to ALL OF THE LISTS". In fact, individually subscribing to a particular category or tag* is more like subscribing to an individual list.
* this is a whole different discussion, but Fedora, we eventually decided to go category-light and focus on tags for organization, and, rather than arbitrary infinite tags, basically treat tags as if each is an individual team or subject mailing list conceptually.
Posted Jul 20, 2022 20:27 UTC (Wed)
by mattdm (subscriber, #18)
[Link] (2 responses)
In Discourse, each "topic" — the flat un-threaded thing that other forum software generally calls a "thread" actually _does_ keep track of replies, and handles quoting nicely. It just keeps the display in a chronological order. It also has the concept of relationships _between topics_, and you can reply to a post in a topic _as a new topic_. (And, moderators can select posts — including "this post and its replies" — and move them to a new topic.)
Having read, participated in, dealt with, and etc., many big long threaded discussions, for example, Fedora devel, I've gradually become convinced that while the threaded model feels organized and helpful, it is Actually Kind of Terrible in practice. It's easy to derail the whole thing, have multiple repeated conversations in different places, loop around, and end up with long branches that are just two people going back and forth. And sometimes those tangents (whether two people breaking something down, or entirely off-topic) are still valuable. Having them be linked topic is really better.
Posted Jul 21, 2022 14:07 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link] (1 responses)
Posted Jul 22, 2022 14:23 UTC (Fri)
by mattdm (subscriber, #18)
[Link]
Posted Jul 21, 2022 5:50 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
Posted Jul 21, 2022 8:11 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (73 responses)
That's really the wrong question. The real question is: why have Greg Beards (tm) so attached to email (resp. IRC) constantly and consistently dismissed its problems as not important and email as near perfect; just write a small procmail or patchwork script and "problem solved". Most people enjoy or at least don't mind threading and bottom-posting, however these advantages are not enough to outweigh email's issues. Email is not dying because people don't see its advantages, it's dying because they mind its drawbacks. You win by paying attention to your own flaws and working on them, not by obsessing about the competition's flaws. That's why email is dying: because its fans still try hard not to see what's wrong with it.
> with other forums like GitHub being linear.
Github _discussions_ (not issues) are threaded. The tab is not enabled by default, it's a project setting.
Posted Jul 21, 2022 9:21 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (57 responses)
Because what the youngsters forget is that change gets harder with age. I stick with email - it's what I learnt when I started out. And as I approach retirement age, I DON'T WANT to have to learn some new-fangled system that breaks my workflow, screws me over, and generally makes life a pain.
And with a disabled wife and elderly in-laws, I see this even more strongly in them - in fact so much so that you can change the words "I don't want to" to "I can't". And I seriously mean CAN'T, not "don't want to"!
Cheers,
Posted Jul 21, 2022 10:39 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (56 responses)
Posted Jul 21, 2022 11:52 UTC (Thu)
by mmirate (guest, #143985)
[Link] (45 responses)
... that's their problem.
Posted Jul 21, 2022 12:00 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
Getting to contribute to a free software project isn't a privilege. Having people contribute to your free software project is a privilege. If you fail to attract new contributors then that's very much not their problem, it's your problem.
Posted Jul 21, 2022 12:03 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jul 21, 2022 12:46 UTC (Thu)
by mmirate (guest, #143985)
[Link]
Posted Jul 21, 2022 14:11 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Eh, calling receiving contributions a privilege is a pretty major stretch.
A lack of 3rd-party contributors is pretty much entirely their problem, only they don't realize it yet.
Posted Jul 21, 2022 12:33 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (40 responses)
It's only their problem if they want to contribute to your project, but are put off by your antiquated communication methods.
It becomes your problem if you want their contributions (e.g. because the current contributor pool is ageing out naturally, or because you believe that your project solves a problem better than any new attempt to solve it could), but they're not willing to work with you.
So depends whether you want your project to outlive you or not; if it's OK for it to die with you, then it's their problem. If you want it to keep going long after you've become unable to operate a computer, you need to attract a new generation of contributors.
Basically, choose your consequences: do you want the project to keep going or die off when your generation can't contribute any more?
Posted Jul 21, 2022 14:12 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link] (35 responses)
Long-standing projects have changed version control systems (in many cases multiple times), changed toolchains, changed language standards, and lots of other major 'breaking' changes which required contributors to adapt to the new thing. I think it'd be quite rare to find a popular (large contributor community) project that has existed for more than ten years which is still using all of the same tools and workflows as when it started with zero changes.
Posted Jul 21, 2022 14:33 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (32 responses)
I suspect because the old guard are like me: they have complex scripts and customizations that mean that an e-mail workflow suits them just fine - they've adapted mutt, written procmail scripts, maybe even their own milters, to make e-mail smooth. If you insisted that the old guard started from scratch with e-mail, with none of their customizations and just a free webmail account, they'd find it every bit as challenging as the new guard do.
The difference is that when I started out, most online communication was via e-mail; sorting out a decent e-mail workflow for my personal life was essential to avoid having thousands of unread e-mails per day hit my inbox. Now, my personal life is almost entirely handled away from e-mail, via per-site notifications or apps, and e-mail (if used at all) just sends me an irregular prompt to check notifications if there's a site I've forgotten I use. And even better, GMail (at least) already has sort functionality that distinguishes those notification prompts from personal mail - so there's no need for me to learn how to write my own workflow rules for e-mail.
Posted Jul 28, 2022 15:03 UTC (Thu)
by Vipketsh (guest, #134480)
[Link] (31 responses)
You seem to take it for granted that one can reasonably customise the stream of ones incoming messages. With web-based fora no-one has any customisations because there it is an unreasonable amount of work to attempt anything and it risks breaking at the drop of hat.
For all it's flaws, the one great thing with e-mail is that one has a reasonable-ish way to munge it so ones pains with e-mail are smoothed over. With web-based fora ? There is not much option: don't like it, don't contribute.
> sorting out a decent [...] workflow for my personal life was essential
I would say the above is still true, but the way things are going either you put up with whatever workflow is presented or you go live a reclusive life in a cave. Sounds more like a step backward to me, but I'm not exactly part of the "new guard"...
Posted Jul 28, 2022 15:32 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (26 responses)
The difference is that most web-based fora I use already support the sorts of workflows I want; if they don't, I don't participate (and a project that needs me, or people like me, but that uses a bad web app does not get my contributions in any form).
E-mail's "bare" workflow is awful - one firehose of notifications, sorted by the time at which my receiving mail server got the mail. Nobody works directly with this and retains a useful level of sanity; everyone who uses e-mail seriously has built a workflow on top of this that works for them, with sorting, searching and filtering to remove junk, bring important things to the top of mind, and to move unimportant things off to one side for later handling.
The trouble is that outside of my open source work, I have literally no reason to build such a workflow atop e-mail any more; my notifications are sorted for me by the originating site, and I can apply a crude filter by simply not going to the "wrong" site; if I don't go to github.com, I don't see GitHub notifications. E-mail has been reduced to just a way to remind me to visit sites and pick up my notifications.
And this leads to trouble for e-mail based workflows. If I'm fully plugged into the current way of doing things, with different notifications on facebook.com, pinterest.com, github.com etc, and e-mail only set up to remind me which sites I haven't checked recently, moving to an e-mail based workflow requires a significant investment of time and effort. Worse, if I get involved but don't invest that time, my GMail (or whatever free mail provider I use) inbox fills with e-mail from lists and things that I simply don't care about - so I am forced to invest the time in making a suitable workflow if I want to contribute to a project that uses an e-mail based workflow.
This puts us in a difficult position; if you can get the newcomer to invest in sorting out an e-mail based workflow, then they will get value from this, because it's a workflow that's customized to their way of working. But because this is an up-front investment (before they're interested in working on your project), you're asking them to spend a lot of effort on "joining" the project when they may decide to leave shortly afterwards.
There are two routes to resolving this:
Both of these are perfectly reasonable choices; the one that's not going to work is insisting on an e-mail based workflow, and then getting upset that your contributor pool is limited to the people willing to set up an e-mail based workflow. There are a few projects that are big enough to do that (Linux kernel comes to mind), but the majority are not - and it is unreasonable to complain that people aren't coming to your project while also keeping a big barrier to entry in their way. Choose one - a big barrier to entry (e-mail based workflows), or an expectation that people will contribute to your project.
Posted Jul 28, 2022 16:02 UTC (Thu)
by Vipketsh (guest, #134480)
[Link]
So: Thank You!
Posted Jul 30, 2022 20:35 UTC (Sat)
by JanC_ (guest, #34940)
[Link] (24 responses)
Oh, and to work around the common flaws of all these sites they use… *drumroll* … email. So in the end you still depend on email.
Posted Jul 31, 2022 12:30 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (23 responses)
> So in the end you still depend on email.
Even if it were true, it would still better than a mailing list that forces you to receive all discussions on it and filter them somehow.
PS: I feel like I fed the troll.
Posted Jul 31, 2022 12:37 UTC (Sun)
by mmirate (guest, #143985)
[Link] (22 responses)
Quite ironic for the free-software community to rely on proprietary infrastructure like that. :(
Posted Jul 31, 2022 13:22 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (21 responses)
GitHub is proprietary. Gitlab CE (Community Edition) which is what a lot of the free software projects like say GNOME use isn't proprietary and is hosted in their own community infrastructure.
Posted Jul 31, 2022 14:47 UTC (Sun)
by pizza (subscriber, #46)
[Link] (20 responses)
Ah but you can't just do a "drive-by" contribution with the "community infrastructure" -- you'll still need to register for an account at minimum.
Posted Jul 31, 2022 14:49 UTC (Sun)
by mpr22 (subscriber, #60784)
[Link] (16 responses)
Posted Jul 31, 2022 15:04 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (15 responses)
Requiring me to create an account is pretty much guaranteed to make me walk away. I don't want loads of accounts everywhere. And what happens if I make a drive-by, and six months later want to make another, and have forgotten my account details? Unless, of course, I use the same account details for all of them ...
Cheers,
Posted Jul 31, 2022 18:18 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (8 responses)
Posted Jul 31, 2022 19:08 UTC (Sun)
by mmirate (guest, #143985)
[Link] (7 responses)
By the latter I don't just mean "newbs can understand it" I also mean "the time needed to log in, compared to memorizing and manually-typing the password, is similar or less" - inconvenient security measures become unused security measures.
Bitwarden is about as user-friendly as it gets, and it's about as close to trustworthy as it could possibly be for something that runs on other people's computers. So close yet so far.
Posted Aug 1, 2022 13:34 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
My passwords are 80+ characters (as long as it's accepted :/ ), so the password manager is faster :) .
> Bitwarden is about as user-friendly as it gets, and it's about as close to trustworthy as it could possibly be for something that runs on other people's computers.
I just have WebDAV access hooked up where needed for my keepass database. Works well enough for me. But I also know I'm not "everyone".
Posted Aug 1, 2022 16:33 UTC (Mon)
by kleptog (subscriber, #1183)
[Link] (5 responses)
Unless there's something else that disqualifies it for you?
Posted Aug 1, 2022 17:11 UTC (Mon)
by mmirate (guest, #143985)
[Link] (4 responses)
Posted Aug 1, 2022 18:16 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
This setup is surely not for everyone. I'm very happy with it, though.
Posted Aug 1, 2022 22:26 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
As for "ctrl+shift+a", that instead invokes a Firefox add-on instead of some desktop-global shortcut. It has enough information to be accurate about the website at least.
Posted Aug 2, 2022 1:31 UTC (Tue)
by edgewood (subscriber, #1123)
[Link]
Posted Aug 4, 2022 8:41 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
Posted Aug 1, 2022 14:04 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Which must be why mailing lists chose to ignore it.
Posted Aug 2, 2022 20:30 UTC (Tue)
by bartoc (guest, #124262)
[Link] (4 responses)
Now, it's fair to say that this is because Exchange and Outlook are broken email clients that are unsuitable for doing any real kind of communication, but that doesn't really help, fixing it usually means allowing non-outlooks clients that lack some security features ("insufficient" spam filter, no platform attestation, etc), and that becomes such a hard sell that it's not worth it for all but the most important projects (like linux itself). It's a sorry state of affairs, to be honest.
Judging from the recent linux foundation effort to provide such email accounts for people in my situation I doubt my situation is unique.
Posted Aug 2, 2022 23:14 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (3 responses)
So email is fragmented too and the otherwise supersmart and highly respected people who buried their head in the sand and kept claiming email is perfect are partly responsible for that sad state of affairs.
Posted Aug 3, 2022 0:55 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
That's not fair; it's more accurate to say that the rest of the world moved on/away, perpetually chasing after the latest shiny.
No matter how "supersmart" someone is, email is a _service_ and that costs money to provide. Free webmail pretty much killed the ability to charge for non-corporate email (with the final blow delivered by still-don't-be-evil Google) which also destroyed the ability to meaningfully advance the protocol stack -- it didn't help that the 800lb gorilla (ie Microsoft/Outlook) was actively crapping all over the place.
So instead, email is being replaced with a hundred different purpose-specific silos, each trying to monopolize their users' attention, mostly paid for through advertising/datamining -- which further reinforces this balkanization as the focus becomes growth for growth's sake, which requires user lock-in. Dropbox is a really good example of this, but so is instant messaging.
Until non-greybeards actually start caring about truly owning their own data, nothing will change -- because again, we're competing with "free".
Posted Aug 3, 2022 8:43 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (1 responses)
> That's not fair; it's more accurate to say that the rest of the world moved on/away, perpetually chasing after the latest shiny.
I wrote "partly" - you gave a great summary of the rest. The open-source community can and has been pioneering amazing things without much business support but this required great leadership. It does not happen when leaders claim that everything is fine, there is no problem and nothing to fix.
For instance I'm amazed at how little publicity gname.org ever got. It was an amazing service that you could only discover... by chance. I'm not saying it was the answer to all email problems but it was at least successfully solving a number of them.
Posted Aug 3, 2022 10:23 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
We need to think outside the box and - rather than some micropayment system - see if we can come up with a "you scratch my itch, I'll scratch yours" system. Like the Linux Foundation. Like some sort of trade association.
Where small groups can come together and seriously push the Open Source "many eyes" and fast response advantages.
The problem is getting enough people to buy in at the start to get it off the ground.
Cheers,
Posted Jul 31, 2022 15:13 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
It takes like two seconds (I know because I just did it right now) to "register an account" in say, https://gitlab.gnome.org/ because it allows you to reuse among other things accounts you may have in github/gitlab.com. So I don't find this a barrier to entry for drive by contributors.
Posted Aug 4, 2022 8:43 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (1 responses)
Fortunately these days the only ones that are left outstanding are large enough that they'll probably be around forever.
Posted Aug 4, 2022 13:13 UTC (Thu)
by gioele (subscriber, #61675)
[Link]
> Fortunately these days the only ones that are left outstanding are large enough that they'll probably be around forever.
The question is rather, how long will the identity provider keep your account around.
Posted Jul 29, 2022 20:20 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
This is of course highly depending on the tool but generally wrong with the decent ones.
Quoting your other comment at https://lwn.net/Articles/902832/
Yes, this is it, you got it. This is exactly the "customization" feature, it's not a bug: in just a few clicks you can subscribe to only the specific threads that you're interested in and ignore all the rest of the project activity. Or choose to be notified of everything, it's all up to you. Adjusts to both drive-by contributors and maintainers, no need to be either "in" or "out" of the mailing list. I don't understand why so many email fans scripting their way out of a today's firehoses of information overload fail to see why many people love this.
Of course one of the notifications possibilities is... email (there are others). Hardcore email fans keep talking about "web-based tools" like it's a thing but the web is just a user interface, it's not the tool. Granted it's the main and most common and most developed interface but unlike email it's still just an interface. For instance some people interact with Githab directly from their editor on a routine basis.
Funny enough if you feel to limited by Githab's default filtering options then you can simply request to be notified of everything by.... email and then fall back into some customizable-to-death workflow.
The fact that email fans with computer science degrees can't seem to make the difference between the data versus the notifications (because email does not) even when they look at alternatives shows how detached from the rest of the world they've become.
Posted Aug 1, 2022 17:15 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
As a coincidence I was just made aware of this: https://github.com/wandersoncferreira/code-review (Github code reviews from Emacs).
So yes: the web is of course the most common and best supported interface (not just for software development) but unlike email the web is not a hard requirement of all the misnamed "web-based tools".
This level of "forge ignorance" can be depressing. I know some vim users who write kernel code without having ever tried fugitive or anything like it so there is clearly a long way to go.
Wake up and smell the coffee.
Posted Aug 1, 2022 18:25 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (1 responses)
One thing that "web-based" tools often get right (not always, but often enough to be useful) is to be split into a backend API and a HTML + CSS + JS frontend. You can thus easily build tools like the one you linked that talk directly to the backend API, bypassing the web front end completely.
This is something that's far harder to build with e-mail, since e-mail is fundamentally designed to send messages between humans, where HTTP is designed for machines to talk to each other.
Posted Aug 1, 2022 22:25 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 21, 2022 22:41 UTC (Thu)
by hodgestar (subscriber, #90918)
[Link] (1 responses)
Posted Jul 26, 2022 2:32 UTC (Tue)
by plugwash (subscriber, #29694)
[Link]
With mailing lists I can reply to a mail and loop in other people or groups. Even if those people or groups belong to different organisations. If i'm discussing an issue in a Debian context and I feel it could use input from upstream I can simply forward the mail CC them and then upstream can participate in the discussion like anyone else.
But increasingly there is no upstream mailing list to post to, so the only options are to either forward to specific individuals (often righly seen as rude) or learn to use whatever discussion service upstream uses. Having done so one is likely to have to manually proxy information back and forth between upstream and downstream.
Posted Jul 21, 2022 14:22 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
That's ultimately up to the new generation.
I've received *one* non-trivial contribution in the past fifteen years.
Any new workflow has to yield benefits for the _current_ contributors, not mythical unicorn developers that will probably never materialize.
Because the hard truth is that there are _not_ hordes of skilled-and-willing developers out there who would _love_ to contribute to my projects, but are turned off by using email instead of whatsapp or FB messenger.
Posted Jul 21, 2022 16:13 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
And your attitude as expressed here is perfectly reasonable; if you don't mind the "new guard" bypassing your project entirely and doing their own thing in the same space, that's great.
But it is unreasonable to simultaneously complain that people are working on a new thing in the same space as your thing, and also refuse to change the way you work to make working on your thing attractive to people who work on the new thing. Make your choice: do you want to minimise change for existing contributors, and accept that future contributors (if any) might instead start a fork or new thing, or do you want to adopt changes that increase the chance of future contributors and risk losing existing contributors?
Both of those are reasonable choices to make - it sounds like you've chosen to risk losing future contributors to a fork or a new thing instead of changing workflow, and that is absolutely A-OK; however, you then can't complain that the new generation aren't interested in working with you when they do their own thing (and I can find no evidence that you've complained about the new generation not supporting your project, which implies that you're making reasonable choices).
Posted Jul 25, 2022 6:52 UTC (Mon)
by johannbg (guest, #65743)
[Link] (1 responses)
Which may or may not be directly relate to the type of project which begs the question which project would that be?
In the end of the day it all boils down to contributors doing CBA's.
> Any new workflow has to yield benefits for the _current_ contributors, not mythical unicorn developers that will probably never materialize.
Right you always want to cater to the core volunteers.
Posted Jul 25, 2022 13:32 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Oh, it's absolutely due to the type of project -- it started out as reverse-engineering a family of dye-sublimation photo printers so they could be useful without a Windows PC, and was eventually mostly subsumed into gutenprint, which itself has only four semi-active contributors over the past decade, and a nearly entirely technically clueless userbase.
Meaningfully contributing requires a pretty niche set of skills, or at least a lot of motivation. Oddly enough, said technically clueless userbase (mostly on MacOS, FWIW) manages to ask for help just fine using the email or discussion forums we (==sourceforge) provide. We provided github/gitlab mirrors and to date there's been *one* public fork. There simply aren't folks interested in contributing, via _any_ means.
The other project I'm actively involved with is also hardware-centric, and that requires even more niche skills with an even steeper learning curve to contribute meaningfully. Most of the userbase is also technically clueless, but even those that are motivated enough to try an contribute find the realities of hard-realtime memory-constrained bare-metal programming on hardware that mostly lacks specifications (and a "core" codebase of several hundred thousand LOC) too much to wrap their heads around.
Posted Jul 21, 2022 12:02 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Maybe. And I take your point entirely - I do try and drive change forward, BUT. I *always* *try* to make sure old and new can run in parallel. Otherwise, if the stewardship changes, you run the risk of the young bloods being the lunatics running the madhouse ... When llvm moved to discourse, I didn't bother to move with it. Is there any way you can communicate with discourse as if it were a mailing list? I don't remember being pointed at anything like that ...
Two personal experiences which show clearly the problems with running with the new and/or not running with it ...
My wife is an ex-Guider. Recently Girlguiding UK went very much "all admin is on-line, all the girls' progress must be tracked on-line, blah blah blah". I don't know how many new rainbows, brownies and guides it attracted - probably very few. What it DID achieve - in an organisation with not enough volunteers - was to ensure that pretty much all the over-50 leaders just walked out ...
We're heavily involved (as volunteers) with Parkinsons UK. We're also desperate to hand over our roles to a younger generation. But yet again, a lot of changes - computerised changes - are making our life more difficult. (The main problem is an octogenarian losing her marbles, but head office don't help ...) Given that so many of the people we (try to) help can't even cope with smart-phones, let alone anything fancier, head-office running headlong into change really doesn't do anybody any favours.
And I'm well aware that a lot of this is being driven by legal requirements, but when you start telling your volunteers what to do, and you get push back saying it's difficult or impossible, it's NOT wise to push ahead regardless. And for the most part, European law is very tolerant of people who do their best.
Cheers,
Posted Jul 21, 2022 13:59 UTC (Thu)
by pizza (subscriber, #46)
[Link] (8 responses)
Personally, I find the "I demand *you* perform additional work for *me*" attitude rather off-putting, especially as I've grown older and have learned to recognize it as an invariable sign of abusive and toxic relationships.
Posted Jul 21, 2022 14:16 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (7 responses)
No - it's more nuanced. If the old guard want the new guard to join their project, rather than starting a new one in the same space or ignoring the problem completely, then the old guard need to make their project attractive to the new guard.
If the old guard don't do that, and then demand that the new guard work on their project rather than starting a new project in the same space, or forking the old project and changing communication methods etc, they are demanding that the new guard do additional work for the old guard. And it's then no surprise to an outside observer that firstly the new guard go off and do their own thing instead of working on the old guards' projects, and secondly that institutional knowledge held by the old guard is lost, because they've driven off the very people who might learn from them.
Posted Jul 21, 2022 14:26 UTC (Thu)
by pizza (subscriber, #46)
[Link] (6 responses)
"attractive" meaning something more than "something I consider important / useful and I'd be put in a hard spot should it go away" ?
Otherwise you're basically saying that oranges would be more popular with folks that like bananas if they'd only change themselves into bananas first.
Posted Jul 21, 2022 15:04 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (5 responses)
Attractive meaning "the new guard want to contribute to the existing project, rather than forking it or starting a new project to solve the same problem".
If the new guard's reaction to the old project being at risk of going away is to start their own thing, that's cool - but the old guard can't both complain that people are starting new projects in "their" space, and refuse to make the existing projects attractive to new guard contributors.
It's the combination of "I will not change my project to attract your contributions, but I will expect you to contribute to my project rather than start your own or go to a competing project" that's not OK. You have a choice:
Both of those choices are reasonable positions, and you may even prefer it if the new guard bypass you and build their own thing instead of contributing to your thing. Just be aware that if you're saying "we are firmly oranges here", you can't then demand that people who like bananas choose oranges instead to suit your desires.
Posted Jul 21, 2022 15:15 UTC (Thu)
by pizza (subscriber, #46)
[Link] (4 responses)
How often does this actually happen, though? (Especially in a way where both old/new continue on in competition instead of one rapidly dying?)
What I see all the time is "competing" projects being driven by fundamentals such as the chosen license or implementation language.
Posted Jul 21, 2022 15:29 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (3 responses)
See the complaints about uutils in https://lwn.net/Articles/857599/ for an example; there was also similar complaining about busybox in the past, since it distracted people from making the GNU utilities smaller.
Or the complaints about the "new guard" working on Wayland instead of X11.
There's plenty of people willing to complain about other people's use of time :-(
Posted Jul 21, 2022 15:51 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
The quotes make me think you're aware of this…but I thought that the Wayland developers *are* (heavily overlapped with) the X11 developers.
Posted Jul 21, 2022 16:25 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (1 responses)
Indeed, which makes the complaints about people choosing to work on Wayland instead of X11 even less reasonable - in many senses, Wayland is X12, dumping the bits that need a complete redesign in the modern era of GPUs, and trying to get the core right.
Posted Jul 21, 2022 17:47 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
But yes, for many years X11 was effectively one developer, who has thrown his weight behind Wayland, and I think X11 long ago went into security maintenance cum Wayland compatibility mode.
Cheers,
Posted Jul 21, 2022 13:24 UTC (Thu)
by cstanhop (subscriber, #4740)
[Link] (10 responses)
There's also the fact that most people are probably using email through a web interface or an IMAP client on their phone where most of the advantages of email that people talk about simply don't exist.
I'm a fan of the advantages of email, but if your experience of email is worse than a Discourse site, I can see why people are moving away from email.
(I'd discuss who I'd blame, but there's very little point.)
Posted Jul 23, 2022 6:41 UTC (Sat)
by gnu_lorien (subscriber, #44036)
[Link] (2 responses)
This is the pervading thought for me when I'm reading these conversations. Nobody ever ported any of the advantages of email over to new form factors. I love threading and threaded UIs, but I haven't seen one that looks good on my phone. None of the email clients on my phone can properly render patch text from plain text emails.
I really am sad by some of what has been lost on the "new internet" and in the new way of building UIs. In many cases they're genuinely not as well-featured and less accessible. At the same time, nobody really took the time to port those features into modern systems and form factors. I know that Alan Kay was sad that Steve Jobs dropped the stylus from his touch designs, but he did, so we have to design for fat-fingers and not just for fast two-handed typists if you we want a paradigm to matter for the ubiquitous devices of the day.
Posted Jul 25, 2022 3:15 UTC (Mon)
by intelfx (subscriber, #130118)
[Link]
Big surprise, because there's a lot more fat fingers than fast two-handed typists in the world.
If you want ubiquitous, you gotta design for what's ubiquitous.
Posted Jul 30, 2022 20:57 UTC (Sat)
by JanC_ (guest, #34940)
[Link]
Posted Jul 23, 2022 13:49 UTC (Sat)
by rjones (subscriber, #159862)
[Link] (6 responses)
That throughout the decades nobody has really come up with a simple, widely accepted, and effective way to verify users, senders, and verify the contents of emails. Spam companies make millions from mitigating the spam problem rather then fixing it. Google and other indexers Web-UI providers make even more based on fact that few people are really interested or able to deal with email themselves, even as businesses.
And that open source projects for email services and clients ground to a pretty much a halt around the same time that Gmail started offering 1Gb of storage.
I have always hated email for these reasons and more. And while I understand that many people have spent weeks carefully crafting their own personal setup years ago and haven't touched it since... there is very little tolerance for that sort of thing among people today. And for good reason.
This is why the alternative for discourse isn't email. It's software like facebook groups, github, and discord.
When examined in that light it is pretty obvious that discourse is the plain superior option.
If Python is successful then this should provide a template for other projects and groups to follow to hopefully claw and drag our way out of the abyss that is proprietary walled gardens.
Posted Jul 23, 2022 15:19 UTC (Sat)
by pizza (subscriber, #46)
[Link] (5 responses)
Except for the whole "every silo has to be independently polled, with an independent client that makes automation very difficult (if not outright impossible), making it impossible to scale" problem. Because its in the interest of each of those silos to make everything happen inside said silos, so users can be mined and monetized and "engaged" all way into the sewer.
Sure, the "new way" has made a much lower barrier to entry for the masses (and that's genuinely good!) but no matter how useful a ladder is for getting to the roof of your two-storey house, it's just not going to work for getting to the top of a 40-floor building!
At the end of a day, email is not even a service, but a "protocol" -- but most people only see it as an "app".
</garumph>
Posted Jul 23, 2022 17:04 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
I think Linus Torvalds once answered in some interview "I actually don't really care what Windows does, it's not that interesting". Of course that's too extreme because you do want to "steal" good ideas from your competition, (as opposed to ranting about how it sucks), and this is what open-source has been doing since forever - except for email. However that sentence makes a good point: focus on the engineering of _your_ "product"; on what you want to win.
There's a strange emotional attachment that develops when you start mastering a complex tool. In a former life I wrote git scripts to help me backport thousands of patches. That and others things cause me to regularly marvel at git's power and flexibility. Fortunately, I'm brought back down to earth every time someone new to git tries to do something simple and asks me for help. If you never get back down to earth then you get complacent: "what email problems?"
"Simple things should be simple, complex things should be possible."
We've all seen people in these discussions saying things like "Good, email keeps noobs away from the Linux kernel". This is both sad and funny (and fortunately rare). This is funny because it is almost admitting that there are some problems but no wait, these are not problems they're actually a test! It's by design! Hilarious.
Asking "noobs" to pass an "email test" instead of a coding test so they are immediately ready to deal with the high volume of spam and noob contributions that streched maintainers must be able to filter with when... using email? OK, I can see a little bit of recursive logic here :-)
Posted Jul 24, 2022 0:45 UTC (Sun)
by pizza (subscriber, #46)
[Link] (3 responses)
Is it so strange? Literally every field of human endeavour has a notion of "expertise" that is usually celebrated [1], and part of that mastery is learning to effectively utilize the tools of that field.
What makes this field so special that what's "good enough" for novices is expected (nay, demanded) to be enough for everyone else as well?
Information management and effective communication are more strategic than ever these days. But instead, we're intentionally crippling ourselves (and handing our entire digital identities over to $bigcorp [2]) because we can't be bothered.
[1] modern politics notwithstanding
Posted Jul 24, 2022 17:30 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
Not 100% sure what particular solution you're referring to but good tools should always make "simple things simple and complex things possible".
The fact is that most people find it very convenient[*] to submit a one-line, typo fix on Githab and then walk away but very time-consuming when the code review requires finding and configuring properly an email client that supports plain text, bottom-posting and what not. These requirements are dying much faster than what's left of email.
[*] and yes that convenience comes at a price, we know.
> But instead, we're intentionally crippling ourselves (and handing our entire digital identities over to $bigcorp [2]) because we can't be bothered
Yes, we know. We've read that a million times. And some. Yet another change of subject.
What alternative to $bigcorp have you contributed to? Did you help understand why email is dying or even help fix it? Have you explored or contributed to any new alternative, can you recommend any?
I did absolutely nothing to help fix this particular problem but I'm not complaining that people are too stupid to leave email (a.k.a. "blame the user") in every discussion either.
People who complain that Windows is evil (tm) generally contribute to Linux or some alternative. What makes email so special that most people who keep complaining about its competition do absolutely nothing to fix it, not even acknowledging the reasons why it's dying and keep claiming that people are just too stupid to see how good it is?
Posted Jul 25, 2022 3:46 UTC (Mon)
by pizza (subscriber, #46)
[Link]
I don't actually have an inherent problem with $bigcorp providing services; what I take issue with is intentional lock-in that tends to come along with it. And nothing locks you in like using $bigcorp's identity services tied to a domain you don't control.
But you are right, the battle has been over for two decades. Google giving away a gig of storage for free was the beginning of the end.
You can't compete with services by providing software. And when you're providing a service, you can't compete with free unless you have some other way of making money -- such as selling (indirect) access to the data you've mined. which in turn is only possible if you're operating at a sufficiently massive scale to where micropennies finally pile up.
And as I mentioned earlier, most folks don't see anything beyond the "app" -- I'm not asked for my email address; instead I'm asked 'gimme your gmail' or something like that.
(What do I do? I'm self-hosting, and made minor contributions to various federated systems. I advocate the importance of owning your own digital identity, and that starts with domain names. And that's about all I can do, because at the end of the day, you're still in competition with "free")
Posted Jul 25, 2022 6:13 UTC (Mon)
by interalia (subscriber, #26615)
[Link]
I say this as someone equally guilty of this kind of feeling sometimes... if I had to climb the stairs to the top to master it, everyone else should have to do the same. If newcomers can just take the escalator instead of the stairs, that effort I put in was just superfluous and I don't get to feel as proud of it.
We all know email is a terrible medium. I haven't tried things like Discourse, I don't read any mailing lists or contribute much to OSS nowadays. But the centre of gravity has moved, and just as when I started I had to join mailing lists, now you have to join something else. It's still the same bazaar, with a different entry path.
Posted Jul 22, 2022 7:27 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Wait, there's at least one guy actually trying to do something:
https://lars.ingebrigtsen.no/2020/01/06/whatever-happened...
On his "spare time" when has any.
Amazing results (when it's not down) considering it's a single-handed effort but never heard of anyone else. Everyone else seems to be just whining about the email competition: "single point of failure", "closed-source", "incompatible", "lost privacy", "slow and bloated", "no threading", "customer lock-in", "evil BigTech",... Mostly correct and valid but neither fixing email nor offering vague idea of any solution or alternative.
There's seems to be more people trying to fix IRC: https://bnc4free.com/?page_id=26 https://quassel-irc.org/about
> why have Greg Beards (tm)
I _swear_ that typo was unintentional.
Posted Jul 25, 2022 12:58 UTC (Mon)
by smoogen (subscriber, #97)
[Link]
I will try to give a possible answer to your question about why have Greybeards tend to try and pick apart the problems of the replacement tools versus fixing the underlying tool.
1. There is a lot of 'I have spent a lot of time building my own infrastructure to deal with this crap' so there is the mastery item you have brought up later.
So instead, it is easier to go find one or two lines in someone pointing out problems and then disect those to show all the logical fallacies and prove to ourselves it isn't worth spending time on. [Basically the brain has a lot of feedback loops to make this the preferred action as we age.. we are trying to maintain a safe environment we know while fixing things or moving to a different environment trigger all this fear and anger.]
Posted Jul 28, 2022 15:20 UTC (Thu)
by Vipketsh (guest, #134480)
[Link] (1 responses)
Maybe one should ask "why are Grey Beards so attached to having discourse ?".
I sometimes wonder if the youngsters crawling github and such are even interested in have any discussions at all ? My experience browsing github is that most projects there have exactly no advertised discussion fora. Not github discussions, no mailing list, nor anything else. The only things available are 'issues' (oft abused by users as discussion only to be told 'go away' after a while) and 'pull requests'. Ofcourse this is all anecdotal, but still says something.
Posted Jul 29, 2022 20:20 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Posted Jul 21, 2022 17:25 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link] (1 responses)
I want my Pipermail back (plus reporting of Message-ID headers in the archive, like many patched locally, and ideally mbox downloads, ideally also of individual messages).
Posted Jul 22, 2022 2:49 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Jul 22, 2022 12:24 UTC (Fri)
by ceplm (subscriber, #41334)
[Link]
Leaving python-dev behind
Civility
Civility
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Disadvantage of modern forum/chat software
Disadvantage of modern forum/chat software
Discourse discoverability and archivability
Discourse discoverability and archivability
Disadvantage of modern forum/chat software
Disadvantage of modern forum/chat software
Disadvantage of modern forum/chat software
(I wish there was a standard for editable email, for Discourse and similar software to use. It could just consist of a header that means "this email is a revision to the email with such-and-such Message-ID".
For Usenet there is "Supersedes: <old-message-id>". However, AFAIK NNTP servers honoring Supersedes: don't give the old message to the user, and I am not aware of NNTP clients having a functionality like you desire.
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
[2] As long as you own your own domain. Which any organization that matters will.
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
> microsoft.com
Leaving python-dev behind
Wol
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
A note on "mailing list mode"
On threading...
On threading...
On threading...
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Wol
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Wol
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Wol
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
I also use Syncthing, but unlike the other poster, do get sync conflicts. But the Keepass db format keeps track of modification times for each record, such that "Merge another database" has never lost information for me. I can make changes with abandon on my Android phone and tablet and multiple desktops, knowing that worst case I'll need to merge.
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Wol
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
> I sometimes wonder if the youngsters crawling github and such are even interested in have any discussions at all ? My experience browsing github is that most projects there have exactly no advertised discussion fora. Not github discussions, no mailing list, nor anything else. The only things available are 'issues' (oft abused by users as discussion only to be told 'go away' after a while) and 'pull requests'. Of course this is all anecdotal, but still says something.
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
As to what that is for individuals, people can only speculate since it differs from person to person.
Leaving python-dev behind
Leaving python-dev behind
Wol
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Wol
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
> When examined in that light it is pretty obvious that discourse is the plain superior option.
Leaving python-dev behind
Leaving python-dev behind
[2] whose ToS says they can drop you at any time for any reason, with zero recourse
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
Leaving python-dev behind
2. We have all lived long enough to know that if we 'fix' this tool, it will break a LOT of other people who will yell at us for doing so. Our infrastructure will break for 'no reason'. Tons of people we know will also have to deal with the breakage. Better to just let sleeping rabid dogs lie.
3. This one hits me a lot when I finally start to fix something. 'Why is it so important to fix now? why didn't you fix it before?' Sure it takes all these workarounds to make it 'work' but those are just cost of doing business.
Leaving python-dev behind
Leaving python-dev behind
Accessibility concerns
Accessibility concerns
Leaving python-dev behind