Show HN: See GitHub issues on a Kanban board
kaizenboard.xyz
kaizenboard.xyz
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?
The owner is just opinionated and refused to merge each and every PR. So Gitea fork was created. I still use gogs.
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
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.
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.
I haven't compared them recently, but maintaining a project, "on-top" of GitHub front-end, seem quite a difficult task.
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.
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.
Nice project though.
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.