Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Posted Sep 7, 2021 18:13 UTC (Tue) by pizza (subscriber, #46)In reply to: Emacs discusses web-based development workflows by marcH
Parent article: Emacs discusses web-based development workflows
Sure, nobody enjoys configuring email filters. But at least email _has_ filters!
Many people turn off app/service-specific notifications because they all follow the "PAY ATTENTION TO ME RIGHT NOW!!!!" interruption-driven paradigm where the sender thinks it's the most important thing ever, but the recipient probably doesn't agree but still suffers anyway. Email is _still_ unique in that you have the ability to configure how frequently/often/etc it polls and what sorts of stuff takes priority.
> _This_ is probably the only serious, valid and informed concern in this entire discussion. Maybe I'm too optimistic but I hope gitlab is not too bad here and best if luck to sourcehut and maybe others.
Gitlab (in of itself) is fine. So is Github. So is any individual site. But approaches that are optimal for a single service don't scale beyond more than a handful of services. It's the same thinking behind RSS aggregators/readers; instead of hitting dozens (or hundreds) of sites every day to see if something is new, it's all aggregated into a single interface. Of course sites are slowly killing off RSS in favor of more "modern" special-snowflake-site approaches, because advertising and data mining gets a lot harder to enforce.
Posted Sep 7, 2021 19:22 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (5 responses)
It's extremely funny you wrote that because this is probably the reason why I hate email the most: email gets "pushed" to me all mixed up and I have to configure something manually to separate it again. Everything else gives me some level of control on quantity and quality at the source instead and best of all: the ability not to "pull" / read it at all and ignore it completely with zero effort, by just not going there and doing nothing. Also, no other medium makes the stupid, email-like assumption that I have read it - or much worse: that I will act on it - because they just pushed it to me. This is especially obvious coming back from vacation right now...
(NNTP achieved some of this decades ago)
> Many people turn off app/service-specific notifications because they all follow the "PAY ATTENTION TO ME RIGHT NOW!!!!" interruption-driven paradigm where the sender thinks it's the most important thing ever,
I'm sure you could prove that "github is evil" in dozens of different ways but certainly not this one.
BTW no one is forced to receive all pull requests on git**b
Posted Sep 7, 2021 19:52 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
Sure, that's what happens when you aggregate lots of different things into a single place.
(The alternative is having to gather it up manually. Which works great at smaller scales)
> Everything else gives me some level of control on quantity and quality at the source instead and best of all: the ability not to "pull" / read it at all and ignore it completely with zero effort, by just not going there and doing nothing.
Pretending something doesn't exist doesn't make it go away.
> Also, no other medium makes the stupid, email-like assumption that I have read it - or much worse: that I will act on it - because they just pushed it to me.
Very few general communication systems provide a mechanism for the _sender_ to know if the message has been read (much less acted upon), and any assumptions along those lines are _social_ problems that have nothing to do with email. Heck, if anything email has a _lower_ expectation of immediate response than most other channels.
(And meanwhile, what exactly is the point of notifications, if not an expectation of follow-up actions)
> I'm sure you could prove that "github is evil" in dozens of different ways but certainly not this one.
Funny, no matter what I do I can't get github to stop sending me notifications _every single time_ something happens in my employer's organization. every new repository, every new ticket, every new discussion. Sure, that's technically not github's fault (vs my organization's boneheaded policies) but the net result is that github's official notification system is completely useless as I get drowned in the deluge of noise. Fortunately I've been able to use (gasp) email filters to redirect most of the dreck to /dev/null, and only let through stuff for the specfic projects I care about.
Much like democracy, email is the worst system around, except for all of the others.
Posted Sep 8, 2021 0:48 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (3 responses)
You missed this point. It was about not receiving things I do not care about. Like for instance most (but not all) messages on a mailing list.
> Very few general communication systems provide a mechanism for the _sender_ to know if the message has been read (much less acted upon), and any assumptions along those lines are _social_ problems that have nothing to do with email. Heck, if anything email has a _lower_ expectation of immediate response than most other channels.
I'm afraid you missed that point too, it was about shared-TODO-lists-by-email. Like the TODOs from your manager and from everyone else who thinks it's your job to do something they want. This problem has been solved a long time ago and - tada - all forges have one: it's a bug/task tracker. Forges merely added the integration with everything else.
People who keep complaining that they don't get attention when they file bugs/request miss the point: a bug tracker is by design where you can politely "file and ignore" things from unimportant people to minimize distractions. Until they pull some strings or something bad happens of course, then you just clock on the link and you don't have to run Google Search on your inbox to gather disparate threads.
In these two particular cases email is IMHO a very good example of your "PAY ATTENTION TO ME RIGHT NOW!!!!"
Posted Sep 8, 2021 2:15 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
That's a fair criticism, and for individual groups it works well. The problems come from scaling up to multiple indepdent sites, each with their own credentials and user interface notions that again aim at user lock-in and maximizing data mining opportunities vs providing tools to keep the signal:noise ratio at manageable levels.
(FWIW, I get most of my low-caring mailing list and forum stuff via gmane's nntp gateway. Superior tools for the task at hand, and all that..)
> I'm afraid you missed that point too, it was about shared-TODO-lists-by-email. Like the TODOs from your manager and from everyone else who thinks it's your job to do something they want. This problem has been solved a long time ago and - tada - all forges have one: it's a bug/task tracker. Forges merely added the integration with everything else.
Yeah, as you said this has long been a solved problem, and today you have a wide variety of solutions to choose from with various degrees of integration. Some even work well completely via email.
> In these two particular cases email is IMHO a very good example of your "PAY ATTENTION TO ME RIGHT NOW!!!!"
I'm sorry, I don't understand how this is a problem somehow unique to (or particularly exacerbated by) email? A notification is a notification is a notification, and while it's intended to get your attention, you're free to ignore it [1] no matter what channel it takes before it lands in front of your eyeballs. (Since we're talking about interacting with external services that presumably maintain their own state independent of whatever client you use to access them.)
Email provides capabilities to manage that stuff (at the individual level) that other channels usually lack, especially in aggregate, albeit with the disadvantage of requiring a more advanced client setup than what (eg) the android gmail (or worse, outlook) clients provide. But setting that up takes upfront, inconveniencing effort, so hardly anyone bothers to try any more.
Look, forges offer a _lot_ of advantages for software development; I'm not disputing that! If something like sourcehut was available fifteen years ago I'd not have bothered with my current mis-mash of gitolite+cgit, flyspray, dokuwiki, mailman, and whatnot, used nearly entirely for my own stuff. But it wasn't, and I needed the on-premise capabilities each of those tools provided, so here I am, with a couple decades' worth of legacy baggage (ie data) that heavily weighs down one side of the cost/benefit curve.
[1] You may face social or employment consequences for ignoring certain notifications, but that's an entirely different matter.
Posted Sep 8, 2021 6:38 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (1 responses)
The problem with pure email "workflows" is the notification is the data and the data is the notification.
Posted Sep 8, 2021 11:42 UTC (Wed)
by pizza (subscriber, #46)
[Link]
> The problem with pure email "workflows" is the notification is the data and the data is the notification.
Well, yeah, but I thought we weren't talking about "pure email workflows" -- As opposed to using email for notifications by external services. (vs sms, special snowflake per-application mechanisms, manual polling, a colleague throwing something at you, etc)
Even debbugs' and emacs' email-based bug trackers are centralized and don't rely on the client to maintain any state.
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Emacs discusses web-based development workflows