Author here. This is my first Show HN post. I was just learning Vue and the GitHub API seemed like the perfect thing.
Known issues:
- Error 502, click (Retry for a live version)
- Demo only displays public repo issues
- Only shows top 100 issues
- If board not up-to-date, may require Shift+Reload
- Unauthenticated access has very low rate limit
- Card colors come from 'label' color and may be low contrast
[I now want it for PivotalTracker that I use at work.]
Looking forward to any/all feedback. Hope some find it useful.
Not at the moment. I enjoyed making it so much I could see carrying it on.
Also I'm not too well read on dual licensing. How can you merge contributions on an opensource license, then not have tainted your commercial offering?
Have you seen / used [Waffle](http://waffle.io) before? It's pretty much exactly this. It's free for open source projects and has a monthly fee for private ones. It's what I've used for a while, and my team at work uses it. It's pretty mature and has lots of features like creating your own columns, multiple repositories in a single board, integrations for tests/builds, PRs, and so forth.
I'm a big fan of ZH; the cross-project kanban board alone gives a huge productivity boost if you have multiple related projects with their own issue tracker.
I also use the Slack email app/integration to give each user in my org an address, and then pipe GitHub notifications to their own `#gh-username` channel. This brings GitHub comments out of email, with minimal disruption.
I'm hoping ZenHub adds a tasks feature that would let us assign/receive/track issue-based tasks. That's an important workflow tool we're currently lacking, but we're reluctant to add another tool to our chain.
They pushed a design update recently which fixed a lot of the issues I had with it such as glitches and slowness. They're doing a great job imo.
I wish we could reuse GitHub projects instead of having the projects be stored on the zenhub API. But GH projects are super lackluster still especially in terms of permissions.
I did a quick search when starting and found it as well as GitHub's own thing and some others. It looks great, but I was looking for something more lightweight for personal projects and Trello wasn't it.
Also remember not to let the existence of something even done well stop you from creating. There's lots of room for differentiating--it's not one size fits all. Pretailored is what the market needs.
Please don't take this as criticism :) I just wanted to make sure you're aware of what's out there, in case you haven't found it.
I often myself end up doing side projects and weeks later, regret not having done more research on existing solutions as I find one that covers my needs far better than I could have covered them myself.
Oh I didn't at all. For my first 'show' post, everyone here has been very welcoming and direct which is appreciated. Better than to fan a baseless project.
I'm just gapd to have found a side project I might keep up with.
I think my differentiator is 'lighter' but with a little more than Trello had.
Where is the most important feature of a Kanban board, limit work in process? At least display the limits in some way. Kanban is not just about showing cards in columns. The goal of a Kanban board is to eliminate overproduction.
True. But then even the limits are somewhat fuzzy. I find with an experienced or well led team, that if you don't take on much at once it works itself out. Otherwise it can get micromanagey when working cross-projects. With physical machines the can exactly work on one thing at a time, people might be optimal between 1 and 2. Technically you're still task switching one at a time but without the cognitive overhead of thinking about updating the tracker for multiple mid-day switches.
BTW, has anyone been getting 502 errors? I suspect it was the browsers unsolited fetching of /favicon.ico. I just gave it one. Will check nginx config after.
I wouldn't say anything is categorically better unless, hey wait do you think my thing is pure crap? :-)
Seriously though, I just want different things. From the GitHub v3 API I didn't see things like estimates or priorities, or whatever I may think of next. I use these every day so I'm just scratching an itch. If others like it too, all the merrier.
Nice project. I like seeing people make their own tools.
The part that jumps out at me, though, is that this had to be specifically targeted at GitHub Issues. Why is bug tracking still a bunch of silos? I hear programmers speak of "open standards" and "interoperability" and "separation of concerns", and still the otherwise smart engineers at Bugzilla/GitHub/BitBucket/Trac/Jira/Launchpad/FogBugz/... go and build these systems which are 98% identical but provide no common interface.
I can share events across calendars, vector images across graphics editors, audio files to hardware players with different codecs, source code history to different version control systems, and nearly every other impossible-sounding cross-platform conversion, but with bug tracking, the shoemaker's children go barefoot.
(The one platform that gets partial credit here is Debian, because they use plain email, and you can rsync yourself a copy of the entire database. It's not exactly pleasant but at least I can process everything with existing standard tools.)
What's the logic here? Those principles of software architecture are good for every type of software except bug trackers? If we keep your issues hostage, you're less likely to leave our service? We're each going to try to become dominant so our proprietary API is the standard?
36 comments
[ 2.9 ms ] story [ 90.6 ms ] threadKnown issues:
[I now want it for PivotalTracker that I use at work.]Looking forward to any/all feedback. Hope some find it useful.
Also I'm not too well read on dual licensing. How can you merge contributions on an opensource license, then not have tainted your commercial offering?
I'm a big fan of ZH; the cross-project kanban board alone gives a huge productivity boost if you have multiple related projects with their own issue tracker.
I haven't compared them recently, but maintaining a project, "on-top" of GitHub front-end, seem quite a difficult task.
Best UX / design I've seen for boards.
I also use the Slack email app/integration to give each user in my org an address, and then pipe GitHub notifications to their own `#gh-username` channel. This brings GitHub comments out of email, with minimal disruption.
I'm hoping ZenHub adds a tasks feature that would let us assign/receive/track issue-based tasks. That's an important workflow tool we're currently lacking, but we're reluctant to add another tool to our chain.
I wish we could reuse GitHub projects instead of having the projects be stored on the zenhub API. But GH projects are super lackluster still especially in terms of permissions.
Also remember not to let the existence of something even done well stop you from creating. There's lots of room for differentiating--it's not one size fits all. Pretailored is what the market needs.
I often myself end up doing side projects and weeks later, regret not having done more research on existing solutions as I find one that covers my needs far better than I could have covered them myself.
I'm just gapd to have found a side project I might keep up with.
I think my differentiator is 'lighter' but with a little more than Trello had.
Nice project though.
https://en.wikipedia.org/wiki/Kanban
The owner is just opinionated and refused to merge each and every PR. So Gitea fork was created. I still use gogs.
Seriously though, I just want different things. From the GitHub v3 API I didn't see things like estimates or priorities, or whatever I may think of next. I use these every day so I'm just scratching an itch. If others like it too, all the merrier.
The part that jumps out at me, though, is that this had to be specifically targeted at GitHub Issues. Why is bug tracking still a bunch of silos? I hear programmers speak of "open standards" and "interoperability" and "separation of concerns", and still the otherwise smart engineers at Bugzilla/GitHub/BitBucket/Trac/Jira/Launchpad/FogBugz/... go and build these systems which are 98% identical but provide no common interface.
I can share events across calendars, vector images across graphics editors, audio files to hardware players with different codecs, source code history to different version control systems, and nearly every other impossible-sounding cross-platform conversion, but with bug tracking, the shoemaker's children go barefoot.
(The one platform that gets partial credit here is Debian, because they use plain email, and you can rsync yourself a copy of the entire database. It's not exactly pleasant but at least I can process everything with existing standard tools.)
What's the logic here? Those principles of software architecture are good for every type of software except bug trackers? If we keep your issues hostage, you're less likely to leave our service? We're each going to try to become dominant so our proprietary API is the standard?