Compare two views of the same commit (found this by searching for any commit on github with the word "indent" in it)
https://github.com/douglascrockford/JSON-js/commit/1e3869cb3... (133 additions and 127 deletions)
https://github.com/douglascrockford/JSON-js/commit/1e3869cb3... (30 additions and 24 deletions)
At present, the "official" collaboration tools in the GitHub integrations directory are here: https://github.com/integrations/feature/collaborate
GitHub has become the de-facto place to host open source projects. Improving the tooling around code merging, seems like a no-brainer, and a huge potential win for the projects using it, especially the larger ones.
- [x] Refactor _
- [ ] Rename variable x
- [ ] ...
Now that you mention it, it would be very nice to have something like Google Docs's ability to mark comments as resolved.
1. There's a data loss bug when multiple people edit the PR descriptions. I've had that as an open issue with GitHub for ~6 months, my team experiences it several times a week.
2. We use the checkboxes to assign and track reviewers, and since there's only one count of checkboxes, it would mess with our "2 of 5 complete" kind of metric for reviews.
I'd like first-class support for the concept of people reviewing and accepting (or rejecting) so that it's taken out of the PR description.
Code review "rules" can get pretty complicated since everyone works a little differently...not sure if GitHub will ever try to tackle that or not but we've got a lot of customers who are happy with how PullApprove fills the gap.
1. Discussions are automatically treated as "issues" that need to be resolved before the review is complete. Resolving can be as simple as clicking "acknowledge" without following up, but there's also a rich system of "dispositions" that lets you block a discussion, resolve it unconditionally, etc.
2. You can set multiple assignees! (Only one will be reflected in GitHub, though.)
3. You can write a custom rule for determining review completion. One of the samples is "complete only when every assignee has sent an :lgtm:", giving the assignees explicit control over merge approval.
I know you've already decided against Reviewable danpalmer, but I figured others might still be interested. :)