Typically how I've seen this work in high-functioning environments is that devs aren't scheduled at 100% according to JIRA. They have time set aside in their schedule for work of this nature. They'll fix the bug, create a JIRA for the commit/PR, and get on with things. The coworkers on PR reviewers and get their notification that way or in standup. If it's more than 30 or 60 minutes they might log some time against it.
On a team I was on, there was a rule that we simply wouldn’t bother documenting 1 point JIRA tickets as then the documentation itself would likely take more time than just making the change.
That reasoning is weird to me. I could live with "there is no impact for users on this" but if it has impact for users (there of course is a difference between developing a library where a lot of things have impact from a GUI application where most things are invisible to the user) it should be documented, even if documentation takes three times the time. Good documentation is part of a quality product.
