381–390 of 539 posts
I'm sometimes kind of surprised at how often I see people say they don't mind it. It's by far the tool I like the least out of everything I've used at any job I've ever been in.
How can it be proper to show me the outcome of applying JQL to a db query but refuse to show me the JQL because of an ownership/acl problem.
Want automation? Chain tasks but it has no "this" or "self" so that last thing you made? Have fun reconnecting to it.
So many options but no way to flatten them and define a template with specific ones: some are baked in and some can't be easily specified as important to float to top.
Still no clean way to uplift org to confluence with native support
Earlier quoted context omitted.
9. The text editor is still busted and I just don't understand why. It's one of the most important parts of the UX, please please fix it. Writing any kind of nicely formatted long form posts is a lost cause.
My gripe for the text editor—if you navigate away from the page, by an accidental click or keypress, all your text is lost. This kind of thing was solved 15 years ago; it's table stakes!
This results in a fun game of me trying out single backticks, triple backticks, braces, double braces, other miscellaneous punctuation symbols, and various indents before giving up and trying the formatting toolbar, only to waste another couple of minutes clicking around to see what works.
Somehow I can never remember what worked either, so I find myself repeating this ridiculous dance on at least a weekly basis.
Although IIRC, there was a recent update that at least harmonised the code formatting syntax between editors, although I can't remember if it actually worked....
Earlier quoted context omitted.
Yeah I've been defended Jira here in the past, too. My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some…
It's not a neutral tool. Jira makes micromanagement easy and trusting people hard; you can use it for good, but you're working against the grain of it the whole time. Everything is default deny (issues can only go through approved transitions, by default regular users can't change the available transitions), the default issue forms have way too many mandatory fields, and a bunch of reports that only micromanagers wan…
I'm in the Jira is actually pretty good camp. I've administered Jira instances from the ground up, including installation, integrating it with directory services, customizing workflows or just as a user in large and small organizations.
The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable. Some transitions make more sense than others. It was also quite tedious to create transitions from "all other states" to some state. So admins were incentivized to only allow transitions that immediately made sense to them and not bother with the others. From the end user perspective this obviously looks like draconian overlordship. While in reality in many cases its just too tedious. Atlassian has heard user complaints though and an "all states can transition here" option is available since some time ago and the default workflow for some types of projects are basically just a few workflow states that all have this transition as the only possible one. Basically transition from any state to any other state. No transition screens. That's pretty open.
If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira. Locked down workflows and transitions, restructured editability etc do have their place in many valid use cases. A simple one being as a customer facing tool where you need to enforce certain things directly because your customer is not first going to learn your conventions and then self apply these.
The same goes for mandatory fields. The only mandatory field you have to choose yourself really is the issue summary. Everything else if mandatory by default has default values. I have used many a Jira instance where Priority (a default mandatory field that also has a default value though) was all but ignored by everyone even if it was still on screen.
Can you elaborate on the reports that only micromanagers would ever use? I agree that some of them can be used by micromanagers as can a lot of Jira functionality. There are many that can also be very useful directly in the hands of teams.
Team managed projects are awesome because sharing Jira admin rights in a large org was hard. Because things are so configurable a good set of naming rules were essential. It was usually easier to set up individual instances for projects instead of having a shared instance for large orgs. And if you centralize administration too much then changes grind to a halt. I have shared admin right with many others successfully though where these standards were adhered to by everyone and changes to work flows, issue and custom field definitions and such were easy to get through. Just required discipline.
OK, so what don't I like about Jira? 1. It's extremely slow. 2. It's difficult to predict the effect of making any kind of change. 3. The permissions system is so convoluted, I can be the admin of a board, and yet not have permission to see a ticket on it. 4. It relegates the conversation to a second-class UI element, when this is the most important part of any project management system. 5. Trying to operate on a bun…
Have you used the bulk issue change tool? The UI isn't necessarily very user-friendly but I would not label it as requiring a lot of time, I actually feel it works quite well for this use case.
Earlier quoted context omitted.
Has anyone tried to use something like notion? Depending on your size you don't necessarily need all the stuff around it. Whats the difference between a story and an epoch? Most people don't really care. They just need something to track stuff being done, like a glorified to-do list with rich text.
Disclaimer: I work at Notion. I think Notion works well for tasks if your organization is small, or you are happy with lightweight process. There is no way to ensure all updates to a Notion page follow a strict state machine like Jira. Notion just doesn’t have those kind of validation / restriction tools yet. For our 100ish engineers it works well especially because planning docs flow seamlessly into project specs an…
I feel like this thread comes up in one way or another every few months but in a place where people almost have a hellbent desire to reinvent wheels nobody has reinvented this one in say...go or rails or whatever.
Why? Because for all of the hate jura actually does what it does pretty well when it's working and for most people and most businesses that aren't your homelab it works just fine provided you pay someone to maintain and administer it.
I feel like hating on Jira is the pastime that is now passed down from each generation of programmers to the next. I'm going to stick up for Jira. I certainly don't "love" Jira, though I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now). The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for…
+1 to all this. Plus, Jira *scales* - all the cutesy drag-and-drop tools are good for 100 tickets/issues/etc and then fall over. JQL and bulk edit are just warming up at 1,000 tickets.
I feel like hating on Jira is the pastime that is now passed down from each generation of programmers to the next. I'm going to stick up for Jira. I certainly don't "love" Jira, though I do think they've made significant improvements with "new Jira" (I think they call them team-managed projects now). The problem I have with the incessant Jira bitching is that I rarely feel that bitchers have a true understanding for…
> why don't you think some other company has come along and toppled the Jira crown? Jira is the way it is because Jira ISN'T built for developers. Devs may have to use Jira, but they're not the ones who have to pay for it. I wrote about this a while back: "Who is Jira’s target customer? It’s certainly not the poor developer who struggles to add a link to his bug report. (I’m still mad at them) Take a look at Jira’s s…
JIRA is so slow and the UI so clunky the project managers where I work use some type of spreadsheet upload mechanism with XML spreadsheets to automate the cruft creation. It's fun to watch.
Earlier quoted context omitted.
Yeah I've been defended Jira here in the past, too. My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some…
It's not a neutral tool. Jira makes micromanagement easy and trusting people hard; you can use it for good, but you're working against the grain of it the whole time. Everything is default deny (issues can only go through approved transitions, by default regular users can't change the available transitions), the default issue forms have way too many mandatory fields, and a bunch of reports that only micromanagers wan…
> by default regular users can't change the available transitions
I can't imagine allowing this. This would be a recipe for chaos. The transitions are supposed to indicate agreed-and-defined steps that work goes through. They're supposed to reflect your team/org process, to the granularity that you want to capture it in Jira. Letting anyone edit them ad-hoc is akin to saying there is no process at all for doing work. How would anyone be able to interpret the state of work if everyone has their own ad-hoc process that they can change on the fly?
If that's okay on a team then that team probably shouldn't use Jira. I also would not want to be the team-lead, or anyone else trying to figure out what's going on or keep track of work!