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...
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.
I find that Pivotal is pretty opinionated with the workflow you use. Specifically, it is meant for an agile process that is exactly that Pivotal (the consulting group) uses to develop their client products.
Pivotal is extremely opinionated. Seems like people love it or hate it. JIRA is totally unopinionated and is what you make of it. I've had awful JIRA workflows imposed on me and it's the worst. My current company is generous with admin rights so we pick the flow we want for every project and it's great.
I don't know much about carpentry, but I've seen that they often build custom patterns and guides to make the work on a particular job easier. Maybe they need to cut the same angle or size or shape many times, or drill perfectly aligned holes, whatever. They don't go out and buy tools that specifically match the requirements of that job, because that would be silly. Who would make such a thing, and what do you do if it's not quite perfect? Instead they use the materials around them to create helpers and guides and patterns.
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.
I guess tags/status/naming hasd a function similar to interpunction: It can guide the consumer of the info in how to relate the items together. Some structure the blurp does not hurt ;)
in that case, you add https://reviewable.io into the mix. now you have GitHub issues managed via a kanban like board, and peer review with everything going through pull requests.
the pull request is blocked until review is complete, and tickets are automatically closed with pull requests. it's a pretty great workflow
When I see the above definition of mental overhead associated with these tools I immediately think "JIRA" because it can literally be configured in millions of different ways, and people seem to like to configure the hell out of it.
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 JIRA 6.4 does is suggest preconfigured workflow templates. What JIRA 7 does is, separate software tracking (with Agile boards, Git branches, code reviews and builds) from service desk or basic ticket management.
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.
For me, being a useful piece of opinionated software means "hey, we want you to do things this way."
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.
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
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?
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.
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.
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.
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.
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.
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...
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.
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.
> 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.
Together we obviously represent a pretty small sample, but I'm curious what OS you use? One of the reasons I like MacOS is because the apps are typically better designed than what I got when I used Windows or Linux as my desktop (don't get me started on Linux UIs).
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. :)
There is no fundamental reason why native apps can not expose shareable links just like any other. And on the other hand with the prevalence of single page webapps etc its far from guaranteed that you can get usable links from webapps.
A web link is easily shareable on the assumption that anyone you send it to has a web browser. A link to a native app requires you to assume that the recipient has the app installed and is on a platform where app URL schemes are well-supported.
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.
None of them are great. Android and very recent iOS are doing OK. Desktop OSes are still pretty bad. Clicking a non-HTTP protocol link in Chrome pops up a huge, user-unfriendly "External Protocol Request" dialog that warns of a possible attack on my system. That's pretty par for the course for desktop browsers.
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.
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!
I'm using Linux but I won't consider installing a native application even if it were available, or if I had a Mac or Windows. Web apps proved to be good enough for issue tracking (maybe I'm telling this to the wrong people given your choice, which I respect), my browser is open all the time and it has offline capabilities. Furthermore, it can be updated more conveniently.
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.
When I worked at Apple we used a native Mac issue tracker. It was much nicer than anything I've used before or since. I hate having to click-refresh-back-forward in a browser window, whereas a native client can have multiple windows, one for my assigned list, one for a search I did, then I minimize that search window and make a new window for a new search, then I cmd-H to hide the whole app without also hiding my browser.
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.
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).
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.
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.
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?
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
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).
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.
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.
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!
> 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.
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?
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.
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
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.
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
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.
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.
> 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?
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 and 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.
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.
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
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?
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.
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.
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.
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...)