11 ms·

Show HN: Ship – A fast, native issue tracker for software projects

219 points by kogir 11y ago

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.
volaski 11y ago
great domain! :)
- TomorrowRich 11y ago
  my thoughts too
bifrost 11y ago
Looks great!
nathas 11y ago
Looks neat. It's a bummer that it's Mac-only
- kogir 11y ago
  We're planning to support the web and other native platforms. I use Windows. Which platform do you prefer?
  - Rickasaurus 11y ago
    I'd love to see this on Windows and and least some kind of viewer for iPhone as well.
    - acgourley 11y ago
      There is an iOS beta listed on the site now.
  - deleted 11y ago
    [deleted]
  - TheWiseOne 11y ago
    Another vote for Windows from me. If you are planning on expanding to other platforms (iOS and Android, especially), maybe considering going with a C#/Xamarin-based project. It'll save you a lot of work by allowing you to re-use the underlying code for your app(s).
  - hockeybias 11y ago
    Windows please. Looks great!
  - onetwotree 11y ago
    Linux please. If you're going to target the web, you might as well build a desktop app with electron[1]. [1] http://electron.atom.io/ http://electron.atom.io/
    - 11y ago
acgourley 11y ago
What will the pricing be like?
schnevets 11y ago
It looks great - and extremely tempting since I am currently going through QA hell with a project, but I cannot tell from your website whether or not this will stay a free product. Do you or your partner have a plan to commercialize the software? Add premium features? Or is this a side-project whose future is still being decided?
- kogir 11y ago
  Pricing will be comparable with similar tools - probably on a per-seat basis, but we'll do something special for early adopters. It will always be possible to export all your data. We have that now, it's just not exposed yet. Here's an example of the demo database: https://www.dropbox.com/s/ujix7vch7ramlmx/data.json?dl=0 https://www.dropbox.com/s/ujix7vch7ramlmx/data.json?dl=0
clay_to_n 11y ago
General question about issue trackers in general: How do people usually integrate these with other project management tools, like Jira or Trello? Some of the issues shown on the site seem like what I would call features as opposed to bugs. Is it a different use case? Does it work to have software "features" in Jira or Trello or similar and then use an issue tracker like Ship for just the bugs? I used to use a system of filing bugs as GitHub issues and then moving them into Trello when they've been scoped and prioritized and are ready to work on - but lately I've just been putting them straight into Trello. Any insight on workflows for combining software like this with Trello or Jira would be appreciated!
- dragonwriter 11y ago
  > Some of the issues shown on the site seem like what I would call features as opposed to bugs. Is it a different use case? Does it work to have software "features" in Jira or Trello or similar and then use an issue tracker like Ship for just the bugs? "Features" and "bugs" are essentially the same thing: differences between the current and desired state of a piece of software. Tracking them in separate tools seems to be a bad idea.
  - hockeybias 11y ago
    Agreed. That is how we do it (with FogBugz).
  - clay_to_n 11y ago
    That makes sense. My next question then would be: Can you use Ship or some other issue tracker to manage the software lifecycle reasonably? Planning for a sprint or release, development, code review, QA, etc. I'm used to having these as columns in Trello or Jira - is the alternative to do them as labels or similar? Or would you use some other tool for them?
- kogir 11y ago
  I personally want everything to live in one place. We throw everything in Ship and then use appropriate queries when we're project planning. If bugs are in one place, and features are in another, it's hard to get a complete overview of what's going on.
foo123456 11y ago
regarding the architecture: basically is (or is very much like) event sourcing, right? I mean, kind of like an append-only log, that will grow forever.
- TheTon 11y ago
  (author here) Yes, that's right, at least at the source of truth on the server. Clients automatically rewrite or squash their local history a little bit prior to pushing it to the server to minimize log length and to avoid showing intermediate editing states that were never communicated to anyone else (just like you might squash git commits), but every important state is preserved in the log.
  - foo123456 11y ago
    ok tnx! as a dev myself, i'm still not convinced about this whole append-only/time-machine approach (i'm talking more about event sourcing in general, not your specific architecture). it smells too much architecture astronaut (see http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html and http://www.joelonsoftware.com/items/2008/05/01.html http://www.joelonsoftware.com/items/2008/05/01.html). it feels like this incredibly heavy monster system that theoretically may let you do anything, but in practice, at the end of the day, is not able to do it because it is impractical to use. again, not necessarily yours.
    - mbrock 11y ago
      Git itself is exactly such an append-only system, and it's one of the most reliable and useful tools ever. What's the problem?
  - alkonaut 11y ago
    > Yes, that's right, at least at the source of truth on the server. I assume the server holds human-readable issue id's, but clients do not then (until they are pushed to the server). Do you assign just random guids to issues on the clients and then issue running issue numbers to them once they are on the server? If so, if I enter two issues on the client side with a reference from one to the other, how do I enter the cross-reference before I have the (server issued) issue id for either issue?
swanson 11y ago
I kind of wish that software issue trackers/ALM/SCM/whatever-the-fuck-its-called-today would be a bit more opinionated and enforce some set of practices. I think some people are looking to these tools for help building an effective software workflow and are left with a configurable product that can work great -- if you've run projects effectively before. But if you haven't it turns into a nightmare. I know that workflow, work item types, how to transition between states is kind of a deeply personal thing -- but often I wish I could just eliminate the mental overhead of trying to figure out how this project, manager, and team are using Jira/Rally/TFS/Trello/Pivotal and what state I need to put something at what time and which fields need to filled out and if we are using tags and why adding this critical bug to the current sprint is giving me a big scary warning and are we calling this a feature or a story or an epic or an enhancement or a task or a subtask and if I want to be looking at what this tool is calling a burndown chart or if its really the milestone progress chart in this project and what was that filter you used to see bugs that were open and also defined because I'm not seeing the bug that my customer is asking about and are we supposed to put new information as a comment or in the description or is it a new linked issue or a new child task or a new child bug or a link to the integrated wiki page... (maybe I'm just the only one with these scars...)
- kogir 11y ago
  I very much agree. We have a workflow we really like that we'll be blogging about, and Ship is optimized to support it. It's nothing novel, but it works well for us and we think will work well for other teams, even large ones.
  - piptastic 11y ago
    These highly customizable products should have "workflow settings" that change a large group of settings to optimize a specific work flow. That and give an explanation/demo of the flow so that the user knows what to do. That way if you don't want to figure out what works best for you and want to be told what to do, you can just set one of these workflows and disseminate that information to the people who will be using it.
randomor 11y ago
Interesting angle approaching this problem, from a continuous log cacheable on the client. Just downloaded and used demo briefly so take this for whatever it's worth: - What about a sidebar for the issue detail, instead of a floating window? - A send button when posting comment, not just CMD-S - The issues list could use some bigger font size and spacing
GordyMD 11y ago
I just downloaded the Mac OS X version to try it out and upon clicking 'Demo Mode' I am presenting with the next screen which is mostly blank (Screenshot: http://i.imgur.com/evyyF5v.png http://i.imgur.com/evyyF5v.png).
- kogir 11y ago
  Thanks for letting us know! That's a bummer. Sadly, I don't have any guesses as to why. I'm happy to help debug if you want: nick@realartists.com, but understand if you don't want to spend any more time on it.
  - sharp11 11y ago
    No no no.... No need to apologize! Just chase the bug. This looks awesome for a V1! Kudos to you guys.
tedmiston 11y ago
Startups would love to use this if you building Jira compatibility.
quickpost 11y ago
I like this. A lot. What's the pricing? SaaS vs one time fee?
dangoor 11y ago
This reminds me a bit of Bee[1] which puts a native Mac interface on top of existing issue trackers (GitHub, JIRA, FogBugz). On the one hand, Bee's approach seems like a win in the short term because people don't have to switch where there data lives or buy in to an off-premise service if that's not what they want. Longer-term, though, the data model of the existing systems could prove to be limiting if you've got good ideas for how to change the approach here. Issue tracking "at scale" is hard for the same reason that a lot of software becomes complicated: when applied to the real world, new workflow needs and such pop up frequently. As an example: security issues that may need to have a restricted audience for a time. The release model for web-based software is different from that of desktop or mobile software. There's plenty of room to make this better! Good luck in finding a winning path forward! [1]: http://www.neat.io/bee/ http://www.neat.io/bee/
gregmac 11y ago
One of the great features of a web-based bug tracker is that I can paste ticket links in various places, which people can view with a single click. On top of that, it's yet another app to be installed and kept up to date, which everyone on your team has to independently do. If it auto-updates, presumably one person updating will update the database and then require everyone else to upgrade to continue use? I can't tell you how annoyed I'd be if it did that right after I finished entering info for a new ticket.. I appreciate the feature set and motivations from that perspective, but I have trouble with the native app part. I'm a very heavy app user though; Aside from my actual IDE, git, and the executable code I am actually writing (generally web apps or background daemons), everything I do is web-based: Email, chat, docs, bug tracker, wiki, build server, repository management, notes, news, music...
- kogir 11y ago
  It's possible you've not experienced the problems that we have with web based issue trackers. That's ok. Ship may not be the right tool for you. As for all-at-once upgrades, so far it's not been an issue. The client ignores things it doesn't understand and we've kept the server backwards compatible for the last 7 months. We expect to be able to continue to do so.
  - sulam 11y ago
    I actually love the native part, fwiw. I've often thought that a native JIRA client could be way easier to use than their web interface. Of course they could also just invest in making their web interface much better, but native expectations are naturally very high, and a lot of the horrible UX practices we accept on the web wouldn't fly in a native environment. Essentially it would have no choice but to be better.
    - andybak 11y ago
      > a lot of the horrible UX practices we accept on the web wouldn't fly in a native environment. I'm interested by this statement. I like to think I just web and native apps by the same standards. I've seen horrible UX in both - and great UX in both. I currently lean towards favouring web apps based purely on my feeling that I tend to get a better UI on average.
codemac 11y ago
This makes me reminisce, we had lots of bug trackers that were close to having these kinds of features when git was first hitting in the mid-ish 2000's. My favorite was Simple Defects: http://syncwith.us/sd/ http://syncwith.us/sd/
awaxman11 11y ago
After looking through the documentation it doesn't seem like the following features exist. Would love to know if I'm missing something, or if not the thought process behind excluding these features: 1) Ability to prioritize problems on a more granular level than the priority type. This would help people prioritize which problems they want to work on next in a kanban type format 2) Story points or the ability to estimate the approximate size of the task
- kogir 11y ago
  We don't personally like agile. We would like to add the ability to order problems - both a personal work order queue, like "I'm doing this, then that, etc." and globally within a milestone, which I think is what you had in mind. Arbitrary attributes are supported, so you could track point estimates that way, but you're right, nothing like that is surfaced at the top level. Perhaps we can think of a good way to surface things like this without reaching Jira-custom-fields level of pain.
  - awaxman11 11y ago
    Thanks for the response! That's exactly what I had in mind re: ability to order problems at a more granular level. Didn't realize that arbitrary attributes are supported, that's great
alienasa 11y ago
Why OSX 10.10 or later?
- kogir 11y ago
  We don't have older machines to test on, and we built it for ourselves first. I use Windows, but a web client is probably next.
Zash 11y ago
We in the Prosody project were using Google Code and the project leader really liked their issue tracker. When the shutdown was announced, we looked around but found nothing that met our needs, so we ended up writing our own. I'm personally quite pleased with the result: https://prosody.im/issues https://prosody.im/issues https://prosody.im/issues/static/readme.html https://prosody.im/issues/static/readme.html https://hg.prosody.im/issue-tracker/ https://hg.prosody.im/issue-tracker/ Also see https://prosody.im/issues/issue/2 https://prosody.im/issues/issue/2 ;)
- lemming 11y ago
  That actually looks very nice, thanks!
Keats 11y ago
You should mention in the article it's mac only
TheJixers 11y ago
We have built an alternative to Jira and we're always looking to improve our product. Check out tool out - https://jixee.me https://jixee.me We're working with developers daily to make it a better experience.
condescendence 11y ago
iOS/OSX only? Meh. The real need is on every platform you haven't yet developed for. At my work right now we use TFS built in tracking tools. I can't even begin to described how annoying it is to work with that system. There are no tools right now that have a built-in workflow and are minimal for windows/linux. There's tons of bug/tracking systems but they tend to take the approach of giving you tons of features and allowing you to make your own workflow which ends up creating a big mess if people get lazy with filing issues/tickets. I'm sorry I know its a good first step, but those who need minimal issue tracking and such are probably on a windows/linux platform where current solutions are bloated and maybe even too feature filled. Then again this is only my 2¢
Laaw 11y ago
What does 'native' mean in this context?
- CodyReichert 11y ago
  In this context it means that the software was built specifically for Macs. Ie, not a web/mobile app.
coherentpony 11y ago
It's strange to me that although distributed version control systems are very popular, we all use centralised issue trackers for them.
- kyberias 11y ago
  But it really isn't strange. Maybe because there is a lot of value in seeing a real-time, shared, up-to-date view of the issues including status information.
mLuby 11y ago
Kudos for doing conflicts the right way!
mwcampbell 11y ago
Looks like the Mac client is written in ObjC, judging by the small size of the binary and the lack of any recognizable language runtime libraries. Is that correct? If so, I guess you'll have to write a new client from scratch for other platforms.
chintanp 11y ago
This looks awfully similar to a tool called as radar when I worked at a fruit company in cupertino.
- kogir 11y ago
  Honestly, it looks more like Mail.app. It really will if we offer a single window mode. My co-founder, James, most recently worked at Apple. Pretending he wasn't influenced at all by (the good parts) of Radar would be disingenuous.
lemming 11y ago
I'd actually be interested in trying this, since I have a lot of issues and I'm getting frustrated with Github issues. But I'd need my users to be able to file and comment on issues online - it looks like this is not possible right now. Is that planned?
- kogir 11y ago
  Consensus seems to be that we need to build out the web client next. We always planned to make a web version, but don't expect we'll be able to do too much better than existing solutions.
  - lemming 11y ago
    Well, I think the "better than existing solutions" part is the offline client - mostly I just need a web front end for users to get the issues into the system. I'm happy for all the searching etc to be only in the desktop client.
vbezhenar 11y ago
I like native part, I like offline support (sometimes have to work without Internet). I don't like cloud nature (if I understood it correctly, I can't host my own server) and it's probably not open-source which I don't like too (would be too hard to make non-Windows server). Overall it's a very interesting approach and I'll consider using it. Thanks for making it.
TomorrowRich 11y ago
Why would you make it require Yosemite 10.10? This is absurd developer laziness. Spend an hour making it compatible with OS versions from the last couple of years. There's no excuse for this.
- PakG1 11y ago
  Out of curiosity, why wouldn't you upgrade? I know Yosemite had its issues, but El Capitan seems better. I agree that having something available for previous versions is probably a good thing. But just curious why you specifically wouldn't upgrade.
tokenizerrr 11y ago
Looks nice. Also looks utterly unusable unless you can guarantee that everyone you work with runs a Mac, which is not an option.
pluma 11y ago
s/native/OSX/

219 points by kogir 11y ago

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.

volaski 11y ago

great domain! :)

TomorrowRich 11y ago
my thoughts too

bifrost 11y ago

Looks great!

nathas 11y ago

Looks neat. It's a bummer that it's Mac-only

kogir 11y ago
We're planning to support the web and other native platforms. I use Windows. Which platform do you prefer?
- Rickasaurus 11y ago
  I'd love to see this on Windows and and least some kind of viewer for iPhone as well.
  - acgourley 11y ago
    There is an iOS beta listed on the site now.
- deleted 11y ago
  [deleted]
- TheWiseOne 11y ago
  Another vote for Windows from me. If you are planning on expanding to other platforms (iOS and Android, especially), maybe considering going with a C#/Xamarin-based project. It'll save you a lot of work by allowing you to re-use the underlying code for your app(s).
- hockeybias 11y ago
  Windows please. Looks great!
- onetwotree 11y ago
  Linux please. If you're going to target the web, you might as well build a desktop app with electron[1]. [1] http://electron.atom.io/ http://electron.atom.io/
  - 11y ago

acgourley 11y ago

What will the pricing be like?

schnevets 11y ago

It looks great - and extremely tempting since I am currently going through QA hell with a project, but I cannot tell from your website whether or not this will stay a free product. Do you or your partner have a plan to commercialize the software? Add premium features? Or is this a side-project whose future is still being decided?

kogir 11y ago
Pricing will be comparable with similar tools - probably on a per-seat basis, but we'll do something special for early adopters. It will always be possible to export all your data. We have that now, it's just not exposed yet. Here's an example of the demo database: https://www.dropbox.com/s/ujix7vch7ramlmx/data.json?dl=0 https://www.dropbox.com/s/ujix7vch7ramlmx/data.json?dl=0

clay_to_n 11y ago

General question about issue trackers in general: How do people usually integrate these with other project management tools, like Jira or Trello? Some of the issues shown on the site seem like what I would call features as opposed to bugs. Is it a different use case? Does it work to have software "features" in Jira or Trello or similar and then use an issue tracker like Ship for just the bugs? I used to use a system of filing bugs as GitHub issues and then moving them into Trello when they've been scoped and prioritized and are ready to work on - but lately I've just been putting them straight into Trello. Any insight on workflows for combining software like this with Trello or Jira would be appreciated!

dragonwriter 11y ago
> Some of the issues shown on the site seem like what I would call features as opposed to bugs. Is it a different use case? Does it work to have software "features" in Jira or Trello or similar and then use an issue tracker like Ship for just the bugs? "Features" and "bugs" are essentially the same thing: differences between the current and desired state of a piece of software. Tracking them in separate tools seems to be a bad idea.
- hockeybias 11y ago
  Agreed. That is how we do it (with FogBugz).
- clay_to_n 11y ago
  That makes sense. My next question then would be: Can you use Ship or some other issue tracker to manage the software lifecycle reasonably? Planning for a sprint or release, development, code review, QA, etc. I'm used to having these as columns in Trello or Jira - is the alternative to do them as labels or similar? Or would you use some other tool for them?
kogir 11y ago
I personally want everything to live in one place. We throw everything in Ship and then use appropriate queries when we're project planning. If bugs are in one place, and features are in another, it's hard to get a complete overview of what's going on.

foo123456 11y ago

regarding the architecture: basically is (or is very much like) event sourcing, right? I mean, kind of like an append-only log, that will grow forever.

TheTon 11y ago
(author here) Yes, that's right, at least at the source of truth on the server. Clients automatically rewrite or squash their local history a little bit prior to pushing it to the server to minimize log length and to avoid showing intermediate editing states that were never communicated to anyone else (just like you might squash git commits), but every important state is preserved in the log.
- foo123456 11y ago
  ok tnx! as a dev myself, i'm still not convinced about this whole append-only/time-machine approach (i'm talking more about event sourcing in general, not your specific architecture). it smells too much architecture astronaut (see http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html and http://www.joelonsoftware.com/items/2008/05/01.html http://www.joelonsoftware.com/items/2008/05/01.html). it feels like this incredibly heavy monster system that theoretically may let you do anything, but in practice, at the end of the day, is not able to do it because it is impractical to use. again, not necessarily yours.
  - mbrock 11y ago
    Git itself is exactly such an append-only system, and it's one of the most reliable and useful tools ever. What's the problem?
- alkonaut 11y ago
  > Yes, that's right, at least at the source of truth on the server. I assume the server holds human-readable issue id's, but clients do not then (until they are pushed to the server). Do you assign just random guids to issues on the clients and then issue running issue numbers to them once they are on the server? If so, if I enter two issues on the client side with a reference from one to the other, how do I enter the cross-reference before I have the (server issued) issue id for either issue?

swanson 11y ago

I kind of wish that software issue trackers/ALM/SCM/whatever-the-fuck-its-called-today would be a bit more opinionated and enforce some set of practices. I think some people are looking to these tools for help building an effective software workflow and are left with a configurable product that can work great -- if you've run projects effectively before. But if you haven't it turns into a nightmare. I know that workflow, work item types, how to transition between states is kind of a deeply personal thing -- but often I wish I could just eliminate the mental overhead of trying to figure out how this project, manager, and team are using Jira/Rally/TFS/Trello/Pivotal and what state I need to put something at what time and which fields need to filled out and if we are using tags and why adding this critical bug to the current sprint is giving me a big scary warning and are we calling this a feature or a story or an epic or an enhancement or a task or a subtask and if I want to be looking at what this tool is calling a burndown chart or if its really the milestone progress chart in this project and what was that filter you used to see bugs that were open and also defined because I'm not seeing the bug that my customer is asking about and are we supposed to put new information as a comment or in the description or is it a new linked issue or a new child task or a new child bug or a link to the integrated wiki page... (maybe I'm just the only one with these scars...)

kogir 11y ago
I very much agree. We have a workflow we really like that we'll be blogging about, and Ship is optimized to support it. It's nothing novel, but it works well for us and we think will work well for other teams, even large ones.
- piptastic 11y ago
  These highly customizable products should have "workflow settings" that change a large group of settings to optimize a specific work flow. That and give an explanation/demo of the flow so that the user knows what to do. That way if you don't want to figure out what works best for you and want to be told what to do, you can just set one of these workflows and disseminate that information to the people who will be using it.

randomor 11y ago

Interesting angle approaching this problem, from a continuous log cacheable on the client. Just downloaded and used demo briefly so take this for whatever it's worth: - What about a sidebar for the issue detail, instead of a floating window? - A send button when posting comment, not just CMD-S - The issues list could use some bigger font size and spacing

GordyMD 11y ago

I just downloaded the Mac OS X version to try it out and upon clicking 'Demo Mode' I am presenting with the next screen which is mostly blank (Screenshot: http://i.imgur.com/evyyF5v.png http://i.imgur.com/evyyF5v.png).

kogir 11y ago
Thanks for letting us know! That's a bummer. Sadly, I don't have any guesses as to why. I'm happy to help debug if you want: nick@realartists.com, but understand if you don't want to spend any more time on it.
- sharp11 11y ago
  No no no.... No need to apologize! Just chase the bug. This looks awesome for a V1! Kudos to you guys.

tedmiston 11y ago

Startups would love to use this if you building Jira compatibility.

quickpost 11y ago

I like this. A lot. What's the pricing? SaaS vs one time fee?

dangoor 11y ago

This reminds me a bit of Bee[1] which puts a native Mac interface on top of existing issue trackers (GitHub, JIRA, FogBugz). On the one hand, Bee's approach seems like a win in the short term because people don't have to switch where there data lives or buy in to an off-premise service if that's not what they want. Longer-term, though, the data model of the existing systems could prove to be limiting if you've got good ideas for how to change the approach here. Issue tracking "at scale" is hard for the same reason that a lot of software becomes complicated: when applied to the real world, new workflow needs and such pop up frequently. As an example: security issues that may need to have a restricted audience for a time. The release model for web-based software is different from that of desktop or mobile software. There's plenty of room to make this better! Good luck in finding a winning path forward! [1]: http://www.neat.io/bee/ http://www.neat.io/bee/

gregmac 11y ago

One of the great features of a web-based bug tracker is that I can paste ticket links in various places, which people can view with a single click. On top of that, it's yet another app to be installed and kept up to date, which everyone on your team has to independently do. If it auto-updates, presumably one person updating will update the database and then require everyone else to upgrade to continue use? I can't tell you how annoyed I'd be if it did that right after I finished entering info for a new ticket.. I appreciate the feature set and motivations from that perspective, but I have trouble with the native app part. I'm a very heavy app user though; Aside from my actual IDE, git, and the executable code I am actually writing (generally web apps or background daemons), everything I do is web-based: Email, chat, docs, bug tracker, wiki, build server, repository management, notes, news, music...

kogir 11y ago
It's possible you've not experienced the problems that we have with web based issue trackers. That's ok. Ship may not be the right tool for you. As for all-at-once upgrades, so far it's not been an issue. The client ignores things it doesn't understand and we've kept the server backwards compatible for the last 7 months. We expect to be able to continue to do so.
- sulam 11y ago
  I actually love the native part, fwiw. I've often thought that a native JIRA client could be way easier to use than their web interface. Of course they could also just invest in making their web interface much better, but native expectations are naturally very high, and a lot of the horrible UX practices we accept on the web wouldn't fly in a native environment. Essentially it would have no choice but to be better.
  - andybak 11y ago
    > a lot of the horrible UX practices we accept on the web wouldn't fly in a native environment. I'm interested by this statement. I like to think I just web and native apps by the same standards. I've seen horrible UX in both - and great UX in both. I currently lean towards favouring web apps based purely on my feeling that I tend to get a better UI on average.

codemac 11y ago

This makes me reminisce, we had lots of bug trackers that were close to having these kinds of features when git was first hitting in the mid-ish 2000's. My favorite was Simple Defects: http://syncwith.us/sd/ http://syncwith.us/sd/

awaxman11 11y ago

After looking through the documentation it doesn't seem like the following features exist. Would love to know if I'm missing something, or if not the thought process behind excluding these features: 1) Ability to prioritize problems on a more granular level than the priority type. This would help people prioritize which problems they want to work on next in a kanban type format 2) Story points or the ability to estimate the approximate size of the task

kogir 11y ago
We don't personally like agile. We would like to add the ability to order problems - both a personal work order queue, like "I'm doing this, then that, etc." and globally within a milestone, which I think is what you had in mind. Arbitrary attributes are supported, so you could track point estimates that way, but you're right, nothing like that is surfaced at the top level. Perhaps we can think of a good way to surface things like this without reaching Jira-custom-fields level of pain.
- awaxman11 11y ago
  Thanks for the response! That's exactly what I had in mind re: ability to order problems at a more granular level. Didn't realize that arbitrary attributes are supported, that's great

alienasa 11y ago

Why OSX 10.10 or later?

kogir 11y ago
We don't have older machines to test on, and we built it for ourselves first. I use Windows, but a web client is probably next.

Zash 11y ago

We in the Prosody project were using Google Code and the project leader really liked their issue tracker. When the shutdown was announced, we looked around but found nothing that met our needs, so we ended up writing our own. I'm personally quite pleased with the result: https://prosody.im/issues https://prosody.im/issues https://prosody.im/issues/static/readme.html https://prosody.im/issues/static/readme.html https://hg.prosody.im/issue-tracker/ https://hg.prosody.im/issue-tracker/ Also see https://prosody.im/issues/issue/2 https://prosody.im/issues/issue/2 ;)

lemming 11y ago
That actually looks very nice, thanks!

Keats 11y ago

You should mention in the article it's mac only

TheJixers 11y ago

We have built an alternative to Jira and we're always looking to improve our product. Check out tool out - https://jixee.me https://jixee.me We're working with developers daily to make it a better experience.

condescendence 11y ago

iOS/OSX only? Meh. The real need is on every platform you haven't yet developed for. At my work right now we use TFS built in tracking tools. I can't even begin to described how annoying it is to work with that system. There are no tools right now that have a built-in workflow and are minimal for windows/linux. There's tons of bug/tracking systems but they tend to take the approach of giving you tons of features and allowing you to make your own workflow which ends up creating a big mess if people get lazy with filing issues/tickets. I'm sorry I know its a good first step, but those who need minimal issue tracking and such are probably on a windows/linux platform where current solutions are bloated and maybe even too feature filled. Then again this is only my 2¢

Laaw 11y ago

What does 'native' mean in this context?

CodyReichert 11y ago
In this context it means that the software was built specifically for Macs. Ie, not a web/mobile app.

coherentpony 11y ago

It's strange to me that although distributed version control systems are very popular, we all use centralised issue trackers for them.

kyberias 11y ago
But it really isn't strange. Maybe because there is a lot of value in seeing a real-time, shared, up-to-date view of the issues including status information.

mLuby 11y ago

Kudos for doing conflicts the right way!

mwcampbell 11y ago

Looks like the Mac client is written in ObjC, judging by the small size of the binary and the lack of any recognizable language runtime libraries. Is that correct? If so, I guess you'll have to write a new client from scratch for other platforms.

chintanp 11y ago

This looks awfully similar to a tool called as radar when I worked at a fruit company in cupertino.

kogir 11y ago
Honestly, it looks more like Mail.app. It really will if we offer a single window mode. My co-founder, James, most recently worked at Apple. Pretending he wasn't influenced at all by (the good parts) of Radar would be disingenuous.

lemming 11y ago

I'd actually be interested in trying this, since I have a lot of issues and I'm getting frustrated with Github issues. But I'd need my users to be able to file and comment on issues online - it looks like this is not possible right now. Is that planned?

kogir 11y ago
Consensus seems to be that we need to build out the web client next. We always planned to make a web version, but don't expect we'll be able to do too much better than existing solutions.
- lemming 11y ago
  Well, I think the "better than existing solutions" part is the offline client - mostly I just need a web front end for users to get the issues into the system. I'm happy for all the searching etc to be only in the desktop client.

vbezhenar 11y ago

I like native part, I like offline support (sometimes have to work without Internet). I don't like cloud nature (if I understood it correctly, I can't host my own server) and it's probably not open-source which I don't like too (would be too hard to make non-Windows server). Overall it's a very interesting approach and I'll consider using it. Thanks for making it.

TomorrowRich 11y ago

Why would you make it require Yosemite 10.10? This is absurd developer laziness. Spend an hour making it compatible with OS versions from the last couple of years. There's no excuse for this.

PakG1 11y ago
Out of curiosity, why wouldn't you upgrade? I know Yosemite had its issues, but El Capitan seems better. I agree that having something available for previous versions is probably a good thing. But just curious why you specifically wouldn't upgrade.

tokenizerrr 11y ago

Looks nice. Also looks utterly unusable unless you can guarantee that everyone you work with runs a Mac, which is not an option.

pluma 11y ago

s/native/OSX/