8 ms·

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

> 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

"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?