Hacker News Reader

> No way to vote on comments

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.

Speaking as someone who has gotten a small number of patches into the kernel (via email, naturally), the implication that sending patches by email requires no additional accounts or tools or learning is a false one.

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.

GMail also turns tabs into spaces when sending plaintext emails. I shouldn't have to set up a mail client to contribute.

Emailing patches is just as hard as making pull requests.

> If you choose the first one, your client has to preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact.

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)

Sometimes you don't have a choice and all you get is your school's or employer's email service, which can be arbitrarily crappy. Services that are crappy enough to cause problems include Gmail and Exchange, which are probably used by 90% of schools and employers. (Gmail SMTP only saves you if you can auth to Gmail SMTP; if G Suite is set up with some SSO and with app-specific passwords disabled, this can rapidly get annoying and potentially impossible.)

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.

> preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact

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?

Yeah, but the intent of sending patches by email is that you do code-review by hitting reply and commenting inline. If you have to import the patch into your local git repo, or build tooling for seeing it in your email client, you're strictly worse off than with a web-based code review system.

> If you have to import the patch into your local git repo, or build tooling for seeing it in your email client, you're strictly worse off than with a web-based code review system.

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 ;)

> A web UI ensures everyone has a great user experience right out of the gate.

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.

Yeah, I realize a lot of devs have already have their own setups that work extremely well for them. Unfortunately anytime you transition to a new tool you're obviously going to break _someone's_ workflow.

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

I feel like you're addressing a nonissue. If you want to start your own project, you can set the standards for development process, coding standards, language, etc. If I don't like those choices it's no big deal and no slur on you: I'll just work on what I want and folks who agree will be delighted to work with you.

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.

By that reasoning though, isn't almost every problem in open source projects a "non-issue", because you can always just fork and do things your way?

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.

> By that reasoning though, isn't almost every problem in open source projects a "non-issue", because you can always just fork and do things your way?

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.

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

So you're saying we shouldn't discuss this at all? Just shut up and stop trying to convince anyone to adopt a viewpoint I believe would be beneficial to open source projects in the future?

IMO open discussions like this are a good and healthy thing for any community of developers (such as the one on Hacker News) to have. It's a great way to share ideas with each other and collectively come up with ways to improve the open source community. It's not something that should be discouraged.

> Yeah, I realize a lot of devs have already have their own setups that work extremely well for them. Unfortunately anytime you transition to a new tool you're obviously going to break _someone's_ workflow.

So don't.

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

Yes. All of the benefits I mentioned in my previous posts further up in this thread. It all essentially boils down to making it as easy as possible for new potential contributors to contribute.

New potential contributors to a kernel that are deterred by not having a ruby-on-rails web GUI wouldn't have contributed anything anyway. (IOW there are none that fit you description).

No kidding. I'd say a web interface sets a ceiling for how good the interface can be. And 99% of the time it's an awfully low ceiling.

...As opposed to, what, a native application? A TUI?

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.

As opposed to a mailing list based interface which allows everyone to read and respond with the tooling of their choice.

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

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

What? Why? All of those are extremely useful features I find myself missing whenever I'm forced to use a platform which doesn't have them.

It's not for your sake, it's for the sake of the maintainers that have to deal with your code.

Why would allowing developers (maintainers included) to post, vote on, and edit formatted markdown comments make it harder for maintainers to deal with my code?

Because voting isn't important and plaintext is easier to deal with than markdown. Plaintext works in a terminal and with embedded patches and inline replies and so on. You don't grok it, that doesn't make it worse.

> Because voting isn't important

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.

Is it possible to get the plaintext of comments from GitHub or the other platforms you prefer?

Yes, using the API you can get the raw plaintext in both Github and Gitlab, at least.

You have to understand that you have a severely different outlook on FOSS maintainership than these projects do. You simply don't grok it. It's not like the maintainers here are unaware of the alternatives.

"A web UI ensures everyone has a great user experience right out of the gate."

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.

Yeah sorry, I should have phrased that as "a well-designed web UI". It's certainly not impossible to create a modern web UI which works well with screen readers.

You're missing the core point: mailing lists are simple, they require no vendor or stack lock-in, and their quirks are well-known.

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.

Using fossilized communications tech, while ignoring the conveniences embraced by nearly the entire rest of the FOSS community, optimizes for the comfort of the Current Developers, while making it less convenient for New Developers to contribute.

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.

> Using fossilized communications tech, while ignoring the conveniences embraced by nearly the entire rest of the FOSS community, optimizes for the comfort of the Current Developers, while making it less convenient for New Developers to contribute.

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.

Could you show your work? You're valuing "decentralied and truly free" as significantly more valuable than (far superior to) the sum total of GitHub Slack features. Could you list out the GitHub Slack features that you considered (and which ones you didn't consider) and your heuristic for their value and how they all combine to be much, much less valuable than decentralized/free?

Email:

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

You listed only positives for Email and only negatives for Github etc. but you implicitly made the claim that decentralization and freedom are more valuable than all of slack and Github's features combined. Or are you saying that the value of everything except your "what I value" list is zero, so all of github/slack's objectively useful features are weighted to zero in the calculation?

> you implicitly made the claim that decentralization and freedom are more valuable than all of slack and Github's features combined.

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.

Forget "afraid". Developers have better things to spend their time on than 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).

> Developers have better things to spend their time on than jumping through hoops to learn the obscure workflow of an old community.

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.

And I'd prefer to have my kernel code written by a community that cares about its long-term health and efficiency rather than respect.

That's true, but the same respect-for-others is valuable in the other direction.

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.

> That's true, but the same respect-for-others is valuable in the other direction.

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.

> Developers have better things to spend their time on than jumping through hoops to learn the obscure workflow of an old community.

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.

> Developers have better things to spend their time on than jumping through hoops to learn the obscure workflow of an old community

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.

> spending several hours setting up a custom email-based work environment

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

Simple is not easy.

Mailing lists are a nightmare for newcomers. That's why they progressively disappear.

Maybe that's a feature? If something as simple and straightforward as a mailing list is a "nightmare" for someone, I certainly wouldn't want kernel patches from that person. If they don't have the patience/tenacity/knowledge/whatever to deal with email, then they sure as heck don't have those qualities in sufficient quantities (yet) to produce more signal than noise in an open source project.

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.

> 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

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

... he wrote, on a forum that's existed for 10 years now, with few problems with toxicity.