3 ms·

My issue with JIRA comes down fundamentally to their UI. I used to be a JIRA power user in the mid/late 2000s. I think that was the pinnacle of it feeling like

by atonse 8y ago

My issue with JIRA comes down fundamentally to their UI. I used to be a JIRA power user in the mid/late 2000s. I think that was the pinnacle of it feeling like a very powerful tool. You could do a lot with their table views, filters, saved views, etc. It was easy to add fields, etc. That's when they were an issue tracker and the primary interface for editing things was just a highly customizable table. Where JIRA started going off the rails is when they started to bolt on Agile methodologies to their existing system (which, in their defense, was where the whole industry was heading anyway). But the nail in the coffin (for 2 years now) is that their new UI is just so damn hard to use. I find myself CONSTANTLY frustrated with doing very simple things. The app is slow and doesn't feel snappy like an SPA does nowadays. The other day, I was on a screen share and trying to edit my notification settings (we were bulk editing a lot of stories and wanted to turn off the deluge of emails). I think the two of us in our screen share spent maybe 10 mins trying to find out where to shut down notifications, and failed. The UI is so damn convoluted. It's like the designers won every debate over any UX people, and focused on making things pretty instead of intuitive. For them to truly compete with today's tools, I don't think they have a choice but to throw out the existing app and start new.

beatgammit 8y ago
Awesome, I feel the same way. Just today, we were told to use a specific filter on our backlog so we could plan out the sprint. It took a bit to find it, and they had apparently set up a new board on an existing project so they could track issues in multiple projects. We plan a single sprint multiple projects because our team handles multiple projects (small company). Since adopting Jira, management kept changing how they wanted to use it (experimenting, can't blame them), and adjusting within Jira has been super painful. I ended up building a couple tools outside of Jira so I could get exactly the view I wanted. I went through this same process when management kept trying to tweak Bugzilla to get what we wanted, and I even ended up building a simple issue management application. I'm getting that itch again, so I'm just trying to figure out what people hate so I can know what to highlight. I don't think it'll go anywhere, but who knows!
- atonse 8y ago
  Good luck! One thing you might want to highlight is all the developer time that's wasted searching for things (or how to do things) in JIRA. It causes frustration and is a true waste of time. But again, I don't think there's one issue tracker to rule them all. Gitlab's appeal was less about it being way better, and more about it being fully integrated.
  - beatgammit 8y ago
    > I don't think there's one issue tracker to rule them all Oh, definitely. GitHub and GitLab issues are both pretty nice. However, they're not meant to be super featureful, and I think there's a niche between those types of issue trackers and Jira, where most people are actually probably better served by something simpler than Jira. Some very large projects are managed with GitHub/GitLab issues, so there's definitely an advantage there, but they don't work when you want to track other things with them (e.g. hardware design/release process, customer support tickets, etc). I just need to figure out what people dislike about Jira, then match the most common use cases making Jira's weaknesses my advantages. However, I'm not fully invested in it yet, but we'll see how much I get fed up with Jira/Gitlab issues (I work on projects that use both).

by atonse 8y ago

beatgammit 8y ago

Awesome, I feel the same way. Just today, we were told to use a specific filter on our backlog so we could plan out the sprint. It took a bit to find it, and they had apparently set up a new board on an existing project so they could track issues in multiple projects. We plan a single sprint multiple projects because our team handles multiple projects (small company). Since adopting Jira, management kept changing how they wanted to use it (experimenting, can't blame them), and adjusting within Jira has been super painful. I ended up building a couple tools outside of Jira so I could get exactly the view I wanted. I went through this same process when management kept trying to tweak Bugzilla to get what we wanted, and I even ended up building a simple issue management application. I'm getting that itch again, so I'm just trying to figure out what people hate so I can know what to highlight. I don't think it'll go anywhere, but who knows!

atonse 8y ago
Good luck! One thing you might want to highlight is all the developer time that's wasted searching for things (or how to do things) in JIRA. It causes frustration and is a true waste of time. But again, I don't think there's one issue tracker to rule them all. Gitlab's appeal was less about it being way better, and more about it being fully integrated.
- beatgammit 8y ago
  > I don't think there's one issue tracker to rule them all Oh, definitely. GitHub and GitLab issues are both pretty nice. However, they're not meant to be super featureful, and I think there's a niche between those types of issue trackers and Jira, where most people are actually probably better served by something simpler than Jira. Some very large projects are managed with GitHub/GitLab issues, so there's definitely an advantage there, but they don't work when you want to track other things with them (e.g. hardware design/release process, customer support tickets, etc). I just need to figure out what people dislike about Jira, then match the most common use cases making Jira's weaknesses my advantages. However, I'm not fully invested in it yet, but we'll see how much I get fed up with Jira/Gitlab issues (I work on projects that use both).