5 ms·

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 f

by kogir 11y ago

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.

cjbprime 11y ago
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?
- ProfDreamer 11y ago
  This is exactly what Bugs Everywhere does: http://www.bugseverywhere.org/ http://www.bugseverywhere.org/
- zem 11y ago
  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.
- TheTon 11y ago
  (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.
  - zokier 11y ago
    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.
    - CodyReichert 11y ago
      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.
lost_name 11y ago
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?
LocalPCGuy 11y ago
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.
panic 11y ago
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.
softawre 11y ago
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.
greggman 11y ago
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
- esailija 11y ago
  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.

by kogir 11y ago

cjbprime 11y ago

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?

ProfDreamer 11y ago
This is exactly what Bugs Everywhere does: http://www.bugseverywhere.org/ http://www.bugseverywhere.org/
zem 11y ago
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.
TheTon 11y ago
(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.
- zokier 11y ago
  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.
  - CodyReichert 11y ago
    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.

lost_name 11y ago

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?

LocalPCGuy 11y ago

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.

panic 11y ago

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.

softawre 11y ago

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.

greggman 11y ago

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

esailija 11y ago
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.