There is no need for mega forges with millions of projects and tenths of millions of people ruled by a centralized power. ☠️
They must vanish and make room for thousands of small forges communicating with each other. 🤝
@dachary @forgefriends @hostea @forgefed Thanks. But is it really required to open an account on forge just to file a bug report or send a patch? This is especially painful when new accounts needs to be approved by the admin. (👀 #framagit) Isn't an email enough? This is not to say that fork-commit-pull workflow is bad, but any forge should also have a patch and email based workflow, so that we don't need an account just to file a bug or to submit a patch. (👀 @codeberg @gitea)
@akib @dachary @forgefriends @hostea @forgefed @gitea there is no reply-via-email feature in gitea yet (but open issues/feature requests?). To the best of our knowledge reply-to-issues-via-email only works for registered accounts? This would be different from what asked above (send requests without identity), and ofc a desired feature!
@codeberg @gitea @forgefed @hostea @forgefriends @dachary @akib The #gitea bug tracker is quite sadly jailed in MS Github! Otherwise it would be useful for us in the free world to contribute to #2386 & #13442. So I will just put my comments right here. The way to support email in a spam-resistent way is to automatically process #email that has been PGP-signed by a key that sits on the pubkey ring with a web of trust that reaches /someone/.
@akib @dachary @forgefriends @hostea @forgefed @gitea @codeberg This approach can kill a flock of birds with 1 stone, by creating incentive for people to actually use PGP, not only adding authenticity to their comments but also reducing server-side/project-side janitorial work. Unsigned email could go into a moderation box, where it could sit a long time, thus creating disincentive to not use PGP, which in turn eases moderation duties.
@akib @dachary @forgefriends @hostea @forgefed @gitea @codeberg It would also be useful to incorporate #gitbug (https://github.com/MichaelMure/git-bug). IIUC, someone could create a new bug report within git, and then submit it upstream. Not sure if that’s done by PR but it should be looked at because it would make repos more portable, as the bug tracker data should migrate with the code in a migration anyway.
@aktivismoEstasMiaLuo @codeberg @gitea @forgefed @hostea @forgefriends @dachary I think it would be better to send PGP-signed message directly to the list and the unsigned ones to the spam filtering program and notify the sender that their mail went the spam detector, recommend them to sign and/or encrypt any new message, and provide links to some tutorials (https://emailselfdefense.fsf.org/).
@akib @dachary @forgefriends @hostea @forgefed @gitea @codeberg Since you mention a list (assuming you mean mailing list?), how about this hybrid of all ideas: bug reports/comments go to an account that checks the sig (perhaps using a #procmail script). If the sig checks out, the msg is automatically submitted via #gitBug to the upstream git db. If the sig fails or is non-existent, the msg goes to a mailing list.
@codeberg @gitea @forgefed @hostea @forgefriends @dachary @akib If someone on the list reads the msg and decides it’s not spam, they can resend with their own sig on the msg, but somehow flag it to say “this bug comment is not endorsed by the signer, but validated as non-spam”, at which point it could go to git-bug to be incorporated into the db.
@aktivismoEstasMiaLuo @dachary @forgefriends @hostea @forgefed @gitea @codeberg The newbie friendly mail clients, especially those which sends HTML mails by default. I never understood the advantages of email until I switched to #gnus on #emacs. There are also other great mail clients like #mutt, #notmuch, #mu4e, etc.
@akib @codeberg @gitea @forgefed @hostea @forgefriends @dachary The sig-failing msgs could also be spam-scored as you suggest, before forwarding to a mailing list. And in that case, it should probably have a high spam score tolerance so that the machine does not have false positives, as the ultimate judge is the list readers.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!