[outworlder]

> I've used both, and I can only imagine your complaints about JIRA's UI are due to how it's been configured for your use.

Exactly. There are some companies that go so overboard with Jira customizations that a single "create new issue" requires hitting page down three times to get to the end. And they arrive at that by adding a field here for the QA team, a field there for the Sales team...

In the end, you get a monster. New users will be exposed to that monster, not the vanilla Jira installation.

[omouse]

Right and now think about who is going to control the JIRA install: the manager or VP or CTO.

Fogbugz's interface prevents this kind of crazy customization and thus it acts as a defense against the craziness. For a custom workflow with Fogbugz you have to grab a plugin. To get my manager to install a plugin for JIRA took weeks (and I still never got access to the REST API or approval for one plugin months later). So Fogbugz is developer-friendly because it makes it harder for a manager to go in an lock things down and mess around. With JIRA, the micromanager seems to be bundled with JIRA... ;-)

[tom9729]

Managers find a way. They will just use (or invent) another tool that lets them do it how they want. Now you have two tools, and some poor schmuck (or the developers) will get stuck with the job of keeping them in sync.

[mwhuber]

We use vanilla Jira and I find it painful - over-reliance on modals, slow JS calls, etc.; I do enjoy Source Tree.

As a PM, Pivotal Tracker (used in a previous life) is one of the best work-tools I've ever used.

[keypusher]

Pivotal isn't really a bug tracker though, is it? It's more for tracking project tasks. On some projects, these might be similar things, but when you have a large QA team and customer support teams, I don't think it's going to cut it.

[mwhuber]

It just depends on the process you put around it. Our team wasn't huge - ~13 if you include QA - but effective use of labels and "task" state management made it great.