A farewell to email
Email is certainly not without its problems. For many of us, plowing through the daily email stream is an ongoing chore. Development lists like linux-kernel can easily exceed 1,000 messages per day; it is thus unsurprising that the number of kernel developers who actually follow such lists has been dropping over time. Email is based on a trust model from a simpler time; now it is overwhelmed by spam, trolls, sock puppets, and more. Dealing with the spam problem alone is a constant headache for mailing-list administrators. Interacting productively via email requires acquiring a set of habits and disciplines that many find counterintuitive and tiresome. Your editor's offspring see email as something to use to communicate with their grandparents, and not much more.
It is thus not surprising that some projects are thinking about alternative ways of communicating. Even projects like the kernel, which remains resolutely tied to email, are seeing some experimentation around the edges. Some, though, are diving in more seriously, with a couple of recent experiments being found in the Fedora and Python projects.
On the Fedora side, project leader Matthew Miller recently proposed
moving the council-discuss list to Fedora's Discourse
instance. The idea was proposed as a sort of trial, with the hope that
it can "
She also added that mailing lists provide no control over where messages
are kept and are impossible to delete material from — attributes that
others will, instead, see as being an advantage of email.
Meanwhile, a significant part of the Python community was surprised at the
end of September when Łukasz Langa posted a missive titled python-committers is dead, long live
discuss.python.org. It stated that "
This move was not a welcome surprise to everybody involved; some thought
that the timing — while the project is trying to conclude a fundamental discussion on its leadership
model — was not ideal, and that the new system was being imposed on the
community without discussion. The result is that the conversation split, with
some posters moving over to Discourse and others remaining on the list.
Here, too, there has been discussion of the advantages and disadvantages of
each mode of communication.
Proponents of email value the ability to choose their own tools and
workflows; many of us who deal with large amounts of email have come up
with highly optimized setups that allow this work to be done efficiently.
Email can often be processed with scripts, and the ability to maintain
local archives can be highly useful. Mailing lists sometimes offer other
mechanisms, such as NNTP access, that facilitate quick reading. Many
people also appreciate the simple fact that email comes to the reader
rather than having to be explicitly looked for on a discussion site; as
Máirín Duffy commented
in the Fedora discussion:
For that and other reasons, she worried that a switch to a system like
Discourse could make bringing in new contributors harder rather than
easier.
Proponents of a switch note (though not in so many words) that the
indicated dopamine
hits have been thoughtfully provided: there are various
email notification mechanisms for new topics and such, and users by default
get handy notifications every time somebody "likes" one of their posts.
The mobile app makes engagement from handsets easier. There is a graduated
trust model that allows proven community members to take on some of the
moderation task, taking the load off of list administrators and community
managers; Python developer Brett Cannon looks
forward to having such features available:
He concluded by suggesting that the project has "
In both the Fedora and Python cases, the move to Discourse has been put
forward as an experiment that may or may not be rolled back, but going back
can be hard. Neal Gompa suggested
that OpenMandriva's shift to Discourse was "
Regardless of how these specific experiments work out, one conclusion is
clear. Even the people who are most tied to email are finding it
increasingly unworkable in the world we have grown into. Administering
an email installation while blocking spam and ensuring that one's emails
actually get delivered is getting harder; fewer people and organizations
want to take it on. As a result, our formerly decentralized email system
is becoming more centralized at a tiny number of email providers. If
"email" means "Gmail", it starts to lose its advantage over other
centralized sites.
As others have often said, what we need is a modern replacement for email —
some sort of decentralized solution that preserves the advantages of email
while being suitable to the 2018 Internet and attractive to our children.
Various projects have been working in this area for years, and some,
like Mastodon, appear to be
gaining some traction. But none have made any real progress toward
replacing email as a large-scale collaboration mechanism.
Your editor's free-software experience began by installing software and
applying patches received via email over Usenet. In the far-too-many
intervening years, some things have changed significantly, but the primacy
of email for development discussions remains unchallenged for many
projects. But the writing is on the wall; many mailing lists have already
gone dark as patch discussions have moved to centralized hosting systems,
and other types of conversation are starting to shift to systems like
Discourse. These systems may not be everything that we could hope for, and
they are likely to significantly slow down work for many of us. But they
also represent important experiments that will, with luck, lead to better
communications in the future. Email is not dead, but neither is FTP; soon
we may look at them both in about the same way.help increase engagement' in council discussions. Sanja
Bonic added
some reasons for why one might expect that to happen:
we have reached the limits
of what is possible with mailing lists
" and fingered email as
contributing to some of the project's community-management problems. He
pitched the advantages of Python's Discourse instance,
including the mobile application, community moderation, the ability to move
discussions between categories, rich media support, code syntax
highlighting, dynamic notifications, social login support, and
"emojis
". The email asked all members of the
python-committers list to cease using it immediately and start talking on
Discourse instead.
simply gotten too big
for email
".
largely a failure
"
when it comes to developer discussions (it worked better for user support),
but the project still has not gone back to using a mailing list for those
discussions. Moving a project to a new communication medium is hard;
declaring defeat and moving back can be even harder, especially since
people will have become attached to the numerous aspects of the new system
that do actually work better.
Posted Oct 16, 2018 23:51 UTC (Tue)
by mtaht (subscriber, #11087)
[Link] (28 responses)
No web browser based tool lets me search my mail locally.
Email used to get pushed to you, asynchronously, and then you could read (at 0 latency) everything you liked... but that was when we had real ipv4 addresses and better control over our dns spaces.
And yet, I do, also feel its demise pending unless "something is done". I beat most of the spam problem by switching my mail servers over to ipv6 only, which only cost me 13% of my correspondents at the time.
But that cost those correspondents and gradually more and more of my email traffic moved to the site (gmail) that just worked than my own personal email server. (which I still maintain).
Furthermore, post-gmane going down, my mailing lists are seemingly not as well indexed as websites are, so finding something that happened "out there" is easier on reddit than https://lists.bufferbloat.net.
And I agree on the gen-gap thing. But this year, it's whatsapp, a few years ago, facebook. I can't find anything I wrote on facebook, nor remember my password for whatsapp.
And then there is correspondence that is genuinely personal that I really only want copies of for the two of us.
lkml used to be indexed usefully too, I had a standard query to "follow" those that I liked to read...
Netnews and email were the bedrock that held the internet together, and today's conversation is so terribly fragmented. And if we could only host more services in the home or office easily then the latency goes down... I started fiddling with my own pod for diaspora and the latency and usability difference was remarkable - just like netnews used to be!
but running yet another server at home... or on my laptop... even if it "just worked" over ipv6... oy... I'm getting old.
Posted Oct 17, 2018 2:00 UTC (Wed)
by mtaht (subscriber, #11087)
[Link] (7 responses)
Get your own certs...
# I started requiring starttls on inbound 5 years back (it is my personal email server after all. Most people would use may, here, and cope with the spam. I couldn't.
smtpd_use_tls=yes
If it wasn't for vger not doing starttls (STILL), and needing to install a policy map for the 13% of my correspondents that didn't have it on 5 years ago (3 lines above MAY, that's it, gawd),
Posted Oct 17, 2018 14:40 UTC (Wed)
by bferrell (subscriber, #624)
[Link] (6 responses)
But it's no silver bullet.
Posted Oct 17, 2018 17:02 UTC (Wed)
by k8to (guest, #15413)
[Link] (4 responses)
Posted Oct 17, 2018 18:07 UTC (Wed)
by bferrell (subscriber, #624)
[Link]
Posted Oct 17, 2018 18:09 UTC (Wed)
by bferrell (subscriber, #624)
[Link]
Posted Oct 17, 2018 18:39 UTC (Wed)
by bferrell (subscriber, #624)
[Link] (1 responses)
Posted Oct 18, 2018 8:33 UTC (Thu)
by philh (subscriber, #14797)
[Link]
Using that I only greylist things that look like they're running windows. That catches pretty-much all of the things I wanted to greylist (since they're coming from virus infected spambots) while not delaying the vast majority of legitimate traffic at all.
I really like the per-user scripting with MailAvenger too. It makes it trivial to do things like apply fairly aggressive SMTP-time spam blocking at on main published address, while being able to whitelist senders and (combined with corespondent specific sub-addresses) let regular corespondents avoid any filtering or delays.
However, I notice that MailAvenger needs some love, as it's currently linked against libssl1.0. I'll have to have a look at that...
Posted Oct 23, 2018 22:50 UTC (Tue)
by mattdm (subscriber, #18)
[Link]
Posted Oct 17, 2018 7:44 UTC (Wed)
by gfernandes (subscriber, #119910)
[Link] (11 responses)
That would require *both* correspondents to _also_ use GPG. Which raises the bar considerably, and you'd probably find your "loss of correspondents" to be more in the 98% range, than the 13% range you've mentioned.
Signal, on the other hand, has no bar to entry. Install it on both correspondents phones, and you're done.
Posted Oct 17, 2018 14:03 UTC (Wed)
by edgewood (subscriber, #1123)
[Link] (5 responses)
Posted Oct 17, 2018 16:51 UTC (Wed)
by gfernandes (subscriber, #119910)
[Link] (4 responses)
Does:
Posted Oct 17, 2018 17:04 UTC (Wed)
by k8to (guest, #15413)
[Link] (2 responses)
Posted Oct 17, 2018 17:08 UTC (Wed)
by gfernandes (subscriber, #119910)
[Link] (1 responses)
"And then there is correspondence that is genuinely personal that I really only want copies of for the two of us."
?
Posted Oct 19, 2018 3:14 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Posted Oct 17, 2018 17:23 UTC (Wed)
by mtaht (subscriber, #11087)
[Link]
I don't use phones much (having poor eyesight and hearing is why I like videoconferencing - reading lips and email are how I cope). I think I've taken 3 phone calls in the last year, all of which went badly. Sometimes I think it's not just me, but how bad modern telephony is...
Going back to a "moral" and technological stance I'd had since the 80s. I'd wanted the world to run on static ip addresses, that you owned. I wanted email and other essential services to come directly into your home, where classic legal protections existed. I didn't want third parties to store my mail, chat, data, or web sites, I wanted it *here* on the premises. If I was down, the other sender would buffer it until it could be sent.
If my IP address got blocked for spamming, I'd get to know about it, and have technical and legal recourse. There'd be a local email repairman I could call to fix my server, just like I call a plumber.
If someone(s) tried to DOS my connection, I'd have recourse.
The dissolution of direct responsibility for your own internet connectivity is part of the overarching problem we have on the internet today.
All that said, that's not the world that happened.
So somehow retargetting my stance is in the cards, or fighting back. I just scanned through several thousand email list messages in emacs, read two, hit c to "catch up", and I'm done that part of my workflow for the day.
Posted Oct 18, 2018 8:40 UTC (Thu)
by philh (subscriber, #14797)
[Link] (3 responses)
BTW If anyone knows of a secure messaging thing that I can expect to persuade mobile-only communicators to be willing to install/use that also is capable of running on a Linux desktop (without nearby phone), then I'm very interested -- to date I've not found one.
Posted Oct 18, 2018 14:09 UTC (Thu)
by giggls (subscriber, #48434)
[Link]
You might have a look at https://matrix.org/ though.
Posted Oct 18, 2018 19:45 UTC (Thu)
by spaetz (guest, #32870)
[Link] (1 responses)
Posted Oct 18, 2018 20:11 UTC (Thu)
by pizza (subscriber, #46)
[Link]
XMPP is a protocol. There are a ton of clients for every OS out there. But those clients are useless without a service to communicate with. Most folks are not capable of running their own service, but fortunately there are still many organizations providing XMPP services to the general public.
Posted Oct 26, 2018 7:58 UTC (Fri)
by debacle (subscriber, #7114)
[Link]
Posted Oct 17, 2018 8:49 UTC (Wed)
by mvar (guest, #82051)
[Link]
Posted Oct 17, 2018 17:25 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (4 responses)
Hello,email! I like email for the following reasons:
Admittedly, people like me who run their own SMTP server are becoming rarer, and GMail et al. are destroying the advantages enumerated above. :(
Posted Oct 17, 2018 22:05 UTC (Wed)
by jwilk (subscriber, #63328)
[Link] (1 responses)
Posted Oct 18, 2018 13:24 UTC (Thu)
by oever (guest, #987)
[Link]
Posted Oct 19, 2018 12:52 UTC (Fri)
by mstone_ (subscriber, #66309)
[Link] (1 responses)
Posted Oct 28, 2018 8:34 UTC (Sun)
by martin.pitt (subscriber, #26246)
[Link]
Posted Oct 19, 2018 14:44 UTC (Fri)
by zoobab (guest, #9945)
[Link] (1 responses)
We need the archive back online.
Posted Oct 20, 2018 23:07 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Oct 17, 2018 0:24 UTC (Wed)
by ejr (subscriber, #51652)
[Link] (22 responses)
Posted Oct 17, 2018 0:32 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (21 responses)
Posted Oct 17, 2018 1:08 UTC (Wed)
by ebiederm (subscriber, #35028)
[Link] (6 responses)
I recently had a trip and I really enjoyed the fact that I could quickly access all of my mail archives with public-inbox running on my laptop. So like being able to clone a git code repo locally, having a local repo of discussions has real value.
Posted Oct 17, 2018 1:31 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Oct 17, 2018 2:21 UTC (Wed)
by wahern (subscriber, #37304)
[Link] (2 responses)
HTTP is so low-level as to be irrelevant in terms of leveling the playing field and permitting novel and useful composition of services and data. SMTP is really the last remaining protocol of its kind in terms of federated, structured content sharing.[1] If this generation *isses it way, then they'll deserve the future they get.
[1] SMTP is far from ideal and has plenty of problems, but that says more about the horrendous state of affairs than it does about its utility.
Posted Oct 17, 2018 3:13 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 17, 2018 4:47 UTC (Wed)
by mtaht (subscriber, #11087)
[Link]
Then, complexity, spam,
Then bufferbloat made async transfers bothersome.
Then the cloud.
Then the lack of working ipv6.
Now the lack of static ipv6 along the edge.
I thought with ipv6, everybody would get a /48 with their house. I was so wrong....
I still have a perfectly usable ipv4/29 here that I dare not use for fear of bloating the link...
Posted Oct 17, 2018 8:01 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (1 responses)
> I recently had a trip and I really enjoyed the fact that I could quickly access all of my mail archives with public-inbox running on my laptop. So like being able to clone a git code repo locally, having a local repo of discussions has real value.
I vaguely imagine a protocol for storing discussions and other things as e.g. a git repository, and sets of tools for interacting with them (but a simple text editor being enough in a pinch). People who preferred the web way could use web tools on a server and never know it was git underneath, perhaps one could also also interact with it using an e-mail based server in a way which felt like mailing lists. As something git-based it would be easy to replicate and store locally.
I am sure that if it makes sense it will already exist somewhere. That said, what must have features of modern code hosting environments would definitely not fit into that model?
Posted Oct 17, 2018 17:05 UTC (Wed)
by me@jasonclinton.com (subscriber, #52701)
[Link]
Posted Oct 17, 2018 13:09 UTC (Wed)
by ejr (subscriber, #51652)
[Link] (13 responses)
Posted Oct 17, 2018 19:34 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
Posted Oct 17, 2018 23:36 UTC (Wed)
by excors (subscriber, #95769)
[Link] (7 responses)
That's not going to allow a constant 1Gbps per user, unless you charge each user about $100K. It might support 1Gbps bursts but the numbers suggest it's going to have to have usage caps that are maybe dozens or hundreds of GBs per month. But at least that should be plenty for web browsing, it'd only count as low-bandwidth for people who want to watch Netflix in 4K from the middle of nowhere.
Posted Oct 17, 2018 23:58 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Posted Oct 18, 2018 0:17 UTC (Thu)
by ejr (subscriber, #51652)
[Link] (5 responses)
And some of us old fogeys do disconnect sometimes still while working.
Posted Oct 18, 2018 3:07 UTC (Thu)
by mtaht (subscriber, #11087)
[Link] (2 responses)
It's really hard. It's realllly hard for the next gen, too. No referents. They've *always* been online.
Initially, we found ourselves staying close to shore just so we could stream music... and I now have an email/nas server on board, but the cellular usb stick I have is just terrible, so I just "suffer" without email and haul a hard disk around...
But offline, offshore, is a good - perhaps the last place! - place to think long deep thoughts and deal with the dopamine addiction. I've done some good writing here... but to keep that nas up I should add a solar panel... and maybe cut a deal with a hotel off my favorite anchorage for some high speed directional wifi.
Play with a diaspora pod, too.
Posted Oct 18, 2018 4:36 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
Posted Oct 18, 2018 14:41 UTC (Thu)
by mtaht (subscriber, #11087)
[Link]
...we're gonna need a bigger boat.
Posted Oct 25, 2018 15:02 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
And some of us - with what many would consider a GOOD internet connection (I have a 17Mb ADSL-2+ connection) - regularly get disconnected at peak time because our local uplink (the nearby British Telecom exchange) seems to get overloaded.
A decent, working, always-on, internet connection is somewhat of an unattainable luxury for many of us, even those living in big cities (London, hey, don-cha-know).
Cheers,
Posted Oct 25, 2018 22:11 UTC (Thu)
by nix (subscriber, #2304)
[Link]
The middle of nowhere is also difficult: I'm writing this from an isolated forested valley covered by a 20CN exchange (one of a few dozen left in the country) which is full, so no ADSL for me, only satellite internet. But hey we don't have municipal sewage or gas either and even the POTS phone line tends to go down surprisingly often. I guess we're lucky to have electricity :)
Medium-sized UK towns seem to be better off.
Posted Oct 23, 2018 12:34 UTC (Tue)
by dbnichol (subscriber, #39622)
[Link] (1 responses)
That said, I don't know how you'd do high bandwidth communications on a non-stationary orbit. So much of the link quality is dependent on the alignment of all the antennas in play to get the best possible gain out of them. The worst case link (which is what you have to design to) at the edge of that coverage must be much worse than at the peak. I guess it's just another degradation parameter. People have been doing LEO communications forever.
Posted Oct 23, 2018 23:32 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I can’t wait to be able to work from a mountaintop in South America.
Posted Oct 27, 2018 15:01 UTC (Sat)
by patrakov (subscriber, #97174)
[Link] (1 responses)
Posted Oct 27, 2018 19:52 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 17, 2018 1:02 UTC (Wed)
by gerdesj (subscriber, #5446)
[Link] (11 responses)
There really is a problem with many people's approach to email. It is thinking it is the only form of communication or routinely substituting it instead of another form. How often have you waded through a problem described by an email with many layers of quoting that could have been resolved by simple conversation?
Tools for the job: Resolving a problem involving a lot of to and fro - voice initially and then formal docs (email only for file transfer). Major issue that requires constant documentation - email. Quick note - voice or email. etc etc
Pick up the phone and use it.
Posted Oct 17, 2018 1:09 UTC (Wed)
by mtaht (subscriber, #11087)
[Link] (8 responses)
I really wanted webrtc, also, to be a totally distributed medium,
Posted Oct 17, 2018 1:38 UTC (Wed)
by roc (subscriber, #30627)
[Link] (5 responses)
It's not that difficult to set up your own WebRTC site with whatever user identification approach you like.
Posted Oct 17, 2018 1:53 UTC (Wed)
by mtaht (subscriber, #11087)
[Link] (4 responses)
If there has been substantial work on making a usable local webrtc
I didn't mean MITM on the voice/video part, but on the rendezvous part.
Posted Oct 17, 2018 6:16 UTC (Wed)
by laarmen (subscriber, #63948)
[Link]
Posted Oct 17, 2018 12:41 UTC (Wed)
by dr@jones.dk (subscriber, #7907)
[Link]
Jitsi has existed for a long time, but your remarks about local javascript makes me suspect that you will like the approach taken by Janus.
Posted Oct 17, 2018 13:39 UTC (Wed)
by BeS (guest, #43108)
[Link] (1 responses)
Just download the zip file, extract it to a web directory, visit the page to complete the installation, enable the talk appand you have your own web conferencing system and much more
Posted Oct 18, 2018 2:43 UTC (Thu)
by mtaht (subscriber, #11087)
[Link]
Posted Oct 17, 2018 1:47 UTC (Wed)
by wahern (subscriber, #37304)
[Link]
Fast forward to yesterday and we're doing some maintenance and I'm trying to remember precisely what the problems were and what to look out for. But there was no transcript! No e-mail, no chat logs, nothing. So I had to poke around the systems looking for shell and MySQL history files (luckily still there as all of these services were hosted on AWS EC2 without persistent disks) to help me reconstruct the night from memory and scraps of code.
I realize some people *need* to converse directly with people (ideally in person but minimally with audio/video) to help them process information. I'm the complete opposite--listening requires considerable focus and energy on my part[1] and I far prefer the written word for digesting information. But as a practical matter you *really* need a transcript of the conversation, and video conferencing just doesn't do a very good job of that, if at all.
[1] A trick I learned from a professor was to close my eyes. At first I thought he was just being pretentious and condescending, like he was suffering fools. But I tried it and it really helps. Nonetheless, it still takes considerable attention just to listen, leaving me less capacity for comprehension, analysis, and response.
Posted Oct 18, 2018 16:11 UTC (Thu)
by clopez (guest, #66009)
[Link]
There is a public deployment of it at https://meet.jit.si
It's open source, you can deploy it in your servers if you wish
Posted Oct 17, 2018 13:26 UTC (Wed)
by aleXXX (subscriber, #2742)
[Link]
I disagree.
Calling somebody is even more interrupting than walking into the office of somebody. Then you at least see whether the person is more or less available, and the person has a chance to tell you that maybe in 5 minutes it's better.
With email, the receiver decides when to check for new email, and then, when to act on the email. Much less interruption.
With chat/messaging like Slack, it's IMO more or less as interrupting as email (i.e. if the person doesn't want to answer now, he doesn't have to), but once you are both active at the same time, it can be a quick conversation, which is much less overhead than email.
Posted Oct 18, 2018 10:17 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
That's the worst. You never know where the called person is: having lunch, at the loo, at an important meeting, is sleeping (different timezones!). In landscape offices answering a call usually means not only a "simple" context switch away from the current work, but standing up from the computer, finding an empty meeting room or an available quiet place, so it's really bad. Also speaking non-standard "English" terms (e.g. UNIX commands, function names) between two non-native speakers could be really complicated even disregarding their incompatible accents.
Posted Oct 17, 2018 1:18 UTC (Wed)
by wahern (subscriber, #37304)
[Link]
GMail in particular and web-based e-mail interfaces in general don't work well with group discussions. I have a hard time believing that following e-mail threads is difficult or inconvenient using tools like Mutt or even Mail.app. I assume these people are using GMail or something similar with poor or non-existent threading support and poor support for folders.
I still use procmail and Mutt for personal e-mail. GMail makes e-mail useless. My [very large] employer moved to GMail with IMAP disabled, but for a year I got away with forwarding messages to a dedicated GMail account with IMAP. (I only used Mail.app on our corporate macBooks with encrypted drives, so no less secure.) They finally cracked down and disabled forwarding. That was pretty much the last time I used e-mail regularly for anything work related. Now I'm just like everybody else at the company--if you e-mail me you may have to wait a day or three before I check e-mail and respond. It's too much of a chore. Now all discussions happen in Slack, which is far *worse* than GMail in terms of threading, filtering, classifying, and archiving, but it's where everybody else lurks because nobody responds to e-mail. Want to remember the substance of some conversation and have a chance at recovering the content and the context? *Manually* create a Google Document and hope it doesn't get lost in the noise or the next knowledge base migration. *sigh*
I echo the sentiment about netnews--it really was/is the best technology. But mailing-lists were *sufficient* and didn't require an additional hosted service. If people insist on moving discussions to a separate hosted service then the way to *improve* on mailing-lists is to support a first-class NNTP interface.
Posted Oct 17, 2018 3:41 UTC (Wed)
by zblaxell (subscriber, #26385)
[Link] (2 responses)
I would eagerly allow a group of dedicated volunteers to provide a metric that orders messages (whether they be records in a forum database or emails in my inbox) by how likely I will want to read them, so that I can prioritize my limited participation time; however, I draw the line some distance away from moving to an architecture that makes ignoring that third-party reading advice impossible, or that adds new non-trivial infrastructure failure modes.
Email clients suck. The email clients that kids get exposed to these days (and the email clients that adults are forced by policy to use) are really awful even by the standards of email clients. It's not surprising that people don't want to use email--if I had to use only one of GMail, Thunderbird or Outlook, I wouldn't want to use email either.
So what's the alternative, that enables CoC enforcement without adding a crapton of new ways to fail? Is there something like distributed reddit or federated github?
Posted Oct 17, 2018 14:57 UTC (Wed)
by quotemstr (subscriber, #45331)
[Link] (1 responses)
Can you point to where they say that?
Posted Oct 17, 2018 16:09 UTC (Wed)
by zblaxell (subscriber, #26385)
[Link]
> There is community moderation where users can flag inappropriate messages to notify moderators, moderators and authors can lock topics, move discussions between categories, archive things that are no longer applicable,
i.e. CoC enforcement features.
> The goal to replace the mailing lists with Discourse met unanimous support at the core sprint
i.e. nobody making these decisions is considering what is being lost during a transition away from email.
https://lwn.net/Articles/768489/
> I've now reached burn-out
> I now dread checking my email because of what's going to be there. And the fact that fighting these CoC fires on multiple mailing lists with the tools they provide have not helped to improve my situation.
i.e. desperation, a state of hopelessness leading to rashness.
Posted Oct 17, 2018 6:28 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (3 responses)
Posted Oct 17, 2018 13:10 UTC (Wed)
by ejr (subscriber, #51652)
[Link] (1 responses)
Posted Oct 18, 2018 23:32 UTC (Thu)
by da4089 (subscriber, #1195)
[Link]
Posted Oct 17, 2018 14:39 UTC (Wed)
by zblaxell (subscriber, #26385)
[Link]
Posted Oct 17, 2018 6:40 UTC (Wed)
by ptman (subscriber, #57271)
[Link] (2 responses)
Posted Oct 17, 2018 8:37 UTC (Wed)
by karkhaz (subscriber, #99844)
[Link]
> As others have often said, what we need is a modern replacement for email — some sort of decentralized solution that preserves the advantages of email while being suitable to the 2018 Internet and attractive to our children
What we actually need is an additional user interface over email, which people who don't like email can use, while still allowing people who value local email-processing capabilities to participate in the discussion. In fact I'd even go further, and claim that email *itself* is one of many possible user interfaces over the general concept of "messaging". Projects like DFeed seem to recognise that, it seems; you can post and receive messages using any of the interfaces, and everybody else will receive the message according to how they like it.
It would be considered ridiculous if, having been forced to use emacs for thirty years, everybody heeded the call to abandon emacs and switch to vim because of a few advantages that vim has, ignoring the protestations of emacs users who are perfectly happy with their setup. The underlying medium is still text, and what the text was composed in by one person needn't influence how it is read by the next person. Yet this is what we seem to be doing with messaging: building forums that you can't interact with over email, mailing lists that you can't interact with over IRC. DFeed seems to be a nice exception to this trend.
Posted Oct 18, 2018 10:33 UTC (Thu)
by ptman (subscriber, #57271)
[Link]
Posted Oct 17, 2018 7:27 UTC (Wed)
by halla (subscriber, #14185)
[Link] (5 responses)
Posted Oct 18, 2018 2:17 UTC (Thu)
by ThinkRob (guest, #64513)
[Link] (4 responses)
So that's obviously one facet of the issue. And an important one. But you also touched on other mediums (forums and bugzilla), and made me realize that there's something else important here:
Aside from IRC and established FOSS web apps, e-mail is one of the few mediums that is inherently open and that cannot have that openness cut off by a single entity.
That last part is important, because without consideration of that you get people suggesting Slack c. 2016.
2016: "Oh, but it's got an IRC and XMPP gateway, so you can just use clients for that and it's totally fine and just as good as open!"
2018: "We're shutting off all non-Slack clients. Bye!"
e-mail is inherently federated, distributed, and multi-implementation. You can't effectively prevent open clients from using it, even if you wanted to. But any third party chat, discussion, etc. service? It's only as "open" as the platform-owners want it to be. And that's frequently inversely correlated with their hunger for profit.
Posted Oct 18, 2018 7:59 UTC (Thu)
by halla (subscriber, #14185)
[Link] (3 responses)
"host mga04.intel.com[192.55.52.120] refused to talk to me: 554-mga04.intel.com 554 Your connection to this mail system has been rejected due to the sending MTAs poor reputation"
I don't know what to about that... Other than trying to mail Intel from my gmail account.
Posted Oct 18, 2018 9:36 UTC (Thu)
by gioele (subscriber, #61675)
[Link]
There are many reputation services that can help you understand why your server is being blocked. A good, free and easy to use service is https://www.mail-tester.com/.
When it comes to reputation, it is not only your IP that counts, but also your network. For example, I have once been temporarily banned by GMail because my IP was in a "bad neighborhood" (subnet) in which other IPs where previously used for spam and many of them blacklisted. I notified the server provider and they contacted the blacklist operators resolved the issue.
Posted Oct 18, 2018 10:36 UTC (Thu)
by ptman (subscriber, #57271)
[Link]
Posted Oct 20, 2018 4:56 UTC (Sat)
by ThinkRob (guest, #64513)
[Link]
Fair point. But (donning my optimist hat): that's only on the relay side of the equation, not the client side.
Even if you do use one of the "big players" in the e-mail space -- and there are a lot of commercial e-mail providers out there, evil and otherwise -- it's still totally open on the consumption side. Until SMTP, POP, and IMAP are purged from the face of the earth, my provider can't reasonably prevent me from using whatever interface I'd like to access my mail[1]. And (thankfully) the stalemate between the various providers means that nobody's going to do that in the foreseeable future.
That's a vanishingly rare property for a hosted service nowadays, and it makes me quite reluctant to declare e-mail "dead"!
[1] Although IMAP is such a wacky standard that it may as well be obfuscated!
Posted Oct 17, 2018 9:59 UTC (Wed)
by nelljerram (subscriber, #12005)
[Link]
But in the non-tech world there are a million organisations that rely on email to communicate with me: school, university, insurers, utility companies, doctor, dentist, (valid!) businesses in general, etc.
As long as all those continue to use email, I need to check my email inbox regularly, and that means it's helpful for technical communications to go there too - so that I have just 1 inbox to check and not 10.
So, problematic as it is, email is a great anti-fragmentation solution. If it's going to be replaced (or just improved), it still needs to be a push-to-unified inbox model, as it's just not feasible to have to poll 100s of organisation-specific systems instead.
Posted Oct 17, 2018 15:30 UTC (Wed)
by jkingweb (subscriber, #113039)
[Link]
Posted Oct 17, 2018 17:33 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (20 responses)
You meant: large amounts of email MUST be processed with optimized setups and scripts. Considering "small" amounts of any information don't exist anymore:
Email MUST be processed with optimized setups and scripts; otherwise email = JUMBLE.
So we're now in the "massive information overload" era and email offers... a jumble? No surprise it's dying. To prove me wrong find ONE person who genuinely favors email and does not have optimized setups and scripts.
That is really the most stupid thing ever about email: *everyone* has to configure filters to triage information which was... already sorted in the first place because it came from different sources! Before email jumble it all up. I'll take the worst web forum over that, thank you. Any of these forums will even let me opt-in into... email notifications anyway if I absolutely need them. In just one click groups.google.com even lets me get email notifications on a per-thread basis!
Anyone wishing to save email should go and try to start save NNTP. Likely not enough but worth a shot.
Posted Oct 18, 2018 6:14 UTC (Thu)
by wahern (subscriber, #37304)
[Link] (2 responses)
Having a system to organize your e-mail is no different than having a system to store files (e.g. a file tree). Would you say that local storage is a dead-end because files can be so numerous we're forced to methodically (by hand or by script) organize files into trees; that once we moved past a flat hierarchy the model manifestly became unwieldly? Would you argue that we should *instead* get rid of files and move to a world where all content is stored and presented remotely by whatever web service generated it; that if you wanted to consume that content you needed to use that application's peculiar interfaces and systems; and if you wanted to share it you would have to direct someone to that web service, who may then even need to create a new account?
That's an even worse jumble, but because there's no feasible way to address it's easier to accept as-is uncritically--that it's just the natural state of things. (There is a way to begin to unjumble it, and the first step is teaching the service how to export and import files. But we know those services won't do that willingly, and won't do a good job of it when they do, because interoperability and portability of data is not a priority and often is a risk to their engineering and business models.)
Ultimately the real problem with e-mail is simple: tooling and applications. Comparing Discourse to e-mail is comparing an apple to a forest--it doesn't make sense. What people are comparing Discourse to are GMail, Outlook, Mailman, etc. Few would dispute that those applications suck.
It's impossible for e-mail to die anytime soon; it's as crucial to our social fabric as postal mail. Which is to say, you don't appreciate it because the benefit is collective and hidden--it largely services as a backbone, bootstrap, or backstop for systems layered on top. It may increasingly move to the background, though, reflecting a regression to the mean in terms of the world's ability to sustain strongly integrated, decentralized systems. And as it does it heralds the withering promise of the Internet--that we could disintermediate consumers and producers of content through a technologically egalitarian system.
Posted Oct 18, 2018 8:22 UTC (Thu)
by karkhaz (subscriber, #99844)
[Link]
I don't think non-technically minded people miss arbitrarily-nested directories too much in that context. The reason for this is search. It's much quicker to search for what you want than to maintain a heirarchy that makes sense to you, and then to correctly navigate that heirarchy when you want to find something. This becomes even more true when the metadata you can search through becomes more advanced than merely textual matching. For example, the Photos app detects people's faces automatically, so you can easily search for all photos of Alice; photos are geotagged, so you can easily find all photos taken in Peru, no need to create a "Peru" directory. This will only become more advanced and more useful as machine learning is used to detect more attributes of photographs that aren't even present in the metadata.
This all relates to email because people tolerate GMail etc. for similar reasons: you can just keep a flat inbox with emails that stream by, most of which you ignore, and if you want to find something you search for it. You can keep "folders" if you like, but Google also does some heavy lifting for you, organising your emails based on whether it thinks they are personal, commercial, or related to social media. This is more than enough for most people.
The counterpoint to all this is that none of it applies to (even smartphone/tablet) apps that are marketed as being for "serious work". If you look at apps for professional writers, photographers, whatever, the apps often do come with a built-in file browser with proper directories. And I think that brings us full-circle to the analogy with email: I don't think that email will ever completely disappear, but it might be relegated to something used only by heavy users and important contributors to a community. Casual users will use the equivalent of the Photos app for communication; Slack today, Discourse tomorrow, Tinder the day after. People who advocate email will point out that federated protocols make it difficult to archive data and move it to a new service when the old one closes shop, but it won't matter, because only ephemeral trivia will ever have been transmitted over those channels anyway; meanwhile, important work will continue to be done over email.</aloof>
Posted Oct 19, 2018 4:18 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
There are huge differences: - no one wakes up every morning finding a bunch of new local files; - a child can move files across folder and it's a manual, once-off operation whereas configuring email filters is automation = some form of programming; - everyone is free to organize (or not) local files without anyone else having any idea of how he or she does it whereas email is a communication channel.
> Would you say that local storage is a dead-end because files can be so numerous...
Local files are numerous only if you inflict that to yourself, you're in control. When you download or copy files you've just put yourself in the best context to organize them, it's not a stream of unpredictable interruptions like email.
> Would you argue that we should *instead* get rid of files and move to a world where all content is stored and presented remotely by whatever web service generated it;
I'm not arguing any of that and I doubt it will ever happen (beyond DRM'ed music and video streaming)
I observe that not all but many files have indeed been replaced by something like this. Will all local files eventually be replaced like this? Probably not. I'm personally (and foolishly?) happy to have fewer local files and I don't think we should care what others do as long as we still have some latitude.
> That's an even worse jumble,
I think I get why you use the word "jumble" here and I'm pretty sure I used it to refer to something much narrower and specific. So neither better or "worse"; just unrelated.
> It's impossible for e-mail to die anytime soon;
Agreed, it's basically mailing-lists that need to die (and are dying).
> the withering promise of the Internet--that we could disintermediate consumers and producers of content through a technologically egalitarian system.
The People have voted with their feet and the winner is fake book. Or the next one.
The Internet: yet another technological miracle which was supposed to make humankind fundamentally better in less than one generation. Guess what happened.
Posted Oct 18, 2018 7:27 UTC (Thu)
by niner (subscriber, #26151)
[Link] (2 responses)
I'm using kmail with "Current Activity/Threaded" view and one archive folder. No filters, no scripts and I'm quite happy.
Posted Oct 18, 2018 16:21 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
This means you can't for instance prioritize work (code reviews, bugs,...) received weeks ago against what you received more recently. That's OK if what you received weeks ago were actually just notifications from another system than just email, likely some actual database[*]. This means email is not the primary reference of information anymore: it's become just a *secondary, optional notification channel* / "newsfeed" that workers are free to subscribe to, or not at all, or anything in between. Looks Good To Me.
[*] whether that database has a good or bad web interface or no web interface at all is IMHO far from the main, "design" questions.
Posted Oct 18, 2018 16:38 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Now instead of sending copies of patches and review comments by email as an *optional* feature, the SQL+git patchwork database is fed by... parsing emails. This inversion and resistance to acknowledge the change already happening is a bit ridiculous.
If the centralization aspect scares (some of) you then just replicate the database, on your laptop even. I don't think database replication is rocket science anymore, I bet easier than configuring procmail or mirroring mailman.
(again this has nothing to do with web interfaces)
Posted Oct 18, 2018 17:46 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (8 responses)
Why I care is *control*. Whereas open-source is all about end users being in control, email is the exact opposite. Whether it's spam or lkml, most receivers are helpless and senders are in control. While there are of course massively more powerful mind-control tools than email like for instance fake book, every email is a tiny, disorganized attempt at controlling what's on the receiver's mind. Can't suppress images of a crowd of preschoolers raising their hands and screaming "me! me!". Email was great in the gentlemen's clubs where it and the Internet were invented and I heard that a few gentlemen's clubs are still holding on to it, however it never really scaled beyond those.
Thank you email, you had a good ride with spam and mailing-lists but sorry, we have to demote you to private conversations and optional notifications cause bigger things went out of control and you couldn't scale. We gave your old job to this new database guy instead.
Posted Oct 19, 2018 20:24 UTC (Fri)
by jani (subscriber, #74547)
[Link] (6 responses)
Surely an alternative to email that would address your problems as well as mine could be developed, but it's not here. It seems to me all of the popular alternatives are centralized with a control point.
Posted Oct 20, 2018 6:02 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (5 responses)
Most communities use a single database instance per git project for convenience/laziness but if you're paranoid about centralization then you can have multiple decentralized instances, either mirroring each other or with pull requests between them - just like plain git. All database instances send email to a single mailing-list for backward-compatibility with old maintainers. Other users can choose to receive all those emails, none or anything in between and that is how they're back in control of their inbox. Drive-by submissions become easy.
While most of the above is real today, I understand today's tools like gerrit or gitlab are far from perfect and not checking the boxes of the demanding and sometimes peculiar Linux kernel community. However long before bikeshedding how bad are gerrit's command line interface, emails or other fixable implementation detail, the very first, baby step would be to consider that the *database first, email second" design choice followed by most of the software world is maybe not totally stupid. I bet many patchwork users already agree.
This is like the attitude difference between:
Posted Oct 20, 2018 6:20 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Rule of Representation: Fold [code review!] knowledge into data, so program logic can be stupid and robust.
Posted Oct 20, 2018 8:16 UTC (Sat)
by jani (subscriber, #74547)
[Link] (1 responses)
Posted Oct 20, 2018 14:56 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
NNTP would be a good (re)starting point. groups.google.com has one cool feature: per-thread fine-grained email notification.
Posted Oct 26, 2018 17:34 UTC (Fri)
by zblaxell (subscriber, #26385)
[Link] (1 responses)
Ideally, database first, email for replication (i.e. you'd have a multipart message with text, html, and/or "blob of semi-readable bytes that the application can import to replicate the change in state of the master database").
We're running out of platforms where email MUAs can automatically feed data to an application, and maybe we never had a widely deployed, working, and secure transport for that data. On the other hand, polling works almost as well, so maybe we won't miss that feature when it's completely gone.
Pulling the data into a local git instance solves many of the problems, but only if the database schema never changes; otherwise, you have half your project's history in one replicated silo and the other half in an incompatible replicated silo that eventually only runs inside a VM running an OS nobody supports any more.
For things like code review records, it's important to capture the presentation of the data at the time the data was created, because it's a big deal if a later version of the database has a bug interpreting or converting old data (e.g. it attributes review comments to the wrong developer). This kind of thing is important in environments where a saved copy of a patch review email can change the outcome of a lawsuit.
The ossification of email standards has ensured that's not a problem for mailing lists (though a really deep archive search has to understand things like uuencoding).
Posted Oct 27, 2018 1:50 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
> Pulling the data into a local git instance solves many of the problems, but only if the database schema never changes; otherwise, you have half your project's history in one replicated silo and the other half in an incompatible replicated silo that eventually only runs inside a VM running an OS nobody supports any more.
Code reviews and other "human" conversations have a high read/write ratio and low volume compared to other database workloads. If nothing fancier comes for free then a simple scheme with 1 master + N throw-away, read-only slaves scheme is good enough.
Posted Oct 26, 2018 17:42 UTC (Fri)
by zblaxell (subscriber, #26385)
[Link]
This difference in perspective is interesting.
Of all the communications platforms I use, email is the only one I would say I, as an end user, fully control. Even then, my control is limited because I can't override someone else's decision to _not_ send me stuff when I want them to.
> most receivers are helpless...Can't suppress images of a crowd of preschoolers raising their hands and screaming "me! me!".
...aaand here we are back at the "enforcement as a feature" idea I mentioned earlier.
Posted Oct 26, 2018 17:01 UTC (Fri)
by zblaxell (subscriber, #26385)
[Link] (4 responses)
Email CAN be processed with optimized setups and scripts (or even clunky and awkward ones--modern hardware has billions of cycles to spend on each mail). The scripts tend to be trivial to write, and nearly identical from one sender (or receiver!) context to the next. Web pages (excluding a few RSS feeds, thank you LWN) are not so easy to filter, and many site owners even actively try to fight such automation.
I find that tracking projects through web forums only scales up to about 70 or 80 sites at any time (and let's be honest, anything after the top 15 or 20 is not getting much attention). At that point, any project that isn't providing me with a stream of informative, actionable, filterable emails never hears from me again. For most projects it's easier to just fork the project than deal with some crazy developer's bizarre UX choices.
Even a tiny amount of additional effort above "send an email to list@example.org to create a new topic" or "click this button to send me a copy of all project activity by email so my mail robots can inject it into the correct places in my personal news feed" can be a permanent barrier to casual technical contribution--especially the kind where a passing developer sends in a drive-by bug fix before moving on to the next project they have to integrate that day.
If you're going to run a web forum/bug tracker/code review site with a transparent bidirectional email gateway and superset database schema (with a working In-Reply-To field) then that's fine--but at that point, you're just running a mailing list with a fancy interactive archive.
Posted Oct 26, 2018 17:39 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
Yet people are not interested. Something must have gone terribly wrong :-)
> Even a tiny amount of additional effort above "send an email to list@example.org to create a new topic" or "click this button to send me a copy of all project activity by email so my mail robots can inject it into the correct places in my personal news feed" can be a permanent barrier to casual technical contribution-
Casual / drive-by contribution is all about NOT being copied to the entire project activity, that's the whole point. How many people still read lkml?
By default and with absolutely zero effort, every code review tool in the universe automatically notifies casual contributors of: 1. everything happening to their drive-by contribution. 2. nothing else. Are you commenting without having ever used a code review tool?
Most projects also offer "whole project" notifications for non-casual contributors (and/or email addicts) and stuff in between. Extreme example with several emails per minute: https://groups.google.com/a/chromium.org/forum/#!forum/ch...
> Web pages [...] web forums [...] crazy developer's bizarre UX choices [...] web forum
Understanding the universal move to "database first, email second" and learning from it requires temporarily setting aside any disgust for web interfaces and look *beyond* that.
> At that point, any project that isn't providing me with a stream of informative, actionable, filterable emails never hears from me again.
As in the title: farewell. Learning is hard; un-learning is harder.
> but at that point, you're just running a mailing list with a fancy interactive archive.
No, not a mailing-list: a database with control over personal email notifications.
Posted Oct 27, 2018 1:43 UTC (Sat)
by zblaxell (subscriber, #26385)
[Link] (2 responses)
Well, somebody spent a lot of time implementing Thunderbird's email filtering capability, so I can't be the only one who uses it.
> Casual / drive-by contribution is all about NOT being copied to the entire project activity, that's the whole point. How many people still read lkml?
lkml doesn't require doing the account setup dance before you can post to it. You certainly don't have to subscribe to it. Even mailing lists with subscribe-to-post policies are problematic, as you can't just CC relevant people or projects to add them to a discussion.
> Most projects also offer "whole project" notifications for non-casual contributors (and/or email addicts) and stuff in between.
If email isn't a first-class collaboration tool for the project, these features tend to be missing, or only available to core developers, or the email content isn't sufficient to keep up to date (i.e. it's just noise, or an advisory trigger for polling).
> By default and with absolutely zero effort, every code review tool in the universe...
The effort is far from zero: one has to do a dance with the project's account creation system, diagnose why it can't send a working email address verification link, maybe wait a couple of hours (or days!) before the account becomes active with posting privileges. Even the list of barriers that have to be cleared isn't standard.
This is OK for the handful of sites I have previously volunteered (or am paid) to use, but these days if I can't find an email address to send a patch to, and I have to sign up to one more github wannabe site whose only salable feature is that it's not github, I just close the browser window and fork the project instead. Even a "post as guest" feature would be an improvement.
> ...automatically notifies casual contributors of: 1. everything happening to their drive-by contribution. 2. nothing else.
That's not how drive-by patches work. Either the project accepts the patch, or converts the patch into a bug report and fixes it some other way, or I fork the project. It's not like I'm going to remove a bugfix patch from my copy of the code because the maintainer has doubled down on unusual whitespace preferences or grandiose conflicting plans I don't care about. The transaction requires no second message.
> Are you commenting without having ever used a code review tool?
Ironically, code review tools are a huge portion of my notification workload. Most of them can't do things like flag reviews for notification because they add or remove strings, or touch parts of a source tree I'm interested in, so I have to suck all the reviews in, filter, and generate my own self-notification when something interesting pops up. This is *much* more code and work than any content-based email filter.
Tools like patchwork are much better as I can just consume their input stream directly with fairly ordinary mail filters.
> Understanding the universal move to "database first, email second" and learning from it requires temporarily setting aside any disgust for web interfaces and look *beyond* that.
Moving to a "database first, email second" model necessarily makes disgusting interfaces (web or otherwise) the contributor's first problem to solve, at least until the database schema reaches a critical level of maturity so that multiple interface tools can share a database.
Don't get me wrong--email is awful, and we do need something better. The problem is that nobody seems to have produced anything better yet, and until someone does, email remains the tool of choice for developers contributing across multiple projects. To reuse the CVS-vs-tarballs analogy, people keep proposing ClearCase and SVN when we need something equivalent to bitkeeper or git.
Posted Oct 27, 2018 3:41 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (1 responses)
> lkml doesn't require doing the account setup dance before you can post to it. You certainly don't have to subscribe to it.
And now it's also "write-only". That example was about reading not writing.
> these [email notifications] features tend to be...
I'm trying to focus on the fundamental, core design question(s). So perfecting email notifications (for new, demanding users who are ex-email addicts) seems like an interface implementation detail.
> The effort is far from zero: one has to do a dance with the project's account creation system,
Fair point, this account overhead is the (IMHO reasonable) price to pay for personalizing and controlling the flow of incoming information - and taming spam which is as already discussed here a massive problem for "fully decentralized accounts" systems like mailing-lists. I don't see how you could have that cake and eat it. Maybe some genius will figure this one out.
There are many ways this overhead is kept reasonably small: OpenID and similar, large sites like github (there aren't and there will never be dozen of "github wannabees"), password managers, etc.
> I just close the browser window and fork the project instead.
Congratulations: you've just implemented the decentralization in the "database first, optional email notification second" approach. Well done!
> That's not how drive-by patches work.
That's not how *your* drive-by patches work, please don't generalize.
> Most of them can't do things like...
"Most" => perfectible implementation detail. Answered above.
> ... at least until the database schema reaches a critical level of maturity so that multiple interface tools can share a database. [...] -email is awful [...] The problem is that nobody seems to have produced anything better yet, [...] when we need something equivalent to bitkeeper or git.
Agreed, agreed and can't wait.
> until someone does, email remains the tool of choice for developers contributing across multiple projects.
Less and less often; hence the title of this article. This l33t and extremely productive community is IMHO underestimating how much "normal people" disliked email, spam, configuring filters and how much people can cope with poor web interfaces. Normal, 9-5 "enterprise" developers tend to have much bigger, unrelated productivity issues at work than a once-off github account creation or having to cope with its web interface. For instance they likely have to use Outlook (which can't do email at all!) and dozens of much crappier "home-made" web interfaces internally.
Posted Oct 27, 2018 21:20 UTC (Sat)
by zblaxell (subscriber, #26385)
[Link]
Interfaces that, due to identical selective pressures, end up being imitations of email filters.
> there aren't and there will never be dozen of "github wannabees"
There _already_ are. I had almost 20 such accounts before I decided I wouldn't support that behavior any more. Most of them are (or were--attrition is high) gitorious or gitlab instances hosted on Linodes. Some of them are more exotic creatures I don't recognize.
The alternative puts a lot of eggs in the github basket, which doesn't seem like a good idea either.
> Congratulations: you've just implemented the decentralization in the "database first, optional email notification second" approach. Well done!
This doesn't seem like success. I'd expect success would involve me contributing to the other project as opposed to being forced to treat it as abandonware.
> That's not how *your* drive-by patches work, please don't generalize.
Huh? That's the definition of a drive-by patch: one contributor, one bug, one fix, one transaction.
> Less and less often; hence the title of this article.
Uh, no, this article is about developers who spend most of their time contributing to a handful of small or medium-sized projects like Python or Fedora, or some random Github. If you're integrating a hundred open-source components into an enterprise service deployment, or building bespoke hardware with a custom software stack, you're definitely not moving away from email as a primary collaboration tool any time soon.
Every few months I get to experience the next generation of new developers first hand in the form of coop students. They come in adept at using email on their smartphones and git from the command-line, but they navigate filesystems by clicking through GUI tools. They quickly learn to stop doing that--the GUI tools are unauditable (we do audits) and error-prone (we do testing), unrepeatable (we do automated deployments), and while not impossible to communicate, much more awkward and expensive (we work with people in different timezones). It's much easier to fix all that by mastering and using a scripting language day-to-day than by using any GUI tool that currently exists. After a while the students figure out they have to do that with email too, for mostly the same reasons--regardless of what tools they started with or might prefer to use, they need to switch to tools that can keep up with their peers and the workload.
> Normal, 9-5 "enterprise" developers tend to have much bigger, unrelated productivity issues at work than a once-off github account creation or having to cope with its web interface.
My 9-5 enterprise workday is where the pressures toward email-first as the collaboration tool become *most* acute.
If I'm paid to create accounts, I'll create all the accounts my customer/project/manager will approve engineering time for, and every customer/partner/supplier wants me to sign up for at least one. Bad web hosting experiences are just included in the price. Most of the real work still gets done by email, because any four collaborating engineering groups have no common database. All the idle databases seem like a waste to me, but I don't decide what customers want to pay for.
I most strongly object to having to do this as a volunteer or on otherwise unbillable time. We might have only a few hours--or minutes--to evaluate, integrate, and contribute to a small project. If the project's account signup interface takes ten of those minutes to complete, then it has burned the time budget for any kind of helpful feedback we might have. We can't afford to suck that up and continue stumbling through an unfamiliar or broken web interface when the next project is around the corner.
Maybe the project doesn't care it's not getting our contribution, or it only values contributions from people with more available time than we have. I can't care either way--we don't have a billing code for caring about stuff at work, and I usually have other things to spend my own time on. I'm volunteering my time here to inform project owners who otherwise may not be aware of potential contributions that can no longer materialize. This is the price of making cross-project collaboration harder vs. making intra-project collaboration easier.
> For instance they likely have to use Outlook (which can't do email at all!) and dozens of much crappier "home-made" web interfaces internally.
I haven't seen a new home-made web interface in an enterprise recently (though there are still plenty of legacy horrors that won't work on anything newer than IE6 out there). Enterprises seem to be moving to mature third party frameworks with plugins to support enterprise-specific activity. Gerrit, Gitlab, etc., or the equivalent proprietary silos are also taking over. That works for enterprises because they explicitly value intra-project collaboration over cross-project collaboration. It ends up being the individual engineers' job to work around that when working with outsiders.
Even Outlook has email distribution lists that can be created or joined with a few clicks.
Posted Oct 18, 2018 6:17 UTC (Thu)
by medicalwei (subscriber, #103028)
[Link] (3 responses)
I was trying to follow some "digital detox" advice. The population of "instant messaging" services make people (including me) unable to focus and they interrupt more. I am thinking of throwing away IMs and use emails exclusively for digital communication (but haven't really taken the path). Emails are much formal too, and people often write contents more carefully compared to what we do even on the forums.
However, for engagement with people using mailing list makes it like "newbie filter". So, if your target audiences are for new comers mailing list is actually not good to them, unless you intend to filter them out.
Posted Oct 22, 2018 13:18 UTC (Mon)
by pj (subscriber, #4506)
[Link] (2 responses)
Don't confuse the surface with the substance.
Posted Oct 22, 2018 15:34 UTC (Mon)
by medicalwei (subscriber, #103028)
[Link] (1 responses)
Though technically you can treat IM like email and vice versa, the mindset people using them are different.
Posted Oct 22, 2018 20:54 UTC (Mon)
by neilbrown (subscriber, #359)
[Link]
It is not your duty to fulfill other peoples expectation. It is your duty to set them, by behaving consistently.
Posted Oct 18, 2018 13:49 UTC (Thu)
by abo (subscriber, #77288)
[Link]
While systems like Discourse might have a slightly better user interface than HyperKitty, the difference could be seen as marginal and fixable.
Posted Oct 18, 2018 18:17 UTC (Thu)
by flussence (guest, #85566)
[Link] (1 responses)
That's not to say mail infrastructure doesn't have any use, but it only seems useful for people already heavily invested in long-term participation and willing to deal with the spam problem. Some projects don't have enough of that demographic left to justify the upkeep costs.
Posted Oct 20, 2018 20:51 UTC (Sat)
by creichert (guest, #128045)
[Link]
I'm not sure if the author is making an explicit point with this line, but I've built a personal habit of aggressively trimming notifications and completely disabling all "like", "share", and alerts that I can't or won't act on.
I'm not saying it's pragmatic to recommend this for new users, but it's a
To the point, I appreciate services that allow me the option of using Email *or* their web interface seamlessly so I can reduce context switching as much as possible.
Take communication over GitHub for example:
When I'm in my mail client and come across a pull-request, issue, or discussion, I can choose to reply from the email or browse the URL and continue a discussion from the web client. Thus, I can reduce context switching and fragmenting my attention.
> As others have often said, what we need is a modern replacement for email — some sort of decentralized solution that preserves the advantages of email while being suitable to the 2018 Internet
I'm certainly not opposed to this argument, but it seems that the alternative system vaguely proposed is just like email, with a web interface, and less SPAM.
Posted Oct 21, 2018 19:31 UTC (Sun)
by Frogging101 (guest, #113180)
[Link]
A farewell to email
A farewell to email
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.taht.net/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mail.taht.net/privkey.pem
smtp_tls_cert_file=/etc/letsencrypt/live/mail.taht.net/fullchain.pem
smtp_tls_key_file=/etc/letsencrypt/live/mail.taht.net/privkey.pem
smtp_tls_security_level=encrypt
smtpd_tls_security_level=encrypt
perhaps my personal email would be more useful.
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
MailAvenger does SYN packet fingerprinting which lets you vary your policy depending on the guessed OS of the client.
A farewell to email
A farewell to email
A farewell to email
He clearly meant correspondence between him and another party that was sent point to point via email, vs being in a broadcast like a web forum. The former can be private even if it's sent in the clear: Alice sends Bob an unencrypted email because she is concerned about Charlie, not Mallory.
A farewell to email
A farewell to email
1. Every correspondent run their own email server?
2. Is every email guaranteed to never go via any intermediary?
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
Signal sets a far too high bar for me:
A farewell to email
Maybe it's just me, but I'm not into mobile phones.
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
Yes, it does exist. This is SSB https://github.com/ssbc/secure-scuttlebutt but it has a long way to go in terms of managing the kinds of things that forums can currently do. There are a number of frontends for SSB now but it's still very hard to use and most of the protocol features for moderation tools mentioned in the article are absent.
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
Wol
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
so I could say... oh - meet me in somehash. Seems sort of feasible,
but there's an awful lot of mitm going on for webrtc....
A farewell to email
A farewell to email
service rendezvous service and relevant javascript for it, please point me at it!!!
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
I only call somebody if it is really urgent, almost an emergency. If somebody is called, this person is interrupted from his work immediately, and more or less forced to pick up the phone and switch topic in that instant.
At least that's how it feels for me when I'm called.
I have to drop everything I am doing and switch to whatever the person who calls me wants to discuss.
Video conference is somewhat similar, I schedule them, for more serious discussions with preparations, it's very useful for that.
And if it is just for small messages, it doesn't fill up the email inbox.
"Pick up the phone and use it."
A farewell to email
A farewell to email
CoC As A Service
CoC As A Service
CoC As A Service
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
>
> "host mga04.intel.com[192.55.52.120] refused to talk to me: 554-mga04.intel.com 554 Your connection to this mail system has been rejected due to the sending MTAs poor reputation"
>
> I don't know what to about that... Other than trying to mail Intel from my gmail account.
A farewell to email
A farewell to email
Use of email for software projects is not the blocking problem, if we want to replace email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A. CVS sucks, tarballs forever! versus:
B. CVS sucks, tarballs until we find something that doesn't suck.
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
I like to wait a day before replying to anything non-trivial (Admittedly, most of IM is trivial.....as is this comment)
Being in a different timezone to EU and US makes this easier.
A farewell to email
A farewell to email
A farewell to email
an effective system that allows me to maintain my focus, reduce overall noise in my inboxes (mail or otherwise), and handle higher volumes communication.
A farewell to email