If I don't like the existing user interface to a standardized machine-readable protocol/format, I can write my own user interface for my own needs, as can anyone else, which has two big advantages: People with different needs can have user interfaces that match their respective needs, even while working on the same project, and that leads to easier innovation (when people share their respective solutions).

Now, github currently provides the low-barrier solution that seems to be good enough for many people, which is why the development of tools for email-based workflows is stagnating, instead building more lock-in for github, and preventing any serious improvement in workflows.

So, your hate for email is for practical reasons, but those practical reasons are not inherent properties of email, but rather the result of github trying to capture the market for later exploitation, and you are happy to help them for the momentary convenience, while probably not realizing how much potential convenience you are missing out on as a side effect.

https://api.github.com/

First of all, github is not the web, and much of the web does not have an API (and I don't have a clue how good the github API is).

But more importantly, even if they have an API: Is there any legally binding committment on their part that that API will be a reliable basis for me to build on for the next 20 years or so, assuming they still exist then? Won't they change it as it suits their needs, in particular their business needs?

A "programming interface" that I can't rely on in the long run is still kindof a user interface, as I have to bother with it whenever it changes. It's a real programming interface only if I can build an abstraction on top of it and essentially forget the layers beneath.

This is how you submit a patch via github: 1. Clone the repository locally 2. Make the fix 3. Fork the repository on GitHub 4. Push your changes to your GitHub fork 5. Go through several screens to make a pull request on GitHub.

(This is assuming you have a GitHub account. If you don't have one, or if you don't know its UI well, insert several more steps in the middle.)

For a casual contributor, sending a patch via email is quite easier than doing it in the web. There are of course downsides to both approaches, but please don't pretend that there are no reasonable objections to web UIs.

Or see Manishearth's comment above.

Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial. Yeah, you gotta know Git, but at least Github has nice easy buttons to guide you through doing things.

It's been said. You do it with a service built upon the traditional currency of open source: patches. GitHub-style pull requests are not an intrinsic requirement even for the kind of shiny web UI that GitHub wanted to build. It was, however, an important part of GitHub's lock-out strategy.

If you build your startup so that the way that person B has to get their changes to person A is through a pull request, then you can make sure that not only is person A active in the market for Git hosting, but person B is, too. They'll need to throw their changes up on some Git hosting service, because it has to live somewhere. And if your startup happens to be a Git hosting service, that's good for you. And, hey! since it's a pull request, you can do more than strongly suggest that person B hosts their stuff with you, you can force it, by making it impossible for the pull request to come from off-site.

You can't do that kind of underhanded "growth hacking" if you allow contributors to submit patches, because while pull requests are indirect, patches are self-contained. They are a unit of change.

(I've referred to this in the past as using a strategy of dark patterns inspired by social networks.)

I want to emphasize: "patches vs pull requests" is one matter, and "email vs web UI" is an entirely different matter. It's a 2×2 matrix, not a dichotomy. But this conversation has (annoyingly) run on as if it is "patches (which must be done through email) vs pull requests (which are done through point and click)". There's nothing that precludes GitHub from having built a web UI where today's "pull request" button ended with a "submit patch" button in its place. Nothing.

> I don't see any way for that to not be trivial

Yes, this is clear every time the conversation comes up. Something has happened wrt GitHub that causes people to a) forget how things looked before GitHub, b) have extreme difficulty imagining that things could work any other way—even when the other way is more straightforward and less convoluted than the way GitHub actually works. It's kind of nuts.

Not to be condescending, but you can get the necessary information for doing that by using your favorite search engine.

> put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks?

You could test that by trying to telnet to the SMTP server on the ports they claim to accept connections on. ISPs may block port 25, but they usually don't block ports for secure SMTP connections (like 465 or 587).

As for security tricks, you can always try sending an email to yourself or another email account for testing.

Wisdom is knowing how to choose the simplest possible way to get a job done, i.e. knowing what not to do. I have enough to know which solution I'd rather spend my time on. Do you?

  1. Go to the file in GitHub you want to change
  2. Click the "Edit" icon
  3. Click the "Create Pull Request" button

It really depends on what you are trying to do in terms of what the process is.. generally, if you aren't a contrib, you will fork, and work from a branch on your locally cloned fork.. you push to that branch, and then create a PR upstream. You may create a local ref to the upstream branch in order to facilitate updates to your fork, and for handling squash/rebase scenarios.

A lot of this is simply git... the "fork" on github creates a github hosted remote copy of the upstream project. The PR is a chance to review upstream patching. Yes, this can be done via email... but you can also do a lot of things in email, that email is a bad user experience for.

1. Clone the repository locally 2. Make the fix 3. Run 'git review'. Done (without needing to remember that annoying refs/for/foo syntax.)