71–80 of 210 posts
More and more I'm starting to appreciate the email based PR
Reviewable tracks code by revisions (aka changesets), not just the state of the git branch like GitHub, and many more improvements both to the broad strokes and to the small things.
Want to immediately see which PR's you should review? Want to avoid getting pinged during the day to review PR's you could have reviewed on your schedule? Want to see the status of a PR right when you open it? What about keeping your comments on the right line even as new changesets come in so you never have to review the PR from scratch again?
All handled by Reviewable to make you a better engineer: fewer interruptions, no repeated work, and generally respond to reviewers faster
Jm2c, but by far the best place I've ever worked (my current client) we don't do code reviews at all unless the author wants feedback. PRs are good ways to defend your code base from bad code, and they were born in open source where you literally have no clue who the contributor is, but years of experience left me convinced that I don't want such a system where there's constant need to overview each other's work. I w…
I don't see code review as an overwatch but a good communication tool and a way to think about problems collectively. Code review reduce bugs because it permit to have people think about the problem from multiple angles. About decisions, I think important design decisions need to be taken prior to the code review steps ,and also reviewed. I'm not sure what context you worked in that gave you that opinion about code r…
I often stack PRs to emulate the practice described by Mitchell but it's not ideal as if you need to change an underlying PR l, you need to rebase all of the dependent PRs.
All supported by Reviewable, of course (sorry for the shameless plug!)
I often stack PRs to emulate the practice described by Mitchell but it's not ideal as if you need to change an underlying PR l, you need to rebase all of the dependent PRs.
I agree 1000%. I’m the creator of what I believe is a better review interface for GitHub ( https://codeapprove.com ) but there are also many others: * CodeApprove (codeapprove.com) * Graphite (graphite.dev) * Reviewable (reviewable.io) * Axolo (axolo.co) * Viezly (viezly.com) * Mergeboard (mergeboard.com) * Codestream (codestream.com) * Pullpo (pullpo.io) * ReviewPad (reviewpad.com) * Planar (useplanar.com) * Visibly…
That's like saying it's OK to expect (say) Ford to make a car with no steering wheel. GitHub basically define the baseline for the entire industry and have millions upon millions to blow on trying to do better. (OK, Saab did actually do that once but they're weird)
Hmm, not saying Github is perfect, but I think there’s value in providing the simplest possible experience as the default.
I agree. As a way to minimise the pain on GitHub today, we disallow force pushing and enforce squash merging. Force pushing is a nightmarish behaviour, once a Pull Request is opened the branch must be append only.
Earlier quoted context omitted.
"I think in the end we should not expect GitHub to provide the best option here. We should expect them to provide a basic option (which they do) and for sophisticated consumers to pay more for a much better option. Everyone should be shopping for code review tools! " I understand this linke of thinking might suit you but I fear it is not as convincing as it sounds to you. At least it's not to me.
Here's how I like to think about it: GitHub is a generalist. They have a big platform with lots of features besides code review, so even though they also have lots of employees they won't be able to focus on code review as much as a dedicated company could. They also have a huge number of users to please so they can't afford to rock the boat too much or make the learning curve too steep. I think therefore it's pretty…
If i must pay for GitHub and an external tool, isn't GitHub just an dumb overpriced git storage.
When using changeset-based review, do you find yourself writing things like "This changeset still has the problem I drew attention to in my review of the previous changeset. Please see the comment there." ? I'm just curious how that works; I haven't used changesets much but it seems like this would be one inconvenient aspect.
Reviewable does this with an algorithm that ensures the code context is similar, with a visual warning if the comment might be in the wrong place. (Shameless plug!)