Externally visible issue where external parties (producers, co-developers, artists, designers, ...) need communication about fixes and timelines? Put it in the issue tracker so people can subscribe, elaborate on repro steps, share links so QA can learn how to verify it's broken / fixed, etc.
Something that needs to be fixed in your local changes before committing, lest something break terribly? Put it in code in such a way that your CI system will reject integration. That can be a // TODO or // DO_NOT_COMMIT comment that can be recognized and rejected by your git pre-commit hooks. Perforce lets you stage and describe changelists before committing them, and you can make hooks that will reject TODOs in those descriptions as well. In a pinch, #ifdefs to check for CI and a static_assert(false, ...); might be another option. One of my more common uses of this pattern is when extending or refactoring a platform abstraction layer - it tends to be easier to get it working on one platform first, and forgetting to test it on a second platform can be very easy. Switching contexts to an external issue tracker for things that nobody but yourself will ever read isn't adding value - keeping it in code where you can build safeguards that will literally prevent you from doing the wrong thing by accident will.
Internal refactoring or performance improvement suggestions? Those often go in the non-blocking non-tracker // TODO bucket for me. They can safely rot away unnoticed for 10 years without causing problems as issue trackers come and go, then suddenly become relevant as new needs cause new development, and as new development causes old problems to become new again. Producers aren't going to have useful input on if the refactoring or performance suggestions are relevant - the developer poking around the existing code isn't doing what they need it to do anymore will.
Something that needs to be fixed in your local changes before committing, lest something break terribly? Put it in code in such a way that your CI system will reject integration. That can be a // TODO or // DO_NOT_COMMIT comment that can be recognized and rejected by your git pre-commit hooks. Perforce lets you stage and describe changelists before committing them, and you can make hooks that will reject TODOs in those descriptions as well. In a pinch, #ifdefs to check for CI and a static_assert(false, ...); might be another option. One of my more common uses of this pattern is when extending or refactoring a platform abstraction layer - it tends to be easier to get it working on one platform first, and forgetting to test it on a second platform can be very easy. Switching contexts to an external issue tracker for things that nobody but yourself will ever read isn't adding value - keeping it in code where you can build safeguards that will literally prevent you from doing the wrong thing by accident will.
Internal refactoring or performance improvement suggestions? Those often go in the non-blocking non-tracker // TODO bucket for me. They can safely rot away unnoticed for 10 years without causing problems as issue trackers come and go, then suddenly become relevant as new needs cause new development, and as new development causes old problems to become new again. Producers aren't going to have useful input on if the refactoring or performance suggestions are relevant - the developer poking around the existing code isn't doing what they need it to do anymore will.