Jira has a long history of needing the admins to do all the config. Not because there's a desire to limit people, but because there's a desire to stop people making a mess. Most of my Jira jobs have started with "please clean up this Jira because we've let people do what they want and it's unusable because they have".
There is the genuine desire to make things work better for the team, but two problems rapidly occur (there are a shed-load of other problems caused, but these two are the big ones)
1. Proliferation - because people are unsure that they might affect something else, they add stuff just for themselves. Seriously, you don't need, or want, 40 slight variations on "start date", you want one.
2. Incidental damage - a bit more unusual, as people who know that they don't know what they're doing tend to go for proliferation as the cautious option, but you do find "my thing stopped working a couple of weeks ago" or "my data has all been changed to something that's wrong", and in the worst cases, people writing scripts to "correct" their data when they find someone else has damaged it.
So, Atlassian limited the config of these things down to admins only, so businesses could say "no, you go through the Admin team". They are now opening them up in limited ways, such that you can do local configs. But they are entirely local, and based on modifying things that the admins still control (to reign in the problem above). Increasingly, project admins are able to do some local config of things admins make available.
I'm not sure screens will ever be added to that list, they might be. I suspect it's more likely that admins will still control the screens completely, but project admins will be allowed to hide existing fields from their project (and hence they'll vanish from screens) and maybe re-arrange the order of the fields.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.