I wasn't criticizing the use of them, I just find it fascinating that we still use them. They'll probably still be around in some form in another 3 decades.

Email is a root-of-trust for authentication in most non-email systems.

GIT is non-proprietary and decentralized so it keeps that promise.

And having a built-in issue tracker

1. isn't related to those properties, and

2. isn't truly within the scope of a source code version control management solution.

That's the domain of project management.

Fossil has one. If its something you want use Fossil - which I think is a great alternative for small teams, on the other hand, this is probably not something large teams (which are a high priority for git) want.

For large projects like the Linux kernel as an example out of many, I would assume the built-in issue tracker would end up 100x the size of the code base in storage space. lol

If I ever get around to writing my git issue tracker, everything will be stored in a completely separate reponame-issues.git

Shouldn't the git native issue tracker be as simple as adding file pr/the_problem_i_am_having

Issues shouldn't really live in the same source tree, IMO. But AFAIK there are forges that keep the issues in the same repository, just not in the same tree of commits that the source tree has, git notes style.

Any user without commit permission should be able to create tickets and comment on them.

What's wrong with debbugs? :)

- horrible usability

- can only participate in conversations via e-mails

- unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox

- NOT accessible, especially in the disabilities sense

- doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability

- no responsive design, tiny text and horizontal scrolling on mobile phone screens

- sends you your password in cleartext via e-mail

- actually complicated to unsubscribe from a list / manage your membership

> - horrible usability

The web has horrible usability if you use a text-based browser. I.e. if you use a mail reader with good usability, a mailing list has good usability. This is a client-side issue, not a technology issue.

> - can only participate in conversations via e-mails

Um, yes, a mailing list uses e-mail. I don’t know what you expected.

> - unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox

If you are a new user, and want to reply to a mail you read in the list archive, just write a new mail; there is no strict rule that any discussions must be restricted to one thread.

Indeed, if you want to start a new discussion after some time has elapsed, a new thread may be preferred.

> - NOT accessible, especially in the disabilities sense

Again, this is a client issue. I believe that e-mail is actually the preferred form for those with accessibility needs.

> - doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability

Somewhat true, but this depends on the list – some list archives do feature search – and is very rarely a problem in practice, since external search engines are very efficient.

> - no responsive design, tiny text and horizontal scrolling on mobile phone screens

Again, a client issue. Get a better e-mail client.

> - sends you your password in cleartext via e-mail

Yes, many lists do this, but this is not a requirement of the technology. Some lists could require all your mails to be signed with PGP or S/MIME; it is entirely up to the list.

> - actually complicated to unsubscribe from a list / manage your membership

Not really. The ”List-Unsubscribe” header is commonly sent in every mail to the list.