davegaeddert

7 ms·

31.
by davegaeddert 11y ago
Thanks for the detail! My personal experience is generally in strategy 1 as you outlined, especially in being that lead person. I know a lot of people like the appeal of strategy 2 (myself included) but like you mentioned, there's a nu
32.
Ask HN: Does your team do code review? How? Why not?
7 points by davegaeddert 11y ago|5 comments
33.
by davegaeddert 11y ago
Sorry if you got an email that felt unsolicited. The only email that was sent was to some users of Sibbell ( https://sibbell.com ) which is another GitHub-related service we built. We really weren't trying to spam people, but
34.
by davegaeddert 11y ago
Gotcha, so if three users have write access then when a PR is opened by one of them, one of the other 2 users has to approve it? If your scenario only has two users (you and one other person) then this flow can already be accomplished (the
35.
by davegaeddert 11y ago
Forked repos is absolutely one way to accomplish preventing merge privileges (since it removes all push access). At least for us, our workflow and tooling is much simpler if all developers work on the same repository. Even in the case of fo
36.
by davegaeddert 11y ago
Thanks for the feedback, I totally agree. I'll see if we can work something up that shows the whole flow -- from creating a pull request, to approving via PullApprove, to merging.
37.
by davegaeddert 11y ago
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,
38.
by davegaeddert 11y ago
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 t
39.
by davegaeddert 11y ago
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 buil
40.
Show HN: Require approval to merge GitHub pull requests(pullapprove.com)
30 points by davegaeddert 11y ago|18 comments
41.
by davegaeddert 11y ago
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
42.
by davegaeddert 12y ago
Thanks! @NathanBartel had fun with that one.
43.
by davegaeddert 12y ago
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
44.
Show HN: Beluga - A nice way to make lists and share tasks on your iPhone(beluga.link)
5 points by davegaeddert 12y ago|5 comments
45.
by davegaeddert 12y ago
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 trac
46.
by davegaeddert 12y ago
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 wh
47.
by davegaeddert 12y ago
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
48.
Show HN: Sibbell – Get notified when repositories you use get updated(sibbell.com)
8 points by davegaeddert 12y ago|2 comments