Hacker News Reader

Comment by kogir | Hacker News Reader

Hey everyone!

James and I made Ship because we were frustrated with other tools we've had to use. It's focused on developer productivity and meant to be used frequently without wasting your time.

But seriously, we'd love feedback, both good and bad.

View on HN

Native is an anti-feature for me. Doesn't run on the platforms I need. Some platforms will be left behind or not get features as you're creating more work for yourselves and you have finite time. Can't check status on a friend's/co-workers machine. Can't use in a locked down Corp environment. And ... I have to trust your app not to do all the nasty things a native app can do for arguably zero benefit given your competitors have all demonstrated web based works

Also all the stated reasons for using native are actually wrong and just as possible in web app, or will be by end of 2016.

Why not a web app that is responsive so it can be used on mobile or in a desktop browser?

I can't speak for all developers, but I would hate to be forced to use my issue tracker on an iOS device (really any mobile/touch device). Mainly because at times I want to add code snippets, text is harder to type on touch, things like that.

edit: I see after reading some of the other comments that other platforms are planned. I would still question the logic of building applications rather than a web application though.

Have you considered using a source code repo as the store for issues? So that "git pull" syncs issues too, issues can exist on (to describe) branches, etc?

This is exactly what Bugs Everywhere does: http://www.bugseverywhere.org/

I tried using that sort of setup for a while (with ditz), and it really doesn't work as well as you'd think it might. Issues mostly want to refer to the global state of the project, and be accessible independent of where in the revision tree you have navigated.

One interesting compromise would be to tag issues with branches or commit hashes, and have a view filter for the tracker where you could search for all issues that applied to a given point in the tree.

(james here)

There are a few tools that do this already. I think it's an interesting approach, and probably makes sense for some people.

However, I feel like tying issues to closely to the code can be problematic. For example, for the product Ship itself there are multiple repositories, there's the server, the client, the web site, and a few libraries that we built along the way and open sourced.

We want to be able to file issues on our product without having to first determine in which repo the problem actually resides. We also want to be able to file umbrella issues or features that require us to make cross cutting code changes across multiple repositories.

I imagine that sort of issues would (mostly) be solved by a monorepo approach. Of course that is also drastically different in many other ways too.

That was my thought too. It sounds like having an issue tracker tightly coupled with the code/repo structure would be extremely useful in monorepo's.

The problem might not be that it's hard to figure out which issue a repo would belong too, but rather, having multiple (separate) repositories that have things in common.

It looks neat, and I like the offline idea.

I'm a big fan of Jira, and I have to disagree with your comment that nobody understands/knows the query language used to find issues. A lot of us here (at least the PMs/leads) know JQL as well as we know JS or whatever other language.

I feel like this is a cool hobby project, but a pretty rough/bold idea for a company to form behind... out of curiosity, which is it?

Thanks for building this! One small piece of feedback: putting comments / related / keywords in separate tabs feels wrong compared to just scrolling down to see them. The buttons to switch between the tabs feel small and hard to click.

Reply on news.ycombinator.com