> 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer.

Following the herd is definitely the wrong answer.

Well, GNU does make both.

Ok, that made me laugh.

Following the herd absolutely can be the right answer. Especially if the question is how to reduce friction for contributors.

Everyone already has email. Not everyone wants to sign up for yet another web service. Email _is_ the low–friction option. Emacs even has a built–in way for any user to report a bug: just run `M-x report-emacs-bug` and it will give you an email template to fill out right there in your editor. No need to even open a separate program.

Everyone has email. Yet less than 5% of developers have set up email workflows so that they're not drowning in patch/mailing list emails. Organizing one's email does take a fair amount of effort - an effort that you don't have to make using services like Github.

Configuring your email client to sort and categorize your emails for you should be easy. If it’s not easy for you, then I suggest that you are using the wrong email client. Also, I note that Github emails you every time anyone interacts with your pull request, just the same as if it were a mailing list.

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.

Would you enlighten us what email clients are so amazingly good, because everything other than Mail.app is a traumatizing experience that I'm trying to avoid.

Gnus doesn't look very user friendly

I really only know Gnus; it’s been a decade or two since I used anything else. I am also not really sure how to judge user–friendliness in this case. Now that I have customized it to my liking, Gnus displays exactly the information I want and has exactly the operations I want bound to keys that I like. That makes it very friendly to me, the only user I _really_ care about.

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";
    }

and so on until all of your mail is sorted how you want it. It’s not a full programming language, so it cannot do everything, but it’s quite capable and pretty well standardized so you can take your filter rules with you if you change email providers. I use it even for simple rules like this so that all I need to do is paste them in when I move to a new provider. One doesn’t need to do that very often, but it only takes seconds to do instead of minutes or hours to reenter every filtering rule in a new UI.

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.

GitHub flow: sign up and provide a username/password, magic happens and collaboration is easy

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 would argue that Github does not care about individual users. They treat everyone exactly the same, and not well at all. Any project relying on Github faces existential risks that simply don’t exist otherwise.

Pushing Gnus is immediately losing 99% of developers.

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.

I can only recommend Gnus, because I don’t know any other email clients. I agree that it isn’t for everyone. In this case I recommended it because someone claimed that they couldn’t use email for development because they would end up spending all of their time managing their email. I’m confident that Gnus’ scoring feature would fix that, but at the same time I don’t really believe that the complaint was a genuine one; all email clients have some form of filtering that can do 90% of the work for the user. And most servers support Sieve, which works regardless of what client you use.

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

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

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!