Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eyeball the ticket.
We use a ticketing system to track work. It's not Jira. But we do have a requirement that all work is tracked in that system. It's not so that a Product Manager or Engineering Manager can chime in and micromanage; it's so that we have a record of the fix that's easy to find, track the conversation around it, and be able to reference it 6 months or later. Documenting how it was fixed and tested and verified is very useful. Having a place for a manager to eyeball tickets before they are working is not the value of the system.
The necessity for documentation exists along a spectrum, and the means of documenting things exists along a spectrum. We have lots of tools for documentation. Design docs, commit messages, the commits themselves, JIRA, email, chat. Which one is appropriate depends on the given situation.
That's not my intent as the parent here, or the point I'm seeing or picking up from this thread. There's value in documenting in a system (Jira is one choice), but I know that I'm certainly able to see value in building a system and a process and then trusting that developers use them when appropriate and know when they are not adding value.
"Fixing a bug or delivering a feature where you haven't documented the process ... is as good a running a web site nobody visits."
For a manager, this could easily have been written as:
It makes me 2 seconds to look in our issue tracking system to see if a bug has been fixed, vs opening a terminal, find the project, curse at grep for being useless,...
Of course omitting steps in your favorite solution makes it look easier.
And how is testing/validation tracked in how you use git?
Most of us don't work in a vacuum without managers, testers, customers.
And for the record, I as a developer also hate Jira, but we have to look at a reasonable solution.
However, I would argue that even some of that metadata is better than no metadata. At least the ticket can provide some clues for anyone who is investigating a change.
I feel like GitHub issues are good enough for this purpose; unfortunately GitHub charges a per user license fee meaning that most non engineers don’t get access by default reducing its usefulness.
Github issues are basically what a Jira ticket is. Just with less of the other stuff around it feature wise that Jira has. How your company uses Jira is not what makes Jira good or bad. Jira can either be used in an appropriate way or it can be customized into a big rigid process machine that we'd all hate. Been there done both. I like being in the Scrum Master/team lead position to try and influence things into a "less process" world. Ultimately I'm probably still 'hated' by the Devs because there's 'too much process and Jira' and the higher ups don't like it either because they don't 'have enough control' (actually illusion thereof).
When has JIRA actually been effective as the documentation for a bugfix? JIRA in its most effective will just tell you whether we agreed to do this work and the state the work is in. It is not "documentation."
We use JIRA specifically for this. Commit messages are JIRA ticket numbers and a short message to provide some context.
In JIRA we document what was requested/reported and which customer the issue affects/came from. We attach relevant documents and link it to possible related tickets. If a case is unclear we send it back to support and get additional info.
Once we commit we comment if needed to provide additional details. Our build pipeline then updates the ticket with build numbers after the issue is resolved so we know which versions has the build, which is pulled by our update distribution mechanism.
This way customers will get a notification when a new version is available that has a fix for one of their issues.
We then assign it to someone on support so they can follow up with the customer and verify that the issue is resolved, or we get the issue back with more details.
This way it's easy for both support, devs and management to see what's going on, and it has the needed context in case someone else has to take over.
Not saying JIRA is perfect by any means, but this works quite well for us. I should mention though that we use on-premise install so speed is not an issue for us. By the sound of things we'll be finding some alternative once that option is gone...
It's a shitty documentation system because it's extremely hard to find that organically, but people do use Jira as documentation.
Sadly it developed from a tiny, quick, useful note to a documentation slog when a new project manager joined and wanted a long description of everything typed into the ticket. So I ended up killing Jira altogether.
I don’t think the problem was jira, it’s just in project management thinking that it is the most important part and the dev work is subservient or easy.
Of course a typo fix in a comment (to find something even more trivial than your VM example) doesn't need a process. But that's also not what I'd call a bug.
In software products with enough large bases, some changes decisions affect other users, who eventually might request the change in the opposite direction.
You do not want to lose the rationale behind the original change/fix.
Keep in mind that what is a bug for some users is a feature for others: https://xkcd.com/1172/