@jacksonchen666 @marcan On the off-chance that this is a good-faith question, I'll point out one specific issue from which most of the practical issues derive:

E-mail based patches are based on convention, not on technical formats.

This means that to contribute, you have to learn and memorize a bunch of arcane conventions, and never get them wrong, or the tooling will get confused and good luck figuring out how to fix it.

It also means that eg. the review process cannot be as granular as something with a dedicated review UI; it's not possible to render an easily navigable 'review history' (see eg. Github PR review threads) unless every review comment includes a bunch of metadata.

And to include that bunch of metadata over e-mail, every user needs to learn more conventions, because e-mail clients are not built to do any of this, so there's no UI for it.

So either you have less metadata and can't render useful outputs, or you have more metadata and require people to memorize absurd amounts of conventions.

There is no good solution there.

We have dedicated UIs for things for a reason - they are more accessible because things have a clear purpose, and don't require constant memorization. How it works internally is a separate matter, but that UI *has* to be there to make it accessible.

(I'm not interested in further discussion on this topic; this should be enough of a pointer to think about other usability/accessibility issues that spring forth from this problem.)