6 ms·

> 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 coul

> 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.

orangeboats 3y ago
>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.
- funcDropShadow 3y ago
  > 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.
  - orangeboats 3y ago
    "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.
    - funcDropShadow 3y ago
      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?

orangeboats 3y ago

>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.

funcDropShadow 3y ago
> 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.
- orangeboats 3y ago
  "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.
  - funcDropShadow 3y ago
    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?