It's just so obviously an absurd statement to say that if a bug is fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all. A huge portion of the day to day work of software engineering happens without explicit documentation of every decision for every change for every line of code. Life continues, software is built.

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.

Who is claiming that if a bug fix fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all?

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.

The original poster in the thread we're in:

"Fixing a bug or delivering a feature where you haven't documented the process ... is as good a running a web site nobody visits."

the problem is it takes me 2 seconds to run git log to see if a bug has been fixed, vs going to a web browser, waiting for JIRA to load, waiting for a search to finish, curse at search for being useless, eventually find the ticket, and then see if it's complete.

Wow.

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.

Let’s face it, most git logs have one-liner commit messages that may or may not describe the issue at a very high level. Even if you have long commit messages, they still are less likely to contain extended discussions about the issue (which can be useful many months later), and cannot be edited. In many places, commits are expected to have the Jira/bugtracker ticket number in the commit message, so that if I find the bugfix via a git log (or git blame), I can quickly find the ticket with the extended discussion and other details that might be important.

Except when the linked ticket is just a title with no content.

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.

Which means that the creator of the ticket does not understand the value of the ticket and is just forced to do it by process and so does the minimum required for Jira and his other tools to let him work.

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).