I am an Emacs enjoyer. My biggest issue with Emacs is that development is still done via a mailing list and patches. I wish they would adopt a Git front-end (web UI) workflow.
There's probably also a lot of emacs contributors that use emacs as their mail client that would be disrupted by replacing it with something web based.
The "next generation" of Emacs contributors will be Emacs users and will not have any issues using email for collaboration.
Git was made for email. Needing a separate service for it is mostly cruft, when you have mailing lists. Yes, github has mass appeal, but a lot of software has been written with just email collaboration.
As for attracting low-quality contributions, I don't think they matter. People who use Emacs and depend on it will contribute. Interest in Emacs has increased and so have the available features.
This! I'm happy that Emacs isn't the greatest editor or the most-used/-popular; it needn't compete with say VSCode or vim.
There's a decent, loyal user base, importantly not the free-loading, entitled kind who water it down; they're like-minded, appreciate the philosophy behind it, don't mind tinkering with some LISP here and there, contribute their creations as answers or packages, and above all form a nice community helping each other.
As lazy as it seems, I’ve made a couple contributions to Neovim whereas I probably wouldn’t have bothered if I first had to figure out a mailing list flow.
Personally, I think that it's the copyright assignment that's the biggest barrier. For someone who figured out how to use Emacs, it shouldn't be very hard to figure out how to use a mailing list too.
This. A mailing-list-driven workflow is not as difficult as it appears, and Magit makes everything a breeze. However, I cannot complete the copyright assignment process, and consequently I am unable to contribute to the Emacs proper beyond a few lines of trivial changes.
It is so discouraging that I stopped working on the Emacs core [1] altogether: your contributions won't be acknowledged at all, even if someone volunteers to rewrite your code from scratch.
[1] I've been hacking some GUI-related features, but I'm not motivated enough to complete them. I also tried to write patches for my bug reports, but alas, my "CA-free" quota is already used up.
This is absolutely true and is one of the stronger arguments for the Linux kernel to adopt something like GitLab as well. Being able to take PRs for smaller contributions while still keeping core development on mailing lists (probably with an email bridge between so things aren't missed) seems ideal to me, but that's extra work for maintainers and whatnot
> There's probably also a lot of emacs contributors that use emacs as their mail client that would be disrupted by replacing it with something web based.
The further I get into "emacs for everything" the more I appreciate using email for everything.
As an occasional developer of PostgreSQL which also does development on the mailing list I see pros and cons with it. It is harder to discuss lines of codes in a review on the mailing list but the nature of the mailing list (threading, etc) promotes much more nuanced and constructive discussions about patches on a higher level. Something which I have yet to see in any project on Github.
Gitlab has some threading support but not very good one.
https://git-send-email.io/ has a great tutorial for getting started.
There's probably also a lot of emacs contributors that use emacs as their mail client that would be disrupted by replacing it with something web based.