4 ms·

Github lowers barriers to entry for a lot of people and I guess Mozilla likes that. Compare creating a one line fix for a project on github and having a discus

• jopsen 8y ago
  It's also a balance... Most experimental researy projects don't need high security or high code quality. They just need to prove viability, etc..
• u801e 8y ago
  > Compare creating a one line fix for a project on github and having a discussion and review to sending a properly formatted patch to a mailing list and following up on that. 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.
  • jvehent 8y ago
    For most folks who already have an account, it's just a matter of clicking the "edit" icon on the top right of a file, making the change, then saving it. GitHub does everything else under the hood, and creates a fork and pull request programmatically. 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.
    • u801e 8y ago
      > For most folks who already have an account, it's just a matter of clicking the "edit" icon on the top right of a file, making the change, then saving it. 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?
      • jvehent 8y ago
        Modern projects don't rely on local linting and testing, but instead leverage continuous integration platforms like travisci or circleci for verification.
        • u801e 8y ago
          Does that apply to forks of the project? Or is the only way to test the project is to open the PR and check the build status on the upstream? Personally, I would like to know that my code is in a working state before I actually submit it to the maintainer for review.
  • danieldk 8y ago
    Create a Github account 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.)
    • u801e 8y ago
      > Which most people have already and it allows you to contribute to a gazillion of repositories. 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.
      • Boulth 8y ago
        > 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)
  • lucideer 8y ago
    1. Bias: (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.
    • u801e 8y ago
      > You included setting up your local repo from the fork in the Github list but it's implied in the 2nd list 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.
    • u801e 8y ago
      > You included setting up your local repo from the fork in the Github list but it's implied in the 2nd list 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).