3 ms·

As someone who formerly used to be in no-ML camp, I am proudly converted. Mailing Lists are decidedly democratic, and have least barrier to entry. It is also te

As someone who formerly used to be in no-ML camp, I am proudly converted. Mailing Lists are decidedly democratic, and have least barrier to entry. It is also technically superior in providing unified interface to patches, communication, bug reports and everything adjacent. Compared to that any fancy service provides lock-in under thin veil of "friendly interface".

robert_foss 4y ago
I think most developers would find it easier to contribute to a github/gitlab/gitea project than a ML one. Besides, there are definite downsides to like MLs, like CI integration and pulling patches to local trees. Now, there are strengths too. Like being archived easily & having threaded conversations integrated.
- e3bc54b2 4y ago
  CI can definitely done on mailing lists. The interface is bit worse than PRs, but I'm sure with enough imagination that can be overcome. Pulling local trees has been absolutely better IMO with mailing list. I can literally with single keybinding apply patch to relevant repo, something that takes much longer route with Github. (convert URL to raw.github/whatever, copy and paste to apply, or do clicky-clicky in the Github app or whathaveyou)
mschuster91 4y ago
> 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.
- dsr_ 4y ago
  "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.
  - robert_foss 4y ago
    > 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.
  - mschuster91 4y ago
    > 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.
- sleepydog 4y ago
  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.
  - mschuster91 4y ago
    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.

robert_foss 4y ago

I think most developers would find it easier to contribute to a github/gitlab/gitea project than a ML one. Besides, there are definite downsides to like MLs, like CI integration and pulling patches to local trees. Now, there are strengths too. Like being archived easily & having threaded conversations integrated.

e3bc54b2 4y ago
CI can definitely done on mailing lists. The interface is bit worse than PRs, but I'm sure with enough imagination that can be overcome. Pulling local trees has been absolutely better IMO with mailing list. I can literally with single keybinding apply patch to relevant repo, something that takes much longer route with Github. (convert URL to raw.github/whatever, copy and paste to apply, or do clicky-clicky in the Github app or whathaveyou)

mschuster91 4y ago

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

dsr_ 4y ago
"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.
- robert_foss 4y ago
  > 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.
- mschuster91 4y ago
  > 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.
sleepydog 4y ago
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.
- mschuster91 4y ago
  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.