davegaeddert

Currently there's two ways "approval" can be determined. 1) Approval by "any" of the reviewers means it has passed. Ex. The 3 people with write-access get chosen as the reviewers, and if any 1 of those 3 approve it, then it passes. 2) Approval by "all" of the reviewers means it has passed. Ex. Of the 3 people chose as reviewers, all 3 would have to approve the PR for it to pass.

Does that make sense? I think #1 gets at the scenario that you're talking about, but right now it doesn't automatically choose the reviewers based on who has read/write/admin access. You would just choose those people manually when you set up the repo and choose whether the rule is "anyone" can approve it or "everyone" has to approve it.

Awesome, thanks for the detailed feedback.

- Great point on permissions. I'm certainly going to do some digging to see how many people get turned away by that level of access. I could definitely understand if people are cautious with that, as you were, because they should be!

- The prevention of commits to master all happens via GitHub's new protected branches feature (they use Git hooks I believe). You're right, preventing force push is part of it, but the other thing it can do is require status checks (PullApprove is just another status check) on all commits to your base branch -- meaning nothing can be directly committed to the base branch, but should instead run through a pull request. Pretty interesting stuff: https://github.com/blog/2051-protected-branches-and-required...

- Thanks for sharing this one, I definitely wouldn't have thought of that without experiencing it myself.

- I'm planning on building some settings towards this. The most basic one giving an option that approval statuses go back to "pending" on new commits. It could possibly get more specific, giving an option to ignore whitespace changes etc...

- Nice idea. I'll throw this in the hopper.

Let me know if you have any other thoughts!

Thanks! We started it for the same reason -- internal use. Felt like we might as well turn it into a service so other people wouldn't have to build it too!

Is there anything you learned by building your tool that would be worth us building into PullApprove?

I give a repo a star if it's something I use or think there's a pretty good chance I'll use in the future (bookmarking). It also means I like to stay up-to-date with their development, as least at the surface level. I built http://sibbell.com for exactly that purpose - it will notify you any time a repo that you star (or watch) has a new release. I don't like to "watch" repos on GitHub though because on a project of any size, you get flooded with emails...

Thanks! @NathanBartel had fun with that one.

Thanks for asking, we feel like Beluga is most effective for groups of that size or smaller. Can I ask what size of group you'd like to use with Beluga? And what that group would be for (development team at work, dishing out chores to your 10 kids, etc.)?

Our company has had a side project going for the last couple months called Beluga. It's a simple, straight-forward task sharing iOS app for small teams. We just made it free today for a limited time, have been getting some awesome traction so far.

https://itunes.apple.com/us/app/beluga-shared-tasks./id83683...

Technology: Django, AngularJS, django-tastypie, Mandrill, iOS (obviously)

Statistics: Almost 300 new users so far today...

History: We built this to satisfy a need for ourselves, instead of sending each other texts and Hangout messages all day with small tasks, we decided it could make for a really simple app that could do exactly what we want and nothing more. Turns out it's also great for sharing to-dos with your significant other...

I've been working on a site called Sibbell (http://sibbell.com/).

At the core, the idea was to provide a way to get notified when GitHub projects you use (star or watch) publish new releases. Keeping you in the know when features get added or that bug that's about to kill your Monday gets fixed. Seems like something GitHub would do, but the only way you can get notified about releases through GitHub is to 'watch' a repo and then you get notified for every issue, comment, pull request, etc.. Got some pretty good reception on HN and have some major improvements and additions coming in the next week or so.

Technology: Django, Celery, GitHub API

Thanks, it's based on GitHub releases (Git tags -- ex. https://github.com/twbs/bootstrap/releases). So anytime a new release is published it will send you an email with any details that they included with the release.