If you sign up to Jira today and start a new project, you'll get the options of a simple workflow with a minimum of fields. The beginning statuses are basically "to do", "in progress", and "done". There's a fair amount of trust in those steps, IMO.

> 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!

> 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?

Everywhere I've worked the states have been the steps, the transitions have just been there for Jira's own bookkeeping. And in the real world it's always possible to move a piece of work to any other step in your workflow - things like "the designer's realised he messed up the wireframes, put it back to design even though it was currently in code review" happen all the time. I don't think that's the same as not having any process.

In the Jira way of doing things you can't do that if that transition doesn't exist, and you probably don't have the required permissions to add that transition (if you can even figure out what they are). Couple that with Jira's terrible performance and I've been in more than one company where you could accidentally drag and drop a ticket to the wrong column (because Jira decides to finish loading at the wrong time) at which point it's permanently fucked up and your only option is to copy and paste the data (one field at a time, natuarlly) into a new ticket.

I realize company-wide planning is extremely hard, especially when there are many inter-dependencies that can block entire departments if a single deadline slips. But in my experience, the only thing that Jira brings to the table is the ability to document, in a centralized place, the pieces of work that need to be done, and what stage they are currently in. In my field, anything software related is really hard to estimate accurately, which makes the whole aggregate estimation in Jira not only worthless, but actively harmful because management will treat it as truth. We could replace Jira with a big whiteboard of TODOs and we'd likely get things done faster, and with higher quality. My favorite excerpt from the site:

> Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.

I find Jira isn't a tracker, it's a tracker construction kit.

You can make it be pretty much anything you want - except, you know, fast.

I view Jira as the embodiment of the misguided software engineering practice of trying to generalize and abstract too high level of a task of something like "project management" and distill it down into one tool.

While the Golden perfect abstraction handed down for the heavens by the gods is what you seek, it ultimately passes down complexity to end users through its generic approach. You need to create opinions within the generic world and then your team needs to understand Jira's abstraction combined with the opinion your company builds around it that's probably not documented.

The end result is unless you're running a large project that really requires the functionality possible in Jira where creating the overhead or overloading something simpler isn't practical, then you're probably better off using something simpler and more opinionated--a nice simple solid framework to keep everyone on track.

> the default issue forms have way too many mandatory fields

I only fill points and name for my issues. My company never customized anything.

Almost none of that is true depending on which version of Jira we are talking about and what type of project you have chosen.

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.

> The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable.

That's probably where the wide-spread (and arguably correct) impression that it has become worse comes from: To begin with, people just installed and used it as-is, but by now corporate bureaucracies have had time to "implement" it -- i.e. set it up -- to mirror their organisation's bureaucratic structure and processes.

And yes, that impression is correct; it is Jira's fault: If it didn't have that customisability, they couldn't (ab)use it that way.

> If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira.

Of course you can: If it didn't offer the possibility to set up those bureaucratic locks, they wouldn't be set up.

I can tell you that a lot of other tools before Jira that I have had to use were really quite good at mirroring that structure in a much worse way ;) Most of those tools from my experience were not usable in a good way.

You and other people are obviously entitled to the opinion that Jira made it worse.

In my book, that's like saying it's the Swiss Army knife's fault that someone was killed with it.

Victorinox's fault. If there were no Swiss Army knives, nobody would get killed with one.