3 ms·

A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of

A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development? We already use a ton of other tools specific to software development. A personal todo list system that integrates with your email is also essential. I don't understand how people don't do it. It's all very well forges having status of MRs etc. but surely your job isn't only merging MRs on GitLab? So you'll have other todo lists distributed over various places like other forges, Jira type things and, of course, your email. Why not consolidate all your todos into one place? If you're interested in a patch, add it to your todo list and check the status of it periodically. Conventions are good. It's part of being human. Learn how to use language to communicate with your fellow humans. It keeps the creative juices flowing.

Hendrikto 3y ago
> a lot of this could be solved with better tooling Yeah, better tooling like GitLab.
argulane 3y ago
Better tooling in Linux kernel case is moving everything to https://lore.kernel.org/ https://lore.kernel.org/ and https://b4.docs.kernel.org/en/latest/ 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/ https://sr.ht/ does not work for the volume that Linux kernel sees.
orangeboats 3y ago
>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.
- funcDropShadow 3y ago
  > 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.
sofixa 3y ago
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?
- grey_earthling 3y ago
  > 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.
  - sofixa 3y ago
    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.
- globular-toast 3y ago
  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.
  - sofixa 3y ago
    > 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.

Hendrikto 3y ago

> a lot of this could be solved with better tooling Yeah, better tooling like GitLab.

argulane 3y ago

Better tooling in Linux kernel case is moving everything to https://lore.kernel.org/ https://lore.kernel.org/ and https://b4.docs.kernel.org/en/latest/ 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/ https://sr.ht/ does not work for the volume that Linux kernel sees.

orangeboats 3y ago

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

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

sofixa 3y ago

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?

grey_earthling 3y ago
> 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.
- sofixa 3y ago
  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.
globular-toast 3y ago
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.
- sofixa 3y ago
  > 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.