Hacker News Reader

Comment by mschuster91 | Hacker News Reader

> Mailing Lists are decidedly democratic, and have least barrier to entry.

Oh no, they are not. I loathe projects that only do mailing list support, because that means I have to subscribe to the mailing list, create a new folder and filter rule so that the mailing list doesn't flood my inbox with stuff I don't care about, and once the problem is solved, leave the mailing list, remove the filter and folder.

In contrast, issues on GitHub/GitLab or public self-hosted GitLab instances only require me signing up once (and in most cases via some form of SSO), I can add attachments such as screenshots or detailed logs that would just blow through the ridiculous size caps on mails, and I only get notifications on topics I explicitly subscribe for.

View on HN

In most cases, you can send to a mailing list without subscribing, and people will include your email when they respond. I've filed multiple bugs this way. It was as easy as sending an email and attaching a patch.

Whenever I tried interacting with mailing lists in the last five years, I always needed to subscribe or wait for days for someone to moderate the spam queue.

Anti-spam measures are a large part of what made using MLs so annoying. From a moderation side, MLs are more work for that reason as well - Github and Gitlab at least get rid of spambots shilling shady cryptocurrencies, weenie enlargeners or questionable quality designer drugs. With MLs, all of this ends up in your moderation queue as well.

My personal experience has been very opposite.

All the relevant mailing lists for my interest projects have web interface/archive, I can selectively reply/participate in any or no ongoing threads, and stop at any time.

"I have to subscribe to the mailing list, create a new folder and filter rule"

That's a workflow problem on your side. Why is it so hard? Maybe your mail user agent isn't configurable?

"In contrast,"... "me"... "I"... "I"... "I"...

Every one of your proposed advantages are not about the community's health, but about your convenience and ability to ignore the community as a whole.

It's fine that you have a preference, but claiming that your preference is more democratic is incorrect.

> Every one of your proposed advantages are not about the community's health, but about your convenience and ability to ignore the community as a whole.

What makes a ML based workflow better for a community?

> It's fine that you have a preference, but claiming that your preference is more democratic is incorrect.

Most development is not done over MLs, that's a fact. The percentage of ML-based development done over time is shrinking. So I'd say the democratic vote is not one in favour of MLs.

> Every one of your proposed advantages are not about the community's health, but about your convenience and ability to ignore the community as a whole.

You were talking about MLs being more barrier-free than "friendly interfaces". I showed why that is not the case. The effort required for dealing with MLs is way higher.

Reply on news.ycombinator.com