Implement edit-in-browser and pull requests on Drupal.org

Just thought that I'd update my comment above after having more experience using GitHub with Drush for a while. It is true that GitHub adds some very nice features, like inline comments in diffs, that drupal.org does not have. However, it's also a little awkward to do some things. GitHub is designed primarily for projects where maintainers collaborate with a single non-maintainer PR submitter. On drupal.org (and in Drush), it is common for multiple non-maintainers to collaborate on the same patch. This sort of workflow is a little awkward on GitHub; the easiest way to do it is for each contributor to fork the primary repository, and make commits in their own repository, with each commit comment referencing the original issue number in the GitHub issue queue. The multi-contributor workflow still is not as nice on GitHub as it is on drupal.org, though, as it is not as convenient to set labels on issues, assign issues to non-maintainers, or quickly merge commits from a third-party forked repository into your own fork. The cli is required for this, and for testing a PR after merge, but before committing it.

I'm sure these activities will get easier on GitHub over time. At the moment, what we'd ideally like is a system that had features from both platforms.

I would strongly be against this proposal. I find d.o. to be miles ahead of other tools, because community modules are centralised in one place. For example, I use puppet, and wish the 'puppetforge' were as fully-featured, visible, and usable as the d.o. project pages. I also notice that puppet modules are strewn randomly across github, with no real centralisation, and no reporting mechanism to track their usage.

I see the appeal of GitHub over d.o. in several key features:
1. Pull requests. This, a million times this.
2. This also implies forking. We have 'sandbox' repos, but I suspect they're not used much, because the process of creating a sandbox has a number of steps, and may not be obvious.
3. Simple creation of new repos ('sandboxes'). GH only needs the name of repo…and for sandboxes, we don't necessarily need all the project information that's currently requested.

Right now, GitHub is a much better code-management system, but I would prefer to see the tools on d.o. improved, than for us to migrate to GitHub.

it doesn't necessarily have to be done via pull request on the back-end; it could also auto-generate and auto-post patches

I agree that forking the whole repository is not necessary, but if you did not have that capability, you'd at least need to commit to a branch in order for the web button to be able to access the code to make the change. That, in my mind, would be equivalent to a pull request. Without a branch to commit to, where would the web button (pull-request equivalent) get the code from?

As for auto-generating and auto-posting patches from your local system to drupal.org today, as an interim step, you should really try the drush_iq project. That's what it does. It's gone largely unnoticed, but it's fairly slick. Not quite as good as pull requests, but still pretty fun to use. It even makes interdiffs. And posts releases, with release notes (using the grn project). From the command line. Yup.

@webchick

However, "Move Drupal.org development to Github" is definitely a separate proposal. ;)

I've almost voted in this proposal thinking it was the same thing. I guess many people did vote on it when they first read "pull requests".

Maybe rephrase the title to something like "Implement pull requests in drupal.org" AND include a note on top of the issue description linking to the similar proposal. Of course, linking back from the other proposal. In addition, explain the differences: one is for implementing in d.o, the other is to make PR in Github.