Is refactor as part of a ticket a good idea. Like mixing refactoring and features all the time because we can’t find time for tech debt otherwise?

Only if the code to refactor is related to the ticket.

We started Trunk Based Development with Shift Left approach meaning developers test their own code during PRs and our main branch should be always in releasable state. Problem is the only metric we get judged on is crash free rates. Since we started with the refactoring our crash free sessions dropped and we keep doing the refactoring. I am at a point where I think I must be going insane as the description of insanity is doing the same thing expecting different results. Keep saying we should separate refactoring from features and mitigate the risks but no people are saying we are testing everything on our PRs so we should be fine. Stats don’t lie and paint a different picture. We do refactoring unrelated to the features or ticket only because we are in the same file, service or model.

@PappyHans depends on how well the files are separating concerns but I‘d say in general, it’s a viable practice.

Depends on the situation. If it's a mess and seldom produces problems, leave it.
If it will save more time in the future than it costs to refactor it you may do it depending on your seniority

Follow your heart.

Thanks for the input all. With us is more of a personal preference rather than anything else. There is one person that has a strong opinion on how things should be done. We keep breaking things because of this refactoring and we are not doing it properly by adhering to any standards other than what is in that person’s head. I am tired of dealing with it and having to prove that person wrong all the time. So common sense is what’s needed there I think. We’re all with 10-15 years plus experience. I haven’t signed up for babysitting

@PappyHans I'm used to what @Lensflare said. But yeah, refactoring often introduces bugs that were solved before. You rewrite somethibg that was already battle tested. I prefer not to do it much. But normally, tests should guarantee that the system didn't break due refractor. But a bigger problem I have with it, it can escalate a ticket and it costs time in general. Your code can better be a six than a nine imho.

I have a nice story about this actually. I came new to a company and they were refactoring so hardcore, I was like, they must be master devs that they can pull this off. Month later, I saw the sentry. My god my god. It was a startup with the attitude to fix the bugs later Ala every AI provider (suckers).

Also, it did not end very well, refractoring attitude was a big reason. If they never had refactored, I'm 100% sure we would've been better off.