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.
really? I did, but I found the github integration lacking actually. Lots of 'coming soon' functionality on the documentation pages last time I checked.
huboard and waffle are much more tightly integrated with github from what I saw, to the extent that all data lives in github, they just display it on a kanban board (as far as I could tell).
You're 100% correct. Blossom/trello/jira etc all suffer from the same data replication problem, though blossom is a pretty product. It was among the products we tried to use before deciding to build ZenHub in the first place! Huboard and Waffle assuage this somewhat, but they still require your team to jump around between different tools, causing workflow fragmentation. ZenHub is the only product that avoids both flaws.
It could stop being able to insert content into the page if the structure changed. If they're smart they'll have tests that periodically check it still works and alert them if it doesn't. If they're smarter they'll have it work out where on the page the target has moved to and update the extension automatically with a fix if it can find one.
Not to mention Github uses feature toggling. So even users of the same team can have different versions of the UI, but almost certainly across the entire user base.
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.
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..
GitHub is very lenient with their rate limits if you just ask. I'd guess huboard and waffle.io have agreements in place where users authenticated through them have higher limits.
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.
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.
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
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!
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.)
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.
45 comments
[ 6.4 ms ] story [ 183 ms ] threadBeing only usable in Chrome is also a disadvantage of zenhub in my opinion.
huboard and waffle are much more tightly integrated with github from what I saw, to the extent that all data lives in github, they just display it on a kanban board (as far as I could tell).
It hasn't been without it's issues, but I would highly recommend trying it out.
Uncaught TypeError: Cannot read property 'top' of undefined
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.
If-None-Match / If-Modified-Since and using the E-Tag header.
If the resources have not been modified, or doesn't match that revision it won't count towards your limit.
Going further down the page does make it more clear though.
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
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!
https://github.com/docker/docker/issues/735#issuecomment-576...
btw, you're making the analogy as if "Zen" were a religion – it is not
Startups using the word Zen are just creepy in a cultural appropriation kind of way. It's like "I Can't Become a Buddhist", by Adrienne Su:
because I grew up vaguely Methodist
and most of the Buddhists
I know are men who turned Buddhist
.
after finding the religion
in a prepubescent
girl serving prawns and chicken
.
in coconut milk, steamed sticky rice,
papayas, and a massage for the price
of a subway token. Because they drive
.
cars bearing FREE TIBET bumper stickers
but would let their neighbors wither
and starve. Because they slither
.
up and down the supermarket aisles
waiting for the chance to ask girls
like me Where are you really from? while
.
stocking up on mung beans and swelling
with the memory of that excellent
backrub in the hands of a thirteen-
.
year-old goddess who's probably dying
or dead or working for Nike at a dime
a sneaker. Because their renouncing
.
is pointed, because all they ever wanted
was to be different and Buddhism planted
the seed of a new Me in a stunted
.
self-image. Because they insist on roaming
the city in off-white robes, deflecting
the sun's hot gaze, saffron being
.
too conspicuous and white being too damned
unprofound and likely to be sandwiched
between red and blue in a crowd of Americans.
http://www.poetrynet.org/month/archive/su/buddhist.html
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
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.
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.
If you could do Bitbucket, that would be awesome (considering Bitbucket already has native Hipchat, Jira, etc.)