No way to vote on comments, no formatting or embedded images (which work with all clients, including the web UI), no way to edit comments after you've posted them, no easy way to subscribe/unsubscribe to just one individual thread... need I go on?

> Unlike your examples of GitHub and Gitter, they're unencumbered FOSS

So use GitLab and RocketChat then.

> It also has advantages of being federated, accessible offline, easy to write bots for, etc.

Fair point. I think RocketChat is working on federation, and GitLab and RocketChat both have well documented APIs, but for the most part you're correct that email is superior in these points.

> I don't see any dichotomy between using email and having a nice UI. I certainly find my email UI (Emacs + Mu4e) far nicer than any Web site I've ever seen.

That may be true for you, but not every new developer is going to come into your project with that kind of setup. They'll be reading your plaintext, hard-wrapped emails on Outlook or Gmail while struggling to set up filters so they only have to read emails from the mailing list about threads or topics they're actually interested in. A web UI ensures everyone has a great user experience right out of the gate.

> As for GitHub pull requests, I've never actually seen the appeal.

All the advantages mentioned in my response to "what's wrong with mailing lists" above, plus inline code review, immediate feedback from CIs, linters, and code coverage analysis tools, and integration with the issue tracking system.

> Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; when I could instead run `git send-email`?

Personally I've never found the process of creating a fork to be any sort of inconvenience. Maybe you'd be interested in the `hub` CLI though: https://hub.github.com/

Good. Speak your piece if you have something to contribute. It's easy to game upvotes; oh look lots of upvotes... oh it's a pointless fluff comment or a flame. Above all, that stuff adds complexity to the system, and no one has shown the value is real versus perceived.

> No way to edit comments

People should consider what they're about to share. Editing is like starting a company and figuring out your business model after you "reach scale". Having to think before you say something is not a bad idea.

> So use Gitlab and rocketchat then

Yes, make everyone else move over to these new things! Because needing an email address isn't enough. We need accounts with every service there is! And we need more UI's distracting us with notification bubbles!

And let's get all these devs to learn all these new tools. Rather than focusing on producing useful output. Sounds good.

Sending patches by email requires an email setup that works. You have, loosely, three options: you can send it in your normal client, you can set up `git send-email` to submit over SMTP, or you can set up `git imap-send` to get it into your normal client's drafts folder. If you choose the first one, your client has to preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact. If you choose the second two, git has to be able to auth to your email server, and nothing else along the way can break the byte-for-byte integrity of your email. Each of these is tricky in various ways; see https://www.kernel.org/doc/Documentation/process/email-clien... for a discussion. (It turns out that email between humans does not depend on byte-for-byte integrity of whitespace.)

That's a lot of reading and fiddling for devs who are busy trying to produce useful output!

I recall that if your current email address is behind Microsoft Exchange, you simply can't use it for patch submission - the Exchange outgoing SMTP server does something weird with spaces, even if you don't use Outlook and connect directly to it with git send-email.

Now, certainly that might be Exchange's fault, but it doesn't change the fact that you'll need to get a new account to submit patches.

Emailing patches is just as hard as making pull requests.

Hmm, sounds exactly like a use-case for Base64 and/or mime attachments. Perhaps it's worth persuing this, if there's no existing support?

That's either an argument against encoding patches, or for reading email in Emacs (M-x base64-decode-region). I don't suppose many would take the latter stance ;)

An email client which doesn't do that is broken; why would one use a primary email client which is broken?

(Yeah, it's a rhetorical question: I'm using an app client these days like everyone else, but I hate how broken it is)

In which case, yes, you can set up a personal email address, but that just reduces it to the previously unsolved burden of having to set up another account just to contribute to a project.

That may be true for you, but it's in no way as universal as you seem to think.

I have a productive workflow (that gives me enough free time to comment on HN :-) that is effective for the several things I work on during the day (a couple of development projects, some management, etc). Hopping over to some web silo doesn't speed things up for me.

The real reason people stick to the current model is because it works. A common baseline lets people use the tools that work for them rather than trying to cram everyone into the same procrustean tools space.

That said, switching to something like GitHub doesn't necessarily mean developers all _have_ to use exactly the same workflow. For example, if you're more comfortable in the command line, there are tools like [hub][1] and [git-gitlab][2] available which let you perform common tasks in GitHub/GitLab using the CLI.

I just think that long-term it's better to have a good baseline user experience that devs can then extend with their own personal tools if they choose than to have a not-so-great one that _requires_ you to extend it with your own tools before it's anywhere near as good as what a well-designed Web UI provides out-of-the-box; even if in the short-term that means breaking some dev's workflows.

Obviously that doesn't mean you shouldn't try to maintain compatibility with developer's existing workflows wherever possible though. For example, GitLab and GitHub both let you reply to issues by email, and RocketChat has an IRC plugin that lets you connect RocketChat rooms to an IRC channel.

[1]: https://github.com/github/hub

[2]: https://github.com/numa08/git-gitlab

But your note feels like you're saying "why don't the kernel dev switch to Ruby?" Of course when I say it that way it sounds absurd, but really it's simply an equivalent.

The point is that reducing the friction required to contribute to an open source project is a great way to attract new contributors. Using more user-friendly dev tools is a great way to do that, and is therefore something existing maintainers would be wise to consider doing.

Yes. Because that's true. Either you have a good point and manage to convince people in the project, or you have to fork.

Writing irrelevant comments on some news site is not going to convince anyone to spend a combined hundreds to thousands of man-hours work (at the very least) to move kernel development to GitHub or whatever platform you like.

Also notice how you are ranting about tooling in a project you're not contributing to, while the submission here is about something entirely different -- and written by a contributor.

So don't.

Do you have a single compelling issue why they should switch?

I mean, you can do a lot of amazing stuff in a TUI, but at this point I'm fairly sure that I only like them out of Stockholm syndrome.

Last point aside, these are all in favor of mailing lists, you know.

Voting is absolutely important. It makes it easier to gauge the community's reaction to issues, PRs, and comments, and cuts down on "me too" type comments which might otherwise clutter issues.

> plaintext is easier to deal with than markdown

Markdown _is_ plain text. I've been writing all my comments up to this point in Markdown. Did you notice?

> Plaintext works in a terminal and with embedded patches and inline replies and so on.

So does Markdown. The difference is that Markdown can _also_ be rendered as pretty, fully-formatted text in a web browser.

I have a few blind users who would heartily disagree with this point considering most 'modern' web UIs totally break any sort of reader usability.

For a project that needs to last more than 5-10 years, using really boring (fossilized?) communications archive tech is a feature, not a bug.

New contributions require a person to forego the conveniences which the fossilized tools don't support well, and that friction _might_ contribute to fewer smart people wanting to contribute to your project. Consider as the OSS world's equivalent of a sales funnel. The more I need to deviate from the way I normally work, the less likely I am to want to make that contribution.

For a project where the overloading of maintainers is an issue, it might be worth considering the value of making it easier for other people to contribute. Sure, smart people who want to contribute _can_ adapt to the way your project wants them to work, but not all of them will want to jump through that extra hoop.

I think I'd rather not have my kernel code written by someone who is afraid to use an email client.

Email is not, FWIW, fossilized. It's far superior to GitHub or Slack, because it's decentralised and truly free.

- multiple clients on multiple platforms

- multiple clients on emacs (e.g. Gnus, mu4e, NotMuch)

- does not require a browser, ever

- does not require executing untrusted code on my computer, ever

- open protocols

- multiple servers on multiple platforms

- federated

Github, Slack et. al.:

- may have a decent text-only client (e.g. there's a Slack mode for emacs, and there are some GitHub clients out there, which may or may not be convenient)

- strongly encourage and sometimes mandate use of a browser with execution of untrusted code allowed

- protocols controlled by a single organisation, with no possibility to add functionality on the server side

- servers controlled by a single organisation

- no federation

- fundamentally proprietary

What I value: freedom; TUI clients; emacs clients; open protocols; being able to run my own service.

I can't speak for others here, but personally I treat freedom as my first priority: it doesn't matter what features a platform offers if it doesn't offer freedom, because I will not use it if it doesn't offer freedom, therefore I'll never see any of those purported features.

If I have the choice of a) contributing to the latest hippest JS browser framework right away, or b) spending several hours setting up a custom email-based work environment, then contributing to the driver for my bleeding-edge Skylake system, I know what I'm going to choose - despite having way more experience with kernel hacking (in a corporate, GitHub-Enterprise-using environment).

Again, I'd rather have my kernel code written by someone who has respect for others, and doesn't view spending a little time learning how to be productive in a group as 'jumping through hoops to learn the obscure workflow of an old community.'

> If I have the choice of a) contributing to the latest hippest JS browser framework right away, or b) spending several hours setting up a custom email-based work environment, then contributing to the driver for my bleeding-edge Skylake system, I know what I'm going to choose - despite having way more experience with kernel hacking (in a corporate, GitHub-Enterprise-using environment).

That's a-okay by me.

Over time, the number of people who are _willing_ to learn your conventions, versus those who _want_ t o use those conventions, may change. You may have several colleagues (and many more who have not yet contributed) who are willing to use email, but would prefer a web-based collaboration platform.

Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail. Rejecting those out of hand as "not productive" seems a bit strange.

Very true! And certainly not all change is bad, and not all new things are worse than their older analogues.

> Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail.

True enough, but I wonder how much of that is not because they are fundamentally better but because email has gotten popular. I can't easily review source code via email because I have to wade through meeting invites, corporate communications and recruiter spam.

Honestly, though, GitHub doesn't really give me a whole lot, other than centralised issue tracking and a data store. I never use its git UI; I just use Magit locally. I've actually been thinking about how a team could use commands to manipulate text files in a git repo to manage history for that repo — then one would never need to leave one's editor to manage issues. With a central file server open to users, merges and PRs could just be operations on the repo itself.

My idea's not fully fleshed out, but I think it'd be awesome, and more productive that using GitHub via a web browser.

Strongly disagree. As a general observation, people who don't have the patience to learn community norms generally don't have the patience to follow coding styles or write tests or properly document their code.

Do developers really think that way?

I know if I'm going to invest 50+ hours of my time on an activity then an hour or two to get setup is no big deal.

You...do realize that a patch email and subscribing to a mailing list isn't exactly something that should take "several hours", right?

In this sense, having a developer mailing list is like FizzBuzz for potential contributors- if they can't handle the easy stuff, they definitely won't be able to effectively contribute as software developers to a nontrivial project.

Another nice thing about email is that in practice, it's a slightly more formalized form of communication. Lots of people write terrible emails, but lots more people type terribly written messages into little boxes on web sites. The nature of the medium (in my experience at least) is such that people are much less likely to treat email like chat than they are to treat web forums like chat, and they're much more likely to make an effort to communicate effectively, which is absolutely critical for successful distributed development.

Finally, I think people forget that it's not necessarily a net good for the users of an open source project to have the most frictionless mechanism possible for interacting with or sending patches to the developers of those projects. People who are new to open source, especially if they're new to software development in general, sometimes have this ideal that more community is always better than less community, and more communication is always better than less communication, and more patches from the community are always better than fewer patches from the community, but I don't think this is true at all. It's very dependent on how the project is run and the goals of its developers. It can be a net good for the whole project to have some hoops that people have to jump through before they can start pestering the developers with patches, and email is about the most trivial hoop there is. Lots of projects intentionally erect many more barriers than that, and that's not necessarily a bad thing. The goal of most open source projects is to produce high-quality shared software, not to be a social experiment with the lowest possible bar for involvement.

Can you cite any study evidence that suggests that these are helpful features in this context (or even that they aren't massively harmful? Comment voting in particular appears to be an especially strong source of toxicity and online forums that feature it prominently have a pretty reliably history of going down in flames after a few years).

Didn't he invent it after the sword had fallen and the BitKeeper people withdrew their permission to use it? I get the impression Torvalds is fine with proprietary tools if they're significantly better than the free alternatives.

Yes, perhaps I should have been more specific that the sword (BitKeeper as gatekeeper) was the problem, rather than the "hanging above" (i.e. the threat rather than the actuality).

* They have no relation to code. It's difficult to discuss patches. * I don't want to make my email public (mailing lists are public). * The interface for threaded conversations is almost always terrible. * It's trivial to get your concerns ignored. This is much harder will pull requests (but still possible).

> UI-wise, each dev is free to access their mail however they like.

If they all suck equally, I'm not sure this is a good thing. I certainly don't want to waste my own time coding around the deficiencies of a medium that wasn't built for holding complex conversations.

> As for GitHub pull requests, I've never actually seen the appeal.

Well, they make it super easy to leave comments on code and iterate before accepting. I've literally never seen this happen quickly via a mailing list: it's either poor quality when it's accepted, or it takes forever to merge.

Most of all, though, if I need to figure out how to generate and mail a patch, I'm not going to even bother looking up the mailing list: I know it's not worth my time. This is exactly the type of problem git is good at solving; why resist?

GP's argument can be applied to GitLab (eg: more "friendly" for new devs), and is FLOSS, and can be self-hosted. Interaction via email is also possible.

Because noone wants to see or deal with your cruft, or that of the thousands of other people also contributing to a large project. Keep it in your own private space until it's accepted as being actually part of the project.

With the pull-request model, there's a lot of Github-specific folderol necessary to accomplish the same task. Perhaps the pull request process offers some significant benefit for the maintainers, which I haven't been able to see, but whatever it is, it must be weighed against the fact that the complexity of the pull-request process creates a barrier to entry. I can think of two situations where I had enough interest in contributing to a project that I downloaded the code and diagnosed the issue that was bugging me, but gave up when it started to look like it was going to take an hour of extra github hoop-jumping and potentially days of review and testing process just to share my one-line fix.

If I'd already been a participant in those projects, dealing with the process might not have been such an issue; but as an outsider, the pull request work flow is a pretty clear "get serious about joining our project, or go away" message. So, I went away. Perhaps those projects will fix those bugs themselves, eventually.

I don't understand; is a clone on my laptop not my own private space?