- pushing branches to your own fork so that others can see your work while it's in draft form

- opening PRs against the main project, and writing a nice PR introduction describing the changes that you've made, their background, and motivation, drawbacks and hesitations, etc.

- participating in a feedback conversation with the maintainers and other developers with comments attached to specific lines in the code (at a specific revision), as well as attached at diff level

- having the project CI run against your branch to check that all tests pass, across a collection of different OSs and architectures. (You can also run their CI in your own fork to check it works there before even opening a PR).

- opening Issues, and discussing with other developers

- and many other things

- having the ability to write your text comments along with images, videos, and syntax-highlighted code fragments.

- Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing.

- Send an email to the development mailing list, making sure to write a nice introduction describing the changes that you’ve made, their background, motivation, drawbacks, hesitations, and so on.

- participate in feedback conversations with the maintainers and other developers with comments situated next to quotations of specific lines of code from specific revisions or specific diff hunks.

- Just run “make check”. 99% of all of the code in Emacs is written in Emacs Lisp, which is platform–independent. If the tests pass on your own computer you can rest assured that they will pass on everyone else’s too.

- sending emails to ask questions and discuss them with other developers

- feel free to include any type of media in your emails, all but one participant in the mailing list can view them

- and many other things

This is the 'we have PRs at home' point of view.

It's not WRONG, but I think it does miss the point. 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer.

The project is well within it's rights to do so, but, there's a reason GitHub specifically is super popular, and it's mostly to provide structure and avoid the pain in the neck that the 'do it by email' and 'just use these different things' approach while collaborating.

Following the herd is definitely the wrong answer.

I recommend a client called Gnus, which can score messages based on their content, and then sort by that score. That way messages about things you are interested in (such as your own patches, features that you care about, etc) float to the top.

Gnus doesn't look very user friendly

I think the design goals of Gnus were not about allowing the user to get started quickly by having the same buttons as every other email client, but instead empowering the users to extend Gnus so that it does what they want. As a result, it may take longer to learn how to use Gnus but the ceiling is much, much higher.

However, for bulk sorting of email I should actually have mentioned Sieve. It’s a standardized configuration language you can use to tell your server how to sort your mail, so that it is already done before your email client even logs in. Most IMAP servers support it, and it is pretty easy for email provide access to it.

You can write simple rules like this:

    if address :is "From" "[email protected]"
    {
        fileinto :create "INBOX.Bugzilla";
    }
    elsif header :contains "list-id" "emacs-devel.gnu.org"
    {
        fileinto :create "INBOX.emacs-devel";
    }

My current email provider is Fastmail. I discovered after I signed up that most of their mail–filtering settings get turned into Sieve rules that are shown to you when you go to add your own rules. I really like this because you can see exactly how spam is handled, how your vacation responders are implemented, how email from blocked senders is discarded, etc, etc.

Gnus flow: signup for mail service that lets you use a bunch of other gnu tools and client side software you have to install on every machine you want to do any kind of collaborative work from, write some code to filter your email, etc., etc. and then figure out the individual mailing list nuances (patches go here, discussion here, etc. - they're all potentially unique and beautiful snowflakes!).

I'm not trying to yuck anyone's yum, but you being the only user you care about is specifically why GitHub has become what it has. They care about all the potential users :)

I've used Gnus. It's crazy powerful. But it is not simple to configure. Using notmuch + Python scripts for filtering is way easier, and even that is more than what 95% of developers are willing to do.

BTW, Sieve beats an ad–hoc Python script any day of the week :)

Email is superior to web applications. It's simple text. I would argue the reason Github is so popular in your context is that it's good for the masses, and they don't care to find out how to write a proper email.

I'm happy with the end result though as in my opinion, what you all call a limitation is akin to a selection process where devs who prefer web apps to standard internet protocols are elliminated.

P.S. Please bring back usenet and rm -rf all online web forums, come back to IRC and drop all the slack-like alternatives that spread communities apart so much so that they are almost all inactive and useless.

I say, shame on the web!

Not sure what feature parity would look like… Neovim has had a built-in LSP client for quite a while.

I do agree that the community around Neovim feels super inviting.