Show HN: Ship – A fast, native issue tracker for software projects
realartists.com
realartists.com
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...)
It's nothing novel, but it works well for us and we think will work well for other teams, even large ones.
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.
(I very much agree with your point)
* Pivotal Tracker is the SaaS software you're thinking of.
* Pivotal Labs is the agile and lean engineering/design/product/data science consultancy, from which Pivotal Tracker first emerged as a product.
* Pivotal is the parent company formed from Pivotal Labs and other products (notably Cloud Foundry, Spring, Greenplum, Gemfire) several years ago.
Disclaimer: I'm work at Pivotal Labs.
My first thought is we should add a "did you mean Tracker?" link somewhere, but that's got problems too. We work on a lot of software.
This is what I get for not pair-posting.
the pull request is blocked until review is complete, and tickets are automatically closed with pull requests. it's a pretty great workflow
It sounds like you could use the same kind of thing. Someone entering an issue doesn't need to be presented with a JIRA server and told to go at it. A tool like JIRA has some tools for guiding users (e.g. embeddable, customizable javascript forms). And where JIRA isn't cutting it, any self-respecting tool has an API that gives you all the power in the world. You want a dashboard that shows you just the charts you want, and clearly explains what they're showing? There's a lot of material all around you to make building that for yourself easy. Wishing for an opinionated and rigid solution that happens to match what a project of nontrivial complexity needs is not realistic.
Unless by JIRA does this now you mean, "JIRA allows for a many confusing setups, leading to the above situation more often than not" I have to disagree here.
What it doesn't do is require a workflow. It is possible to start with a Scrum wf, then progressively change it into a waterfall hyena with cumbersome required fields and impossible permission-based transitions. In fact, I've met many people who have the opinion that JIRA is cumbersome, just to discover that their sysadmin is a knee-jerk person who blocks any initiative within their entreprise using misconfigured software.
JIRA isn't opinionated in the sense of OP. OP suggests that saying "We use [Bug tracker name]" is equivalent to saying "We're Scrum with branch tracking and timetracking", because the bugtracker would enforce checks and a layout without much possible configuration.
For example, Trello or Bitbucket Issues are quite opinionated bugtrackers.
Then rely on the users being smart enough to not hang themselves with the rope given.
What you're talking about is, as you said, bad management. The reason opinionated software comes and goes, and JIRA stays is specifically because just like you can build sync on top of async, you can build opinionated on top of flexible, but not vice versa.
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.
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.
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.
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.
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.
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.
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...
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.
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.
Don't get me wrong, I've seen some bad app UIs on the Mac -- even from Apple. The old skeuomorphic days are coming back to me as I type this and I'm still sad for them. :)
Direct linking inside apps has been enough of a pain in the mobile world that entire companies have been built around it -- and the solution that those companies tend to use is built on web links. Android and iOS have also been moving in that direction.
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¢
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!
Which platform do you prefer?
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).
Another point is that issues are useful if shared. I shared links to issues to customers and coworkers countless times and included them in reports. A web client solves at least one problem, maybe two. First, they might not want to install (or pay for) another tool. Second, Ship references issues with the ship:// url, which won't work unless you have Ship installed. A https:// url would work for everybody but then you need to share two different URLs which would be cumbersome. I'm sure you already found a solution to that.
Your site doesn't address explicitly one fundamental aspect: the data are hosted on your server, like issues stored in GitHub, Jira, etc and you're selling the service, or will be. Is this correct? What's the pricing? Thanks.
At my current company we have an in-house project/issue tracker system which isn't quite as good as Apple's IMHO but very customized to this company's workflow. For my at-home consulting projects I try various web apps, most recently Mantis.
But disregarding my preference, what is your analytics showing in terms of OS usage?
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.
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?
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://prosody.im/issues/static/readme.html https://hg.prosody.im/issue-tracker/
Also see https://prosody.im/issues/issue/2 ;)
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.
My favorite was Simple Defects: http://syncwith.us/sd/
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!
"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.
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.
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
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.
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.
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?
We always planned to make a web version, but don't expect we'll be able to do too much better than existing solutions.
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.
I use Windows, but a web client is probably next.
There's no excuse for this.
We're working with developers daily to make it a better experience.