[he0001]

Jira tries to solve everyone’s problem. It tries to incorporate everyone’s idea of how and what’s needed to be tracked.

I can just say from my own experience that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer or anything near a software project, and yet enforces all this garbage for their illusion of control. And yet they have none. Just because they are higher up in the hierarchy than the people that works with the actual product.

And then there is all these managers that think that everything should be a ticket and all changes can absolutely map to a ticket. Or that everything is actually done by the guy on the ticket.

I bet when I die and go to hell, my punishment will be to fill out Jira tickets and push them through the workflow.

Edit: formatting and spelling

[submain]

I share the sentiment and frustration of having to fill useless boxes.

However, as a manager, things go south very quick if you're not tracking what's being changed and by whom. You won't know what's included in your release, nor if it was tested properly. You won't know who to reach for fixes after testing or even what to tell clients when they ask if a feature/fix was shipped.

I hate overly complicated processes, but tracking things is essential.

[TheCoelacanth]

Continuous deployment is the solution to that. You always know what is in a release because it's the one thing that you were trying to change when you clicked merge.

Overly complicated processes are just patches to try to cover up for immature engineering practices.

[ozim]

Bonus points for insisting on tracking everything in Jira and then not making effort to open it up to check and asking for status updates via im/mail/call.

[jdmoreira]

Your developers must be children then. (Maybe because you treat them like children).

The source of truth is their changelog not your Jira tickets

[submain]

Quite the opposite actually. My developers barely touch their tickets. Most of the updates are done rather informally. They mostly interact with git and I make sure things are tracked.

You’ve used quite strong words there.

[scubbo]

There are already 4 replies telling you that you're trying to reinvent source control, and that's still not enough.

[_dain_]

>tracking what's being changed and by whom

git

>You won't know what's included in your release

release notes

>nor if it was tested properly.

CI

[vundercind]

Resistance to simply reading data we already fucking have is so very weird to me in “agile” (and much of non-agile, to be fair).

Part of the trouble is using things like Jira and moving tracking-what’s-happening and chatting-about-features farther from the code than it needs to be.

[occz]

Seems like the kind of thing that Git is really good for, right?

[dingnuts]

> that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer

This is all configurable by the JIRA admin at your org. You're not complaining about JIRA, you're complaining about someone at your company who set up the workflows. I figured this out after bitching endlessly about JIRA at company 1 only to move to company 2 and discover everything I had hated about the process was set up by my previous boss...

I thought it was JIRA, but it was the org..

[bigmattystyles]

The problem is when your instance has too many masters - all fields are global, then their visibility is controlled at the project level. In a big company with one instance, holy sh!t. There are so many duplicated fields, unused fields. When you go to the bulk change option, it shows you all of these and it goes for days. It works well if you keep it under control, but word to the wise to any company. Create a governance board that's not afraid to tell a VP to fuck off with their requests for yet another ill-conceived field. That's from the user / web viewpoint. Don't get me started on their API. v2, v3 changes - the stuff you can't filter out that bloat responses, etc.... But otherwise, if well controlled, it is good. Or at least one of the least bad systems.

[robertlagrant]

Lots of things can be a ticket, though.