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 prett

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.