Posted by moshe weitzman on March 31, 2011 at 6:14pm
For code contributors and reviewers, I think the Github Pull Request model is extremely tight. Please read their blog post at https://github.com/blog/712-pull-requests-2-0. Note that Github can optionally associate an issue with a Pull request. I think thats a good starting point for how pull requests and issues play together.
Comments
Definitely
Yep, we really want to implement the things behind to actually have the ability to use pull request in git phase 3, and like you mentioned, github is a good example of how it can works.
We need to figure out how exactly it should/can work for our issue's model, but we want to have it! ;-)
Yep, there's a lot that
Yep, there's a lot that they've done that we can work with/from. There are some key differences, but that post especially does highlight most of the principles we're going for. Biggest distinction is that Github's pull requests are a restricted/confined conversation to people who have push access to the requesting branch, whereas our conversations are open.
Are you sure about that?
Are you sure about that? I just submitted a pull request to the oocss project without having push access and I couldn't believe how smooth and intuitive the process was.
Here is the documentation I followed.
All you have to do is
Your pull request immediately spawns a discussion where all comments, code reviews and followup activity are captured chronologically as they happen.
So in my case when I was notified by email that someone commented to say that I could remove another redundant css selector, I committed the additional changes to my topic branch and the pull request discussion was automatically updated with this activity.
Github's workflow is so smooth and intuitive that it really promotes collaboration.
Yes, I'm quite sure. I think
Yes, I'm quite sure. I think you missed my point: it's easy for you to open a pull request. What's not easy is for me to contribute code to the pull request you opened. I can harp on that comment, just like someone did to you, but I can't actually fix it myself, commit the fix & push it somewhere, and have my fix directly interwoven into the pull request.
As far as I'm concerned, Github's done just about the best conceivable job when it comes to facilitating that 1:1 interaction. But it gets awkward fast if you want to actually let multiple people write code together - you have to actually spin up a new repo for that. And if you both already have forks...yeah.
Maybe that's an edge case - but of the last three or four patches I've reviewed, I've really wanted to be able to make tweaks and push them back up into the conversation on top of what the other person has already done. Can't do it with Github, and unless I'm missing something big about how their system is structured, it runs counter to the fundamental structure of their interaction dynamic. We don't have to be limited by that on d.o, so I'd rather not.
AccessGranted! service
One plausible solution is to build a simple service on top of Github. Let's call the new service 'AccessGranted!'. The flow goes like this.
Github doesn't have
Github doesn't have branch-level access control, as far as I know, so you'd have to delete the fork to make a new patch with different people having access?
Frankly, other than the UI tools, a lot of the github workflow is quite limiting, so I'd tend to agree with Sam.
Looks like you are replying
Looks like you are replying to my post above.
Why not just keep adding contributors to the same repo? Do you really need to exclude people on a branch by branch basis. It is not like you can do that on drupal.org.