Emacs discusses web-based development workflows
Emacs discusses web-based development workflows
Posted Sep 6, 2021 22:05 UTC (Mon) by pizza (subscriber, #46)In reply to: Emacs discusses web-based development workflows by rodgerd
Parent article: Emacs discusses web-based development workflows
If you were berated and attacked for years (and years) for being out of touch dinosaurs for not embracing [fad of the year] you'd express a fair amount of contempt too. It's no coincidence that those supposed dinosaurs are still responsible for maintaining most of the low-level infrastructure that all of these new fads are built on.
In every skilled field it is there is a concept of mastering of the tools of the trade.
You wouldn't tell a chef that their nicely-equipped commercial kitchen is a just a pile of completely unnecessary out-of-touch-with-modern-times wankery because you can do everything you need with a microwave oven.
Suffice it to say I don't place much stock in folks pissing all over email because they can't be bothered to learn to be effective with it.
Posted Sep 7, 2021 14:42 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (11 responses)
Totally understand. Except this time, email is really dead. No crying wolf this time, sorry about that.
This time, integrating code reviews, CI and everything else in the same place is really not the "fad of the year", it's the present and it has been for years (and years).
> You wouldn't tell a chef that their nicely-equipped commercial kitchen is a just a pile of completely unnecessary out-of-touch-with-modern-times wankery because you can do everything you need with a microwave oven.
Not sure whom exactly you're referring to but there are many open source projects and "chefs" using a forge too. Even (parts of) Debian are using gitlab and I believe Debian is pretty serious with software freedom.
Posted Sep 7, 2021 16:20 UTC (Tue)
by pizza (subscriber, #46)
[Link] (10 responses)
Except _every_ _single_ _service_ implementing all of that stuff (and everything else) is still backstopped by email, because email remains the communication channel that can be assumed to be available.
Granted, increasingly those services just send an email that just says little more than "something happened" and "log in to see details", as each individual service tries to increasingly lock folks into their particular walled garden.
That's great if your life revolves around that single service/garden, but as every service(and their dog) tries to create their own proprietary platform/ecosystem whose sole purpose is to monopolize and data mine your attention, a different approach is needed if your priorities don't align with those platforms'.
...which brings us full circle to email, the universal inbox.
Anyway.
Posted Sep 7, 2021 16:41 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I'd been using Github for a decade with an incorrect email on my account before I noticed that.
> Granted, increasingly those services just send an email that just says little more than "something happened" and "log in to see details", as each individual service tries to increasingly lock folks into their particular walled garden.
That's because email actually sucks for anything but notifications and password resets.
Posted Sep 7, 2021 16:43 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
On the contributor side, there is no insight into the status of a patchset. I have 3 sent to Git recently. One got review and needs some work. I know that is in my court. However, that work led me to make 2 other patchsets as a base. One has received no response and it's not in the "What's cooking" summary either. The other went through some iterations before another (more regular) contributor took it over. These are in some state between contribution and accepted, but I don't know anymore because that state is sitting in someone's inbox somewhere. Has CI been run? Is it pending merging? As for the ignored patchset, how long before a friendly ping? Should the ping be a new thread with a resend of all the patches? The state machine is completely hidden from view and it discourages these kinds of "hey, wouldn't this be nice?" contributions with hidden bureaucracy.
On the maintainer side, collaboration between maintainers is visible. I don't have to fight different threading styles if there are two topics about different parts of the code (replying to both on each reply versus new subthreads for each topic). I can also see CI state (has it started? finished?), who is "in charge" of reviewing it, etc. Giving a patchset to a fellow maintainer for review is a state change (which turns into an email) rather than a crafted one handing it over. It's also visible to everyone.
Additionally, when joining a project, one is (usually) lacking the email archives to be able to contribute to in-progress threads at the right place versus able to just dive in on existing discussions seamlessly. For example, if I have the same problem as someone else and there's a thread I'd like to contribute to, I'd better have *already* been a subscriber to the list or I have to wait to receive a point to latch onto it. Hope it's a relevant subthread. Of course, one could trawl the archives for Message-Id headers and craft a reply yourself, but who wants to learn how to do that in their preferred email client?
I respect that email may be more comfortable for many, but its process opacity is just maddening to me. Do I wish things worked like debbugs with email able to control things *and* have a web interface into the current state? Sure. Has anyone built one yet? No. But *my* preferences are more towards facilitating the "paperwork" for the project as a whole rather than asking everyone to come up with their own inbox-based TODO list manager.
Posted Sep 7, 2021 17:00 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (7 responses)
Indeed email is sadly one of the extremely few "universal" media which is why it has always been a supported for notifications. It's far from the only way to get notified though and many people turn off email notifications. Not everyone enjoys configuring email filters.
> but as every service(and their dog) tries to create their own proprietary platform/ecosystem whose sole purpose is to monopolize and data mine your attention..
_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.
Posted Sep 7, 2021 18:13 UTC (Tue)
by pizza (subscriber, #46)
[Link] (6 responses)
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
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