Hacker News Reader

> a lot of this could be solved with better tooling

Yeah, better tooling like GitLab.

>tooling

I don't see why we should still use email when half of that requires "non-email" tooling then. I like using emails for person-to-person communication, not this.

And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea?

>Conventions are good. It's part of being human.

It definitely won't keep the creative juices flowing when 99% of said conventions can be automated out. Rather, having to do everything manually impedes my ability to work on actual creative things. This paragraph is also semi-contradictory to your earlier paragraphs on tooling.

I am replying to you on HN without manually typing "From:" "To:" because the website has automated that process for us.

Furthermore, you are wholly sidetracking the core issue here which is "How can we enforce conventions?" The more laborious following a convention is, the harder it is to enforce the convention.

> And what better tooling could it be if not a tool explicitly designed for software development, like GitHub/GitLab/Gitea?

It would be better if the user could actually select his tool instead of being forced upon a tool by a project or company. The former used to be the standard with email. Today, I have the impression half of my colleagues never used a mail program that wasn't called Outlook or Gmail. Spoiler alert: Both are abysmal mail readers for the purpose of following and participating in technical discussions. To fix that, they should at least support proper threading and encourage selective inline replies.

Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate. As long as Outlook-ordering decisions are made at the C* level it will never support software developers properly.

>Making the tools a user choice over an established protocol/data model creates lots of possibilities to innovate

If that were the case we wouldn't have had this discussion today. Email workflow is abysmal and the limited innovations it has (patchwork comes to mind) is not enough to attract new developers.

What's worse is that the email workflow is very resistant to changes[0], and arguably, the people supporting the email workflow are too. It's hard for one to imagine there is a chance of innovation given the current predication. Even a complementary system like patchwork has remained relatively unadopted according to my non-scientfic observations (most people are likelier to link to the mail directly instead of the patch series on patchwork).

[0]: Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata. I don't know how well people will receive it, I'd imagine very badly.

> Building a more complicated system akin to the forges on top of emails will likely require modifications to the original email workflow, e.g. to add metadata.

Emails do have header, there is no problem storing metadata in those.

"Metadata" here refers to everything surrounding the git repo, e.g. CI status, milestones, or even reactions. Those metadata are constantly updated and since there are no mechanisms to retroactively update previous emails to include the new metadata, the only way to do it is to send even more emails to the already-voluminous mailing list to keep the email-only people updated.

This is why I have serious doubts on the possibility to build forges (with accessibility and feature set on par with GitHub/GitLab) on top of emails. And please, don't use the minimalism excuse because those extra features of forges _are_ being used. Removing them for the sake of forge-on-email is a strict UX degradation and you only end up making both forge people and email people angry.

Another way to share those metadata through emails is to send an email that links to an external HTTP website which displays the latest updated data, as is done by some projects for CI. But at that point, it ceases to be an "email workflow" in my opinion -- if you are already hosting a HTTP server, you might as well host a git forge on it.

You bring up valid points. I am not at all arguing we should strive for minimalism and reduce features that are actually used. If we are already using html emails for everything, why can't we embed the little build status widgets, plugins, tags -- whatever they are called -- that you find in many readme file on Github into html emails?

Or it is great idea to have a plugin for your mail program showing the build status of your ci plugin next to the email about the pull/merge request?

Better tooling in Linux kernel case is moving everything to https://lore.kernel.org/ and https://b4.docs.kernel.org/en/latest/ witch mostly side steps the E-Mail part of the flow.

The amount of people who have the free time to massage `.muttrc` for patch based flow is pretty small. And https://sr.ht/ does not work for the volume that Linux kernel sees.

So your advice is to reinvent to very good and battle tested wheel of GitHub and GitLab around multiple different extra tools which don't even come close?

Do you also DIY your dishwasher with an assembly line, a rotating robotic arm with a sponge, industrial chemicals? Or do you just use an off the shelf dishwasher if you're at the sufficient scale needed for one?

> So your advice is to reinvent to very good and battle tested wheel of GitHub

GitHub isn't analogous to a wheel. GitHub is a proprietary service owned by one company. Any patent on the wheel has long expired.

A web-based collaborative Git-based VCS is a wheel. There are like 10 different projects, the majority of which are open source or at least open core.

Wait, are you saying email is reinventing the wheel that is GitLab etc.? I think your history might be a bit backward here.

My advice is to develop your own personal tools in such a way that you can handle all kinds of interactions with other developers and projects. It's pointless saying "I prefer this or that" when you probably don't get to make those decisions. Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.

My point isn't at all about trying to switch projects from forges to email based workflows, it's merely saying that you can do things to improve your tools such that you can interact with those projects. If you find it difficult to work with a successful project with many contributors then you are the problem, not them.

> Wait, are you saying email is reinventing the wheel that is GitLab etc

Bolting a million custom tools around email to force it to do something it was never meant to do is reinventing the wheel, yes.

> Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.

Yes, and very very few of them prefer arcane workflows such as patches over email. Some highly critical ones like the Linux kernel do, but the vast vast vast majority of products use well oiled machines like GitHub, GitLab, Gogs, Gitea, etc.