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