[kqr]

When there is a ticket, yes, adding the number is trivial and probably worth it. Where the rule breaks down, in my opinion, is when you have to create a ticket and replicate the commit message in it any time you stumble over a code maintainability issue and fix it in stride.

[dallbee]

This is the practice we use - link to a ticket if it exists.

There's nothing wrong with fixing a bug you discover upon inspection. Forcing tickets for every change discourages code maintenance.

[crdrost]

This is also where automated code quality checks can shine. You can say something like, if it's more than 5 or 10 lines we expect a ticket ID, otherwise we don't.

See DeGrandis’s “Making Work Visible,” the hazard of “link to a ticket if it exists” is that sometimes this causes us to treat tickets as an external process, but we absolutely want to surface tickets that track our cleanup of tech debt and any other procedural tasks that we are stuck doing.

If automated tooling sounds nice but you are at the sort of place where “there are three priority levels: hot, Red Hot, and DO IT NOW,” this can also be part of a pull request template. One extremely effective template we used at a previous job just had quick checklist and you'd check off for example “I tried this code on my dev cluster.” Caught a lot of “whoops I am moving too fast and need to slow down a bit” issues, hah!