For the former:
* Create a Github account
* Fork the repository
* Set up the new git remote
* Push to that remote
* Open the pull request
* Wait for notifications via email
* Go back to the webpage and find the comment
* Modify the code, add, commit, push, and type a comment
* Repeat
Versus
* Configure git to use one's ISP's email server
* Run git format-patch
* Run git send-email
* Check email for replies
* Amend the commit, run git format-patch, and git send-email
* Reply to the maintainer email
* Repeat
To reply to emails, you can use any email client or even do that in the browser. You only need to use the format-patch and send-email commands to send patches.
(a) You included setting up your local repo from the fork in the Github list but it's implied in the 2nd list
(b) You included "Modify the code, add, commit, push, and type a comment" in the first list: this is literally how you use Git for normal development. It isn't an exclusive part of using Github
2. Network effect:
(a) Creating a Github account is a one-time step: this will be omitted for any platform with a large projectbase
(d) Most popular modern tooling/documentation/etc. are set up for the Github-ish workflows and general user knowledge of `format-patch` and `send-email` as commands is considerably more sparse.
Presumably one would have to clone the repo in order to make the modification locally before forking. But whether or not one would fork the repo through the GUI before cloning it depends on the person. I don't know which scenario is more common. If it's the former, then they would have to handle setting up the new remote for the fork before pushing up their code.
> You included "Modify the code, add, commit, push, and type a comment" in the first list
In the second list, I did state: "Amend the commit, run git format-patch, and git send-email" which is essentially the same thing. The only difference is that the first list implies that you make more commits (which is in line with the expected pull request workflow on Github) while the second involves amending the commit and resubmitting the patch (which is in line with the expected workflow for email based review).
> general user knowledge of `format-patch` and `send-email` as commands is considerably more sparse.
Github explicitly tells you how to set up a remote when you create a new repo and tells you how to clone a repo and has pages that tell you how to handle pushing code up to the remote and how to set up your git config for your name and email address. They don't assume that anyone has knowledge of those commands (git push, git config --global --add user.name, git clone, git branch, git remote add, etc). There's no reason why similar quick to read documentation for git format-patch and git send-email couldn't also be provided.
I didn't read your statement carefully enough when I replied earlier. For the second list, you would only have to clone the repository and make your modifications locally. You wouldn't push your changes up to a remote repository; you would only send email messages with the commit message information and the diff.
This means you wouldn't have to go through the step of forking the repository and setting up the new remote before pushing the changes and going ball to the UI to open a pull request (though setting up the new remote isn't required if you fork the repository first and then clone from the fork--though that would make keeping your local copy of the repertory up to date more difficult).
Which most people have already and it allows you to contribute to a gazillion of repositories.
Run git send-email, Check email for replies
There is one important step missing here: Find out who to send the patch to or subscribe to a mailinglist (and later unsubscribe). In the former case, if a maintainer goes AWOL, the patches that they received are lost. In the latter case, subscribing to a mailinglist, let alone for every project that you want to do a drive-by submission, also involves several steps:
- Figure out how to subscribe
- Subscribe
- Set up filter in your e-mail client to avoid cluttering up your inbox.
- Unsubscribe when you are done
To reply to emails, you can use any email client or even do that in the browser.*You can also reply to GitHub issue e-mails.
(I am not a big fan of GitHub, but I think it is important to understand why a lot of people find GitHub so convenient.)
And pretty much everyone has an email account. In fact, I don't think it's possible to sign up for a Github account without providing an email address.
> There is one important step missing here: Find out who to send the patch to
Many projects have a README or CONTRIBUTING file that describes the necessary steps. Looking at projects that don't accept Github pull requests (like the Linux kernel or git itself), there are (as of the time I'm writing this post) 225 and 155 open pull requests on each respective project, which indicates that people aren't reading the documentation before trying to make a contribution.
> In the former case, if a maintainer goes AWOL, the patches that they received are lost.
The same thing can happen in Github if the maintainer never bothers to acknowledge the pull request or just closes it. Finding a particular patch out of the hundreds of open but not acknowedged pull requests in the linux and git repositories isn't going to be easy.
>> To reply to emails, you can use any email client or even do that in the browser.
> You can also reply to GitHub issue e-mails.
I made the statement about using any email client (local or web based) because the post I replied to stated that one needed to use a TUI client like mutt.
Wouldn't using HTML email (default in most modern clients and webmails) be frowned upon by the ML participants?
(for the record I liked your comparison)
We can debate the value of centralized web interfaces to vcs systems all day long, but the fact that they immensely simplify contributing to open source software cannot be understated.
From what I've read, it could lead to badly formatted files and commit messages (since the online editor may not handle wrapping or spacing correctly). Plus, how does one test a change they make if they just made it in an online editor? If their contribution has syntax errors because they didn't even run the code, then is it a worthwhile contribution?
