Github's workflow, features and terminology are focused on open source projects and those projects tend to work in a specific way. Kiln is focused on providing features that fit better inside a business environment. For example, the idea of a pull request is a bit foreign in a business environment. Internally, almost all the code written eventually gets shipped, so the social interaction around pull requests doesn't fit exactly right.
How is the "social interaction around pull requests" not just a synonym for "code review?"
Now, I recognize that much code written in a "business environment" does indeed ship without review. I just don't think that's a good thing.
If what you're saying is that you've yanked code review tools because customers don't want them, my only reply is that I'm afraid I'm unlikely to be a customer.
No, we have code reviews instead of pull requests, which as you point out is mostly terminology. But that terminology is indicative of assumptions that are baked into how the software operates. The assumptions and workflow of Kiln assumes you are using it inside of a business. I just gave one superficial example of a larger point I was trying to make about our intentions vs. people creating open source solutions and how that translates into defaults/workflows/usability of the software in different areas.
Give us some more examples, please. The pull requests vs. code reviews distinction is unconvincing.
I'd love to find a DVCS SaaS that provides better integration with the business software engineering workflow, and a UI that doesn't suck. So far I don't see a whole lot of that going on in kiln+fogbugz.
In my particular little enterprisey world, pull requests are something myself and some of the other bleeding-edge guys would like to work up for a workflow over a traditional branch and merge workflow. We think it's better for what we do. YMMV.
Joel explains it better than I can: http://www.joelonsoftware.com/items/2013/03/11.html