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?
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.
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.
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?
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 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.
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 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.
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.
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.
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.
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?