Thanks so much for all the love, HN! I'll do my best to address everyones' questions in one post:
1) Cross-platform support: ZenHub for Firefox, Safari, and mobile is coming soon - how soon depends on how much our current user-base wants more platform support vs big features we have spec'd out. No worries here :)
2) GitHub API rate limit: GitHub has worked with us to lift the API request rate limit for users that need it, we're also limiting the GitHub API calls we do have to make with caching systems and other tactics, for eg disabling polling when you're not looking at the board. TLDR: we have no worries here either.
3) Major GitHub UI updates: these do have the potential to break some functionality, but our major feature (the Boards) is pretty robust. Also, we're really fast and can react to GitHub's changes within minutes if not hours. We're now working with GitHub to get a heads up on changes that may affect our product, so again - no worries.
4) Transitioning from Huboard / other tools: should be painless: you can even use both products in parallel during the transition period and pick the one you like best (hint: it'll be ours!)
5) Errors with our homepage (zenhub.io): we're fixing issues as quick as they pop up, bear with us :)
6) Other comments or requests: please vote on feature requests by creating new Issues or +1'ing existing Issues on our public GitHub support repo: https://github.com/zenhubio/support/issues
I couldn't imagine getting all my team to use this product and then suddently GitHub updates their UI and this plug-in is broken for days or weeks before an update hits the Chrome app store. This seems like a huge deal breaker.
That's exactly my concern. I'm currently considering between waffle.io and huboard - and in general it seems to me safer that they use github's API, compared to Zenhub, which (is this the right expression?) 'monkey-patches' the front-end.
Being only usable in Chrome is also a disadvantage of zenhub in my opinion.
For me, that page is lagging like crazy (although other tabs work fine). Also, this is another good example of a headline that doesn't state anything about what the product actually does.
Going further down the page does make it more clear though.
I think this looks really cool, and may give it a spin. However, not sure I can justify the charge for my team. I currently pay $25 for a Bronze GitHub Organization plan [1], and while I'm the main developer for the site, I do have a team of volunteers that contribute to the source whenever they can, about 10-15 of us total.
So I would be looking at $50-$75 for an extension to a product I'm only paying $25 for at the moment. Just seems a little imbalanced.
Of course, I realize I'm an edge case, as most teams of this size will be paid team members in an established startup or company, but it still seems even these companies may find it odd to pay more for an extension vs. what they might pay for the base product.
Why not base your tiers similar to GitHub, charging by the number of repos instead of the number of users?
Thanks very much for the note. I see where you're coming from, but keep in mind our pricing drops to $3.75/user at higher volumes - quite affordable compared to the products we replace.
Please do take ZenHub.io for a spin and, if you love it, shoot me an email: r[at]ze.nr - we can talk about your team's needs and find a win/win.
1. API limits are usually per user (OAuth token, API token), not per API consumer. 5000 per user is a lot. The exceptions are ancient APIs, actually want to constrain usage, or didn't think about how their API would be consumed.
2. Honor cache headers and, headers or not, know the data well enough to cache thoughtfully.
We consume 40+ APIs for https://tacoapp.com/ and even with a full day as #1 on ProductHunt, the only APIs we had to worry about were those tied to the consuming app instead of to the user (API token) or user+consuming app (OAuth token).
Basically, if you build an API, base limits on the number of users a consuming app is acting on behalf.
We have been using ZenHub for quite a while and have to say that it has been a great change from Trello. As a developer, I was already in Github all the time, so adding the pipeline process within Github is awesome.
It hasn't been without it's issues, but I would highly recommend trying it out.
This is rad, however, echoing others it does seem a bit risky to trust that Github won't swap out. For stuff like boards, it'd be nice to have an option sync with Trello. Worst case scenario all of the data is there and usable without a lot of fuss.
Keep in mind that almost everything in ZenHub is built directly on core GitHub features which are not going anywhere (Issues, Pull Requests, etc) - the files are hosted on S3.
That said, Trello sync is an interesting idea. Taking a look at Trello integration is somewhere on our list, mostly to set up a Trello-to-ZenHub importer but sync would be a nice side-effect. Thanks for the feedback!
We already use huboard. It would be nice if this transition from huboard to ZenHub was more seamless. For now, I'm told that I need to create another board and I'm not entirely sure how this will affect our huboard setup..
Do you use gira, at first glance it like it only works on public repos? It looks like an acceptable but rather thrown together alternative to both Huboard and Zenhub.
(Background: we used Huboard, but essentially have too many issues for it to handle & I'm curious what other workflows people use and if Zenhub could handle what Huboard can't.)
[+] [-] rohamg|11 years ago|reply
1) Cross-platform support: ZenHub for Firefox, Safari, and mobile is coming soon - how soon depends on how much our current user-base wants more platform support vs big features we have spec'd out. No worries here :)
2) GitHub API rate limit: GitHub has worked with us to lift the API request rate limit for users that need it, we're also limiting the GitHub API calls we do have to make with caching systems and other tactics, for eg disabling polling when you're not looking at the board. TLDR: we have no worries here either.
3) Major GitHub UI updates: these do have the potential to break some functionality, but our major feature (the Boards) is pretty robust. Also, we're really fast and can react to GitHub's changes within minutes if not hours. We're now working with GitHub to get a heads up on changes that may affect our product, so again - no worries.
4) Transitioning from Huboard / other tools: should be painless: you can even use both products in parallel during the transition period and pick the one you like best (hint: it'll be ours!)
5) Errors with our homepage (zenhub.io): we're fixing issues as quick as they pop up, bear with us :)
6) Other comments or requests: please vote on feature requests by creating new Issues or +1'ing existing Issues on our public GitHub support repo: https://github.com/zenhubio/support/issues
[+] [-] Khao|11 years ago|reply
[+] [-] jdc0589|11 years ago|reply
[+] [-] earless1|11 years ago|reply
[+] [-] Khao|11 years ago|reply
[+] [-] gingerlime|11 years ago|reply
Being only usable in Chrome is also a disadvantage of zenhub in my opinion.
[+] [-] EduardoBautista|11 years ago|reply
[+] [-] conradk|11 years ago|reply
Going further down the page does make it more clear though.
[+] [-] jader201|11 years ago|reply
I think this looks really cool, and may give it a spin. However, not sure I can justify the charge for my team. I currently pay $25 for a Bronze GitHub Organization plan [1], and while I'm the main developer for the site, I do have a team of volunteers that contribute to the source whenever they can, about 10-15 of us total.
So I would be looking at $50-$75 for an extension to a product I'm only paying $25 for at the moment. Just seems a little imbalanced.
Of course, I realize I'm an edge case, as most teams of this size will be paid team members in an established startup or company, but it still seems even these companies may find it odd to pay more for an extension vs. what they might pay for the base product.
Why not base your tiers similar to GitHub, charging by the number of repos instead of the number of users?
[1] https://github.com/pricing
[+] [-] rohamg|11 years ago|reply
Please do take ZenHub.io for a spin and, if you love it, shoot me an email: r[at]ze.nr - we can talk about your team's needs and find a win/win.
[+] [-] kateho|11 years ago|reply
I'd still give it a spin though. We've been looking for a way to make github work better for us, and this looks like it's going to hit the mark.
[+] [-] felixrabe|11 years ago|reply
https://github.com/docker/docker/issues/735#issuecomment-576...
[+] [-] Khao|11 years ago|reply
Uncaught TypeError: Cannot read property 'top' of undefined
[+] [-] EduardoBautista|11 years ago|reply
[+] [-] Revell|11 years ago|reply
[+] [-] troydavis|11 years ago|reply
1. API limits are usually per user (OAuth token, API token), not per API consumer. 5000 per user is a lot. The exceptions are ancient APIs, actually want to constrain usage, or didn't think about how their API would be consumed.
2. Honor cache headers and, headers or not, know the data well enough to cache thoughtfully.
We consume 40+ APIs for https://tacoapp.com/ and even with a full day as #1 on ProductHunt, the only APIs we had to worry about were those tied to the consuming app instead of to the user (API token) or user+consuming app (OAuth token).
Basically, if you build an API, base limits on the number of users a consuming app is acting on behalf.
[+] [-] hk__2|11 years ago|reply
[+] [-] joshfinnie|11 years ago|reply
It hasn't been without it's issues, but I would highly recommend trying it out.
[+] [-] rglover|11 years ago|reply
[+] [-] rohamg|11 years ago|reply
That said, Trello sync is an interesting idea. Taking a look at Trello integration is somewhere on our list, mostly to set up a Trello-to-ZenHub importer but sync would be a nice side-effect. Thanks for the feedback!
[+] [-] WadeWilliams|11 years ago|reply
[+] [-] repple|11 years ago|reply
[+] [-] chibicode|11 years ago|reply
[+] [-] pradn|11 years ago|reply
[+] [-] alexeyza|11 years ago|reply
[+] [-] sandGorgon|11 years ago|reply
If you could do Bitbucket, that would be awesome (considering Bitbucket already has native Hipchat, Jira, etc.)
[+] [-] mechazawa|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] oyanglulu|11 years ago|reply
[+] [-] adzuci|11 years ago|reply
[+] [-] unclesaamm|11 years ago|reply
[+] [-] iolsantr|11 years ago|reply
[+] [-] mck-|11 years ago|reply
btw, you're making the analogy as if "Zen" were a religion – it is not
[+] [-] anhtran|11 years ago|reply
[+] [-] maximumoverload|11 years ago|reply