3 ms·

GitHub does have the ability to assign to (https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/ https://help.github.com/ar

GitHub does have the ability to assign to (https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/ https://help.github.com/articles/assigning-issues-and-pull-r...) and filter by assignee (https://help.github.com/articles/filtering-issues-and-pull-requests-by-assignees/ https://help.github.com/articles/filtering-issues-and-pull-r...). If you want to pull in multiple reviewers, you can @mention them. Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Github has Hub (https://github.com/github/hub https://github.com/github/hub) which is as powerful, if not more so, than arc. The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from.

gcb0 12y ago
I have no idea where that help page took those screen shots from... but it is definitely not from github.com or github enterprise. I see no way to assign pull requests... i don't even see the checkbox they mention on the PR list!
- stormbrew 12y ago
  That's really odd.. I see it on both the public github and the not completely up-to-date GH-enterprise setup I have access to...
- frossie 12y ago
  You need to have someone to assign the PR to. Either you need a second contributor on the repo, or you need to be in an organisation with more than one member.
spicyj 12y ago
> Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes. > The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from. Yes, Phabricator's isn't perfect but it's the best of the ones I've tried, especially if everyone using it is familiar with the tool and uses it frequently (that is, you might forget to Clowncopterize once or twice ever, but then you'll know for the future). I used to use Kiln (http://www.fogcreek.com/kiln/ http://www.fogcreek.com/kiln/) which had a different approach for emails – they essentially debounce emails to have a half-hour delay and coalesce any emails within that timeframe together, so you get fewer emails but don't need to submit the collection of comments explicitly. Having tried all three choices, I'd say that they're all painful in different ways and I personally prefer Phabricator's approach.
- vaceletm 12y ago
  > Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes. For this Gerrit[1] does offer the possibility to fully customize the approval process. It's a bit freaking odd at start because it relies on Prolog [2] but it's the way to tailor the tool to your process [1] https://code.google.com/p/gerrit/ https://code.google.com/p/gerrit/ [2] https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html https://gerrit-review.googlesource.com/Documentation/prolog-...
jtsnow 12y ago
> Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Phabricator allows "blocking reviewers", meaning that those reviewers must. There can be any number of blocking reviewers. These reviewers can be groups or individuals. For example, you could require someone from the "Security" group to accept every revision.

gcb0 12y ago

I have no idea where that help page took those screen shots from... but it is definitely not from github.com or github enterprise. I see no way to assign pull requests... i don't even see the checkbox they mention on the PR list!

stormbrew 12y ago
That's really odd.. I see it on both the public github and the not completely up-to-date GH-enterprise setup I have access to...
frossie 12y ago
You need to have someone to assign the PR to. Either you need a second contributor on the repo, or you need to be in an organisation with more than one member.

spicyj 12y ago

> Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes. > The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from. Yes, Phabricator's isn't perfect but it's the best of the ones I've tried, especially if everyone using it is familiar with the tool and uses it frequently (that is, you might forget to Clowncopterize once or twice ever, but then you'll know for the future). I used to use Kiln (http://www.fogcreek.com/kiln/ http://www.fogcreek.com/kiln/) which had a different approach for emails – they essentially debounce emails to have a half-hour delay and coalesce any emails within that timeframe together, so you get fewer emails but don't need to submit the collection of comments explicitly. Having tried all three choices, I'd say that they're all painful in different ways and I personally prefer Phabricator's approach.

vaceletm 12y ago
> Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes. For this Gerrit[1] does offer the possibility to fully customize the approval process. It's a bit freaking odd at start because it relies on Prolog [2] but it's the way to tailor the tool to your process [1] https://code.google.com/p/gerrit/ https://code.google.com/p/gerrit/ [2] https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html https://gerrit-review.googlesource.com/Documentation/prolog-...

jtsnow 12y ago

> Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Phabricator allows "blocking reviewers", meaning that those reviewers must. There can be any number of blocking reviewers. These reviewers can be groups or individuals. For example, you could require someone from the "Security" group to accept every revision.