Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work.
Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.
If you want daily updates on normal tasks, you're just wasting a bunch of people's time. Under ordinary circumstances, that stuff cannot possibly be actionable, and tracking data that's not actionable is just wankery. I don't mean keeping people directly working on the tasks in-the-loop with one another and surfacing blockers, which shouldn't need formal process beyond at most a five-minute daily standup, I mean up-the-chain status updates. Wanting to watch the little Jiras move through the flow chart on a daily basis is just PMs and managers wishing they were playing Starcraft or something instead of doing work.
Given that, if your tasks are taking long enough that any but very-rare outliers span more than a couple status updates (which shouldn't be needed more than about weekly, under normal circumstances) then your tasks are too big or you've got some serious process issues making everything take far longer than it should.
From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily. If it's a nice-to-have bugfix, update it whenever you can, I don't care. If it's somewhere in between, I'd expect an update frequency proportional to the seriousness of the problem.
Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!
> If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily.
That's what one has sev/incident response procedures for. Put everyone in the entire management chain on a conference call with execs/comms/legal for as long as it takes - and make damn sure the line manager is shielding the actual engineers from this process so they have time to fix the bug.
> From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily.
Right, that's why I specified "normal" and "ordinary" tasks. Outages are another matter.
> Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!
Devs aren't in the ticketing system all day. They close it because they're all bloated as hell and eat system resources like mad, only opening it when strictly necessary, which then takes forever. They take longer to navigate it than you do, because they're not in it all day. They dread it because ticket workflows are often convoluted and hard to understand for anyone who's not in the ticketing system all day, and because they're all designed in such a way that it's weirdly-easy to accidentally press a button or drag something and mess things up in ways that can be tricky to fix or even to understand what's happened, sometimes without even noticing one has done that—it usually feels like trying to collaborate by using the PM's RDP-shared Windows desktop, covered with directories and text files arranged just so.
It is not the "easy way" to them, it's easy for you, and only you—otherwise, they'd use it! If your devs are any good, I guarantee they're communicating a lot, just not where you want them to, because it is not easy for them. Slack, email, git logs, PRs, quite possibly a shadow-ticketing system that's not a resource-hogging, confusing pile of crap in really pathological cases (probably the one attached to any Web-attached source management system you're using)
I agree that status needs to be communicated, but if that's more than about weekly under normal circumstances then it's because someone's screwing up, and it's worth remembering that your "easy" as someone who's in Jira (or whatever) all day isn't someone else's "easy".
Their "easy" would be you letting them use a ticket system they find actually-usable, and then reading that and translating anything that's happened there, into the one that you like but that doesn't work well for them. Or just figure out a way to use the one they like—you're one person, they're several.
[EDIT] It's also worth considering that those kinds of high-visibility-to-managers systems are always going to be a bit bullshitty. People will omit things or even lie on them at higher rates than they will on purely-internal communication tools, which is part of why people don't like to use them for their actually important communication within a team. Letting the team communicate where they like and then translating that into Manager in the high-visibility system will get you more-accurate information, and you can decide what to do with it.
Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.