This is neat! I'm excited to see things about the GitHub code review ecosystem improving. I've long wanted to see "when tests pass and a reviewer :shipit:'s, then go ahead and merge the code" bots.<p>I wrote a bot of my own, which I have at <a href="https://betterdiff.com/" rel="nofollow">https://betterdiff.com/</a> . The idea there is that instead of having humans go through and give cursory reviews, you have a round of automated review by robots (using normal, industry-standard tooling) and it comments on the PR just like a reviewer would. I'd love to hear your thoughts. :)
This is pretty cool. We built something similar internally at a previous company - very handy to enforce good development practices, and ensure that no unreviewed code is deployed to production for security purposes.
Some cool stuff here, though I think a demonstration video or fancy animation would be nice. Like someone else has mentioned, it's a little intimidating to give full access just to see how it works -- you might convert more customers if they can see how it works and some common use cases before they need to commit the time to trying an integration.
I used to think that this was a really weird missing feature in Github. Then someone introduced me to true Gitflow using forked repos have used it with all teams since. With a forked repo someone with read access can post a PR to the originating repository without the ability to merge.<p>Does no one else use this methodology on their teams?
Does it support a dynamic reviewer? In other words, instead of assigning a person who approves pull requests, it would allow merging if at least one other person with write access approved the code.<p>That would be the main use case for the company I work at, right now we're doing that manually by tagging and waiting for the response.
I received an unsolicited email from these guys. The email does not get subscribed to many things to keep volume low. Did they buy a bunch of addresses to spam?
Oh look, another tool to get in the way. Of course "write" access means "merge" access, they are the same thing. How about we try this thing called trusting the developers.<p>If you can't trust your own developers, you have bigger problems then "merge access".